How to lead projects from start to finish as a software engineer

The best engineers don't just know how to code.

They know how to bring people together and deliver value.

They know how to:

• Align people toward a goal and consistently make progress
• Push through challenges as they arise
• Raise others and scale themselves

Today, you’ll learn exactly these skills.

In this article, you’ll learn How to lead a project from start to finish.

Note: Every company will run projects slightly differently. I’m going to share the process I’ve seen the most in my experience that has gone well.

Step 0: Kickoff

A project starts at the “Kickoff” stage. This is when something that was planned on the quarterly or annual level is ready to start.

A Product Manager (PM), engineer, tech lead, or engineering manager usually initiates the kickoff phase. Who starts it depends on the company culture.

We’ll assume you are taking the lead as an engineer.

As the lead, you create a Project Kickoff Document.

The goal of the kickoff is to align on the “Why”, “What”, and “Who.”

• Why is this project being worked on
• What will we do to solve the problem
• Who is working on it

Check out the full, free Project Kickoff Template here.

After you write the doc, you’ll schedule a meeting with the stakeholders you listed.

Check out my Guide to Leading Meetings to lead this meeting effectively.

After the meeting, all the key stakeholders should agree on when they will start work on their respective parts. Since this is the early stages, you’ll rely on the Product Manager and Designer to make progress on their parts so the engineering work can progress.

However, there are a few things engineers can do at this stage:

• Work with your cross-functional dependencies to ensure they are on board with providing the support you need.Omar Halabieh, Tech Director at Amazon shares the importance of aligning with cross-functional dependencies early.
• Start scoping out the code and filling in the Technical Design Document with what you know so far.
• Work with your product manager and designer to help where you can

We’ll talk about working with your product manager and designer in the next step.

nbsp;Step 1: Setup

After the kickoff, everyone starts working in their direction.

The problem is that there is no clear way to communicate updates.

To solve this, I recommend a few things:

1. A channel for project discussions—usually in Slack. In the past, I had a #project-payment-portal channel when I worked on a Payment Portal project.Here, you can ask questions, share progress, collaborate, and surface blockers.
2. A weekly project sync meeting. Use this for visually showing progress on the project, sharing wins and kudos, demoing new functionality, getting feedback, and adjusting the timeline if needed.You can use my Weekly Project Sync Template to lead this meeting
3. Set up regular 1:1 meetings. I recommend meeting with your product manager, designer, and engineers weekly or bi-weekly.These 1:1s are an opportunity to connect with the other person and understand how things can go better for either of you.I bring up things like, “How do you feel the project is going? Is there anything you’d change?” or “Is there anything I could do that would help make things better?”I also ask more general things like, “What’s top of mind for you?” or “How was your weekend?” and try to get to know the other person more.

On 1:1s with your Product Manager and designer:

1:1 meetings with your product manager and designer are a great opportunity for you to provide early feedback or suggestions on the direction of the requirements or designs.

Don’t tell them what to do though. Instead, tell them how certain approaches could impact parts of the project they might not be aware of.

For example, if your designer is between 2 options, you could share that you like one of them because it will cut scope by 1 week and would allow for earlier customer feedback.

The last optional addition for the “Setup” phase of the project is a daily standup.

Daily standups help shorten feedback loops and improve accountability. Many people don’t like them but know they are an option. I recommend using your best judgment to determine if you need them.

nbsp;Step 2: Planning

At this point, you have:

• Alignment on the goals of the project
• A Product Requirements Document (PRD) from your Product Manager
• Designs from your designer if there are UI changes

Now, it’s time to plan the milestones and technical approach.

You can do this through a Technical Design Document (or tech spec).

The purpose of the design doc is for 2 reasons:

1. Align on the technical approach for solving the requirements in the PRD
2. Align on the estimated timeline and project milestones

You can follow my Technical Design Document Template and article on writing better design docs here.

Following the article above will lead to reduced risk in your document and fast approval when you do a group review.

Once the technical approach and milestones are agreed on, you can begin the technical work.

nbsp;Step 3: Execution

Now that you have the technical approach and the milestones laid out, you want to start assigning tasks at the sprint level.

You might have a team sprint planning where you do this for all projects, or a dedicated meeting for it, like the weekly project sync.

With your plan in place, start allocating tasks.

Throughout this process, do 3 main things:

1. Keep stakeholders up to date in your project communication channel—Share progress, blockers, timeline adjustments, and meeting summaries.
2. Meet in the weekly sync and adjust milestones or timelines as needed. Show a visual indicator of progress, not only JIRA boards. Make it clear to everyone where the progress is at and whether it’s on-track or off-track.Preview of the Weekly Sync Template
3. Continue meeting 1:1 with engineers and other stakeholders to address concerns or areas of improvement for how things are going.

