How to Lead a Project - as a Software Engineer

On my engineering team, every team member eventually leads a project, no matter how junior (or senior) they are. This is a practice I've built up over years. We've shipped complex projects like rewriting the Uber rider app and the Uber driver app - our team of up to 20 engineers used this methodology to ship our parts, as part of larger projects that involved hundreds of engineers. We used this approach for smaller, but complex projects, like launching new ways to pay. This is the project lead expectations guide I share with project leads, outlining guidance on the role, and expectations that come with it. View the whole Google doc here.

Tech lead / project lead expectations. See the document on Google Drive.

I tried to put all of these as guidance: being clear on the expected output, but not specifying the “how”. Want to do this via Scrum? Fine. Adhoc? Also good. Some weird, new method? Go ahead. Having space for tech leads to experiment is so important for growing for leads - and it's something I embrace in building an engineering team where everyone is able to step up and lead.

Setup a framework for collaboration

A key role I ask tech leads to take on is ensuring collaboration happens between team members and stakeholders. I try not to specify how to do this, in detail, but things I do expect are these:

Stakeholders. Create a list of project stakeholders involved in this project.
Kick-off. Schedule a kick-off with the team - with all relevant stakeholders (like the PM, Design, DS and EM) included.
Documentation: setup and maintain the documentation of the project. There should be one place where anyone interested in what this project is, can go and have access to planning, boards, rollout plans, and other relevant resources.
Collaboration channels: setup the collaboration spaces for the team: may this be JIRA, a chat channel, email list, document storage etc. The larger the project, the more important it will be to clarify which channels people can use to reach all relevant team participants.
Efficient project management. Choose a project management methodology. Make sure the team shares regular updates, there are regular progress demos, work is transparent and tracked and encourage face-to-face information exchange so everyone can quickly confirm that they are on the same page.

Manage risks

Managing risks is another key area. Have a way to track if things are on track (it doesn't have to be status reports - remember, we're talking about hands-on engineers). If something seems off, dig deep and come up with ways to mitigate it. If you see something, say something.

Understand all parts of the project at high level - from mobile to backend to business impact. E.g. if you’re a mobile engineer, get familiar with the backend stack and the other way around and build a good relationship with the engineers on your “other” stack - and the other way around. You will be the person with the most context on the project - make sure you know what the top issues on each stack are.
Create an inventory of knowledge - list out the services and libraries that you’ll touch. If you work with an unfamiliar codebase, assume the worst when giving time and risk estimates, and make sure the team does some research upfront.
Call out risks honestly as they arise - on standups, raising to the team/EM as soon as you spot them. Between project time, scope and people if one changes, we need to decide if and how we change the others. As a rule of thumb, the best time to call out a risk is when you first spot it. The second best time is now and not later.

Communicate status to stakeholders

Instead of others pulling information on how things are going, come up with lightweight ways of keeping stakeholders in the loop. It could be as simple as keeping the workboard of the team up to date or sending a weekly/bi-weekly update email.

Keep the team and internal stakeholders aware of how the project is progressing via the weekly team meeting and demos. Consider sending out a weekly update email to make sure everyone is on the same page.
Keep status tracking documents up to date that the team and other stakeholders can get an idea of project progress. This could be the project board or other documents (like a feature readiness list) you choose to use.
Identify any other stakeholders who need to be aware of the project, working with the PM.

Help the team focus - and don't be afraid to delegate

Make the life of the team easier. With a tech lead, they should be able to focus more, not less. But don't put it all on your shoulders: delegate up, or to team members (especially when it's a nice growth opportunity for them).

Help engineers focus on the next important thing. We need to go one step at a time towards the next shippable thing. Remind the team what milestone you need to ship next.
Delegate where it makes sense. You can both delegate upwards (e.g. to your manager or PM) as well as to team members. You own a lot of responsibilities - it can be a win-win to `share these with some of your teammates. For example, someone else can be in charge of running standups. Be clear that you’re delegating or asking for help. Also be clear on what your expectations are for the person taking this on.

Motivate the team

Finally, be the kind of team lead people like working with. Motivate the team and don't forget to celebrate in the end. I always make sure we have budget to celebrate a job shipped and a job well done. And make sure others hear of the great work the team just did.

Checklist for first-time project leads

I found the above generic guidance to be a bit too vague for first time project leads. So I put together a more hands-on version for getting started with that first project. I ask that people who have not lead projects before follow these steps closely. Once they have led a project and have gotten experience with these techniques, they are welcome to experiment with different approaches, reverting back to the original guidance.

Project setup

Lead a kickoff meeting with an agenda and all stakeholders present. Prepare for this meeting, getting feedback from the EM and other, experiences project leads.
Break down milestones, assign estimates to them. Usually done on one or more planning meeting, with the engineering team.
Follow the RFC planning process. Send out the intent for RFC, do the planning, put the RFC together, send it for review and follow up with approvers.

Regularity

Weekly update emails. Send out weekly update emails to internal stakeholders. This email should have milestones, estimates and their status the very least. This should be sent at the very least to all team members working on the project, team EM & PM.
Daily standup with an agenda & notes. Use something like the sync notes template. Make sure the whole team and internal stakeholders (like PM, design) are present.
Set weekly team goals. At the beginning of the week, agree with the team what you aim to get done this week.
Demo progress (bi)weekly. At the end of the week, check if you made this progress via a demo. Demo even if you don’t have anything visible: show at least the code to each other.Do a retrospective at the very least, at the end of the project. You can do it every few weeks as well.

How this process is working

Over the past three years, I've iterated on this approach with my team. Every team member has led at least one project with multiple people involved - including the most junior ones. While there have been a few tensions and challenges, I'm very happy with the results, so far. I've summarized more detailed learnings in the post, An engineering team where everyone is a leader.

Feel free to check out the more detailed project lead guidance document. If you are leading a team, perhaps you can put something similar together. And if you're an engineer, perhaps you can use this as a starting point for running your next project - however large or small it might be.

Featured Pragmatic Engineer Jobs

Full-Stack Engineer at Farmlend. £85-95K + equity. London.
Senior Backend Engineer at Farmlend. £85-95K + equity. London.
Senior Full Stack Engineer at Perfect Venue. $150-180K + equity. San Francsico or Remote (US).
Senior Software Engineer at AI Build. London or Remote (Europe).
Senior DevOps Engineerr at AI Build. Remote (US).
Full-Stack Engineer at Vital. $70-120K + equity. Remote (Global, within 5 hours of GMT).
Backend Engineer at Vital. $70-120K + equity. Remote (Global, within 5 hours of GMT).
Technical Lead - Platform at Vannevar Labs. Remote (US).
Senior Software Engineer, Fullstack at Vannevar Labs. Remote (US).
Computational Geometry Engineer at AI Build. London or Remote (Europe).
Senior QA Engineer at AI Build. London or Remote (Europe).
Lead Backend Developer at Cineville. €53-79K + equity. Amsterdam.
Senior Software Engineer, Distributed Systems at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
Senior Software Engineer, Fullstack at Mixpanel. $200-270K + equity. New York, San Franciso, Seattle or Remote (US).
Principal Engineer at Shoplift. $185-205K. New York.
Senior Engineer at Sixfold AI. New York.

The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.

Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities - similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.

Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers - full-stack, backend, mobile, frontend, data, ML - and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.