I want to share several learnings from my experience over the past three months of serving as a project lead for the first time. It was both an exciting and, at times, a stressful period, but overall a wonderful opportunity to deliver software not just from an engineer’s perspective but also as a project manager.
Know exactly what is being asked of you. I remember when I was told that I was going to serve as project anchor I said to myself, “Oh this will be fun,” except I didn’t take a moment to clarify what exactly that meant. I spent the beginning of the project operating under my own assumptions. Assumptions are a space where miscommunication can thrive. Even if your task is ambiguous, always try to ascertain what people are expecting of you. Take the time to talk to your manager, the product owner, or whoever is involved and ask them what they think your role is. Once you have an understanding of what people think you should be doing, you can then come up with a clear vision of what your role actually is and set expectations accordingly.
Ask whether there is a deadline, and if that deadline is unrealistic, push back via the right channels (to the product owner). It’s important to express early in the project’s development that the current deadline is not practical. If you’re using Scrum or agile methodologies, you should have a good sense of the team’s work pace, so be confident in that knowledge and inform the right parties when deadlines are set or communicated.
They say information is often lost in the seams of things. This couldn’t be truer than when delivering a multi-team project. Understand and make sure everyone is aware of what they own and what they will be accountable for. Project boundaries can become very blurry when you are working with multiple full-stack teams. Set up weekly meetings so there’s a space to ask any questions, get progress updates, and share any information other teams need to know. Over-communicate big decisions whenever possible.
On the days leading up to the project launch, after each standup confirm everyone’s roles and duties for the project. Create and share a launch week roadmap to track when final changes should be completed. This not only will give the engineering team a direct path that they can follow but also will reassure business team members about the project’s ability to launch on time and successfully.
When demoing your project, make sure to highlight the aspects that the audience will care most about. For example, if you are presenting to designers, make sure to demo and talk about any use of a particular design system. Tailor your demo so you call out the features and changes that the particular audience will appreciate.
After launch, always host a postmortem with all relevant parties so there’s a space to talk about what could have gone better and how to improve collaboration in the future. Postmortems differ from retrospectives since they bring to the meeting everyone who contributed to the project, not just the team you work on. Use the postmortem as a way to collectively share and receive feedback as a wider team.
And be sure to celebrate the launch. Some teams enjoy lunches, drinks after work, or maybe participating in a team activity. Use the end of a project as a moment to bring the team together and build a sense of camaraderie. Please spend some money (ideally the company’s) on the team after they have delivered a win. People work hard, and when they get things done, a pat on the back makes everyone feel appreciated.
From my experience, the main challenge when leading a project is making sure everyone clearly understands what role they play in the success of the project. Communicate early what people will be held accountable for, and keep everyone in the loop with decisions to prevent cross-functional knowledge gaps.
What have you’ve learned as a project lead? Share any insights in the comments below.