As the project lead, you want to focus your time on guidance and support as much as possible—rather than on nitty-gritty details.

Think of yourself as a map-maker that shows everyone where the treasure is and how to get there, but you can’t go alone. You need everyone to work together to reach the treasure.

A few more ways this may manifest:

• Prioritizing code reviews rather than shipping code yourself
• Writing a guide that others can follow—allowing you to scale yourself
• Staying at a high-level view that preemptively recognizes edge cases, blockers, or places certain people will need to work together and facilitating that.

For more of the philosophy behind this, check out Addy Osmani’s guest article, The Making of a Senior Engineer.

nbsp;Step 4: Launch

Your code is ready for users! It’s time to ship it

But wait—for any decent-sized feature, you rarely want to jump to 100% of users.

Why? Because new code is risky. It can cause bugs or regress metrics.

Begin by rolling out the feature to a small percentage of users.

I also recommend splitting up your milestones into deliverable units of value to users. This allows you to incrementally ship new behavior to users and get feedback.

So the two things you want to focus on here are:

1. Start small. Ship to just 1% of users when first rolling out to production. Depending on the company, you might also segment based on client type or geographic location.
2. Iterate on direct feedback from users, metrics you’re looking at, or bugs you see.

As you do that, gradually increase it to 100%. At some companies, you might need to let experiments run for multiple weeks before finally getting to 100% rollout.

I’ve had to do a multi-week rollout in some cases, and in others, I’ve been able to go from 1% → 5% → 20% → 50% → 100% in a single week when the feature ships with no bugs and the metrics are moving in the right direction.

nbsp;Step 5: Close-out

Once your project is live, it’s not over yet!

Don’t forget to do these:

1. Check metrics - Ensure the results are what you expect. This is also a great time to screenshot for your performance review later on!
2. Announce the launch - Using those metrics, announce the launch and the wins you saw. I like Ryan Peterman’s Launch Post Template for this.
3. Run a retro - Schedule a retro and discuss how to improve for next time. You can use my Project Retro Template for this.
4. Request feedback from your team - The retro is great for covering team-level process improvements. However, you’ll learn a lot about how you specifically can improve if you ask for individual feedback from your teammates.A quick way to ask is, “Hey Marie, it was great working on the project with you. I was wondering if you’d be open to sharing start-stop-continue feedback with me? I want to know what I did that went well and what things I should look out for in future projects. Feel free to be brutal! I won’t be offended.”
5. Celebrate - Find some way to celebrate, whether it’s doing a happy hour, having a board game hour, or getting pastries for the team. These are things I’ve done in the past but feel free to adjust depending on the team and company culture.

nbsp;TL;DR

As a subscriber to High Growth Engineer, this whole guide in checklist format is readily available to you in my Project Leadership Checklist doc.

Here is a quick summary of the steps though:

1. Step 0: Kickoff - Align on project goals, key stakeholders, rough milestones, rough timeline, risks, and next steps.
2. Step 1: Setup - Set up a channel for communication, a weekly sync, and any recurring 1:1s with key stakeholders like your product manager, designer, and other engineers.
3. Step 2: Planning - Write your technical design doc to align on the approach to meet the requirements in the Product Requirements Doc from your PM. Also, come up with finalized milestones based on your estimates.
4. Step 3: Execution - Assign tickets during sprint planning based on the milestones from your technical design doc. Continue meeting with engineers and stakeholders to minimize risk and catch any issues early.
5. Step 4: Launch - Roll out to customers incrementally. Test and iterate based on feedback.
6. Step 5: Close-out - Check metrics to verify results, run a project retro to improve for the future, ask teammates for feedback, and celebrate!

nbsp;Shout-outs of the week

• Strategies to track your achievements on Strategize Your Career by Fran Soto — I love the approaches Fran shared for reflecting and keeping track of your achievements to set you up for success in 1:1s, stand-up, and performance reviews.
• Five mistakes when seeking feedback on Take It From TechLead by Omsai Jadhav — Concise article packed with insights on how to improve how you ask for and receive feedback.
• Key insights from Radical Candor on Tech Books by Orel Zilberman — The 4 types of feedback givers and why you shouldn’t be afraid of giving feedback.

Finally, I’d like to shout out Irina Stanescu’s Influence Cohort starting in < 2 weeks. I took the cohort and learned a ton of great frameworks for thinking about influence. Plus, it was great to have direct access to Irina and hear stories from all her experiences as both an IC, tech lead, and manager. She also offered a 10% discount for all High Growth Engineer subscribers which you can access via this link.

Thank you for your continued support of the newsletter and the growth to 52k+ subscribers ref credits to : JORDAN CUTLER MAR 10