10 Things I have learned about leading projects

Over the past few years, I have had the opportunity to lead several projects working with other engineers and other cross-functional peers. 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). If you are doing this right and taking on more growth challenges, things should get harder in some ways and easier in other ways. If it starts to get too easy, then it means you are not being challenged enough. Some things which helped me deal with ambiguity:

• Spend some time building a high-level view of the problem space you are in, including some past context. Definitely recommend talking to folks who are domain experts but it is important that you build your own mental model of how to think about this space. It is important to realize that all models are incomplete and at the end of the day it is 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 throwing it out completely. (Having said that, it is also totally fine to not have a clear mental model since sometimes you can develop that only after trying out a few things)
• Once you have a model of how the different pieces fit together, you can now use that to figure out where new information that you learn fits in.
• 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. (But it is totally fine to listen to ideas that you don’t understand and get more clarity on them later when you need to act on them)
• 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 worst thing in the world if you pick a wrong answer since not all wrong answers will lead to bad outcomes, only ones which are one-way doors. Unless you have a crystal ball, you won’t know what’s right and wrong upfront. So trust your intuition and your ability to course-correct as needed. Over time, your intuition should be getting better in a specific area. If not, you should think about why that is not happening — Am I not reflecting enough? Am I not seeing the patterns?

2. Effective written communication is key: I have gotten a lot of feedback about this over the years and is an area that is important for project leads. 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 common failure case. But the costs of communication overhead doesn’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 offending 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 of any project lead. 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:

(1) A winning team is a happy team!
(2) 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 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 all project leads 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. (Having felt motivated and unmotivated at different points in my career, I know this is very real) So it is in our best interest to find ways to get people to focus on parts/aspects of the project that they are personally excited about. Some of my favorite project experiences have been when the project lead took the time to put me on things that I enjoyed doing. For a project lead to do this effectively, it is important to have conversations with the members of the team 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 that don’t have an existing working relationship with me. The ideal end state is that people should feel comfortable talking to me if/when they have concerns and it is in everyone’s best interests to get there as soon as possible). At times, there may not a good match between what they want 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 but also understand that sometimes it just may not be possible and that’s ok :) Some ideas in this dimension are around allowing them to focus on things which are important to them:

• giving designers more time to explore things that are adjacent to the focus area
• find some interesting product/technical challenge for engineers/designers
• giving engineers time to refactor code in project-adjacent areas
• giving team members chance 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
• giving people visibility for the work that they are doing with leadership by allowing them to present in meetings

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 in with your current mental model of how things work (confirmation bias is real). If your first reaction is that it is a bad idea, always assume you are missing some context and ask clarifying questions to confirm your understanding. If after that, 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 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 but I am sure my opinions will change over time with new experiences. Looking forward to writing about that in a few years’ time :)