Leading projects has given me the greatest learning opportunities in my career. I can attribute a lot of personal growth to these opportunities and am extremely thankful for getting them at the right time. So I thought I’d share some learnings from these experiences in case it’s helpful for others. I’ll be focusing less on the process-oriented aspects (which can differ by project) and more on the more generalizable aspects of being a good project lead.
1. Dealing with ambiguity
When I started leading projects, the biggest challenge I had was dealing with ambiguity, making decisions and getting comfortable with the outcomes (good or bad). Some things which helped me deal with ambiguity:
- Spend some time building a high-level view of the problem space. Definitely recommend talking to folks who are domain experts but it is important that you build your own mental model. All models are incomplete and ultimately it just another tool to help us make progress. If you encounter new information that changes how you think, be open to re-thinking the model or discarding it completely. It is also fine to not have a clear mental model upfront since you often develop that only after trying out a few things.
- If in doubt, ask a lot of questions. You will find that people are generally happy to help you understand how something works in their area of expertise. No matter what happens, don’t pretend like you understand something that you don’t. It will just come back to haunt you later. It is totally fine to listen to ideas that you don’t understand and revisit them later if they become relevant.
- There is no one “right” answer but there are a lot of wrong answers. The goal is to pick a right-ish answer and figure out the rest along the way. It is not the end of the world if you pick a wrong answer since they won’t necessarily lead to bad outcomes. (But be wary of one-way doors.) Unless you have a crystal ball, you won’t know what’s right and wrong upfront. So trust your intuition and ability to course-correct as needed.
2. Effective written communication is key
I have gotten a lot of feedback about written communication over the years. This is an area that is important for anyone leading projects. Here are some useful principles that I stick to:
- Put some effort into crafting any written communication. (Over time, hopefully should carry over to in-person discussion although that’s harder since that’s more spontaneous.) This is a lot like writing code where the goal is to optimize for future readability 🙂
- Keep it short — imagine every email or slack message is a tweet 🙂
- Provide quick context for someone (in the first line) to know if they should care to read more or not
- Use bullet points aggressively!
- After writing a draft of anything, see if it makes sense logically. (I have personally written some confusing and contradictory statements and gotten this feedback. Writing helps you catch flaws in your thinking unlike speaking)
3. Limit communication overhead
This maybe a potentially controversial take but I don’t think more communication is always a good thing. I am sure we have heard of plenty of stories of how under-communication has resulted in bad outcomes (someone not being in the loop or not communicating something in more detail) and that’s in general a more common failure case. But the costs of communication overhead don’t get talked about enough. This is a biased take since I am particularly sensitive to this as someone who feels drained with a lot of information/interaction. Here are some costs of extra communication:
- Loss of focus for anyone who doesn’t need to be involved in an email thread/slack conversation
- Derailing of important discussions with irrelevant details. (Social pressures like not wanting to offend the person sometimes don’t allow us to bring things back on track quickly)
- A general reduction in system efficiency since things take longer to resolve. Length of email chains is roughly proportional to the number of people on it 😉
4. Focus on results
This sounds obvious but getting results should be the no.1 goal for anyone leading projects. Making other people feel good, personally feeling happy, experiencing a lot of personal growth are all amazing secondary objectives but none of them should ever be prioritized over getting results. Getting results has a lot of positive consequences:
- A winning team is a happy team!
- Stakeholders trust you which gives the team a lot of breathing room to be more creative. This can allow you to create new opportunities to support growth of the people on the team.
Having said that, the goal should be to not just get results for the current project/quarter at any cost but to think about how this team can continue to work together to achieve a lot in the short, medium and long-term. At the end of the day, being a decent human being is more important than hitting the OKRs. Knowing how to balance people and results is the mark of a good project lead 🙂
5. Don’t take results too personally
This is a necessary follow-up to previous bullet point and is easier said than done! I personally struggle with this a lot when leading projects. When things don’t go well, this creates a lot of self-doubt on whether I made good decisions or not. This is quite normal and is a good thing since it indicates that I care about the outcome. But worrying alone will not change the outcome. So, I try to use this to take some steps to overcome how I am feeling and then move on to worrying about a different thing 🙂
6. Figure out what works for you
Everyone is different. Every project is different. There is no reason why those leading projects need to follow the same rules on every project. A couple of examples to illustrate what works for me:
- Being an introvert, meetings tend to drain my energy 🙁 But being a project’s lead means meetings are sometimes a necessary tool to keep the team aligned. So, I put effort before the meeting to have a good agenda and send it out ahead of time (and I cancel aggressively if I can’t think of anything). It allows me to rely on the agenda to run the meeting and I don’t have to spend a lot of energy during the meeting since I have done all the thinking ahead of time which saves time in sharing context/helping make decisions quickly.
- In general, I am super loose about project tracking, especially at the task level. This mostly stems from my bias as an IC who considers it to be overhead most of the time. This can be really valuable for bigger cross-team projects (like React) but for most small projects, it maybe overkill. So it is up to the project lead to decide how much process is needed for (i) the team to be effective and (ii) for project lead to have a sense of team execution/progress.
- I split my week into IC and project lead days (see Maker v Manager schedules) so I can work on execution without being distracted by slack messages. (As a project lead, responding to that and unblocking others maybe more valuable for the project success than your own personal output. Having a reputation as someone who is prompt can never be a bad thing)
7. Motivate people on your team
Motivated people significantly outperform unmotivated people. For a project lead to do this effectively with team members, it is important to have 1:1 conversations and understand what they are excited to do on the project. I do this by scheduling some time before the start of the project to get to know them better and check-in somewhat regularly to see how they are feeling. Since this takes time, I only do it with folks I don’t have an existing working relationship with. The ideal end state of this exercise is that people feel comfortable talking to me if/when they have concerns.
At times, there may not a good match between what someone wants to do and what they are required to do on the project. While that’s not ideal, we still have to get work done! The best thing to do in this case is to just be upfront about the mismatch and appreciate them for doing this even when they are not excited about it. (It’s not easy and we should acknowledge that!) There are always other things the project lead can do to make people feel excited about a project! The key insight is that most people care about more than one thing — so be creative in finding opportunities. Some ideas in this dimension:
- finding interesting product/technical challenge for engineers/designers
- giving engineers time to refactor code in project-adjacent areas
- encouraging team members to grow their project leadership skills by allowing them to take on some of that work from you (that is how I got the opportunity to be a project lead)
- giving data scientists chance to grow their ML skills / do more data research / write production code
- providing visibility by allowing them to present in meetings with leadership
8. Listen to everyone
This took me a while to internalize but every single person you interact with knows something that you don’t. So, be very careful about shutting your mind to new ideas, especially ones that don’t fit your current mental model of how things work (confirmation bias is real). If your first reaction to some suggestion is that it is a bad idea, ask clarifying questions and seek to understand. If after this exercise, you still feel the same way, thank the person for their input and move on. It is really important that people feel listened to when they share ideas. Otherwise, the next time they have a valuable piece of input that could benefit you, they may not feel comfortable sharing it with you and the loss is all yours. Caveat: While it is important to listen to everyone, you shouldn’t feel pressured to accept/incorporate their ideas.
9. Appreciate good work
Everybody loves to be appreciated! (though the way they like to be appreciated may differ) We may remember to point out things that can be done better but it’s even more important to appreciate good work so that they remember to do that and also others will emulate that. Good to be specific with praise, otherwise sounds hollow 🙂 Appreciating good work also allows you to be more direct about things that person can do better and that constructive feedback has a much higher chance of landing better.
10. Invest time in building your peer group
I have been able to build strong relationships with folks who are better than me in some dimension. A lot of this started organically when working with them on projects but I tried to keep that relationship going with one-off social chats or brainstorming sessions. I personally value people who think a little bit different from me (especially designers). There are a bunch of ways having this peer group has helped when leading projects:
- When stumped with a product or technical problem, I can always go to the person who I think can help and have a conversation with them about it. Sometimes I talk about the same problem with different people to get different perspectives. (Word of caution: If multiple people you trust say the same thing, it could be because that is actually the best path or it could mean that they are relying on the same information to draw conclusions. Groupthink due to shared context is real)
- A lot of times, these relationships go both-ways i.e. they would come to me with help with certain problems which makes the relationship feel mutually beneficial which encourages more help-seeking without any reservations about taking up each other’s time.
- Some of them provide emotional support too when faced with some not-so-fun-work since they can relate. I find peer relationships to be better in this dimension because they can relate to your experience more easily (unlike managers who may not have experienced it themselves)
The above learnings represent a lot of my beliefs right now about leading projects. But I am sure my opinions will change over time with new experiences. Looking forward to writing about that in a few years’ time 🙂