How to Lead a Software Project in 6 Steps

You're eager to get promoted as a junior SWE—I’ve been there.

To rise through the ranks, you'll need to deliver projects that unlock meaningful value for your customers.

But what if you've never owned and delivered a software project from start to finish?

Luckily, I've walked this road many times over the past 3 years at Wayfair. These 6 steps comprise my battle-tested formula for success:

Establish credibility as a competent SWE.

Before any manager will hand you the reigns to lead a multi-month project, you'll need to establish a reputation for delivering high quality work on time.

This is because they'll be taking on risk by investing the team's resources to complete the project. And your manager will be entrusting YOU to lead that investment.

Their reputation will be at stake as much as yours, so give them every reason to believe that your leadership abilities are worth taking a risk on.

2. Wait patiently for the right opportunity, or create your own.

You may be lucky enough to get handed your first major project. If so, great! Pick up the baton, and run the rest of the race as if you started it.

If you aren't so fortunate, you'll have to make your own luck. This means doing the up-front work of inventing the project you'll own by looking for high-priority problems your team can feasibly address.

It may be a large enough problem to warrant collaboration with other teams. See this as an opportunity to broaden your scope of influence within the company, not as a roadblock to success.

Once you've found the problem you want to solve and thought through a few high-level solutions, you'll need to sell the project.

The rest of your team has to buy into your narrative about WHY this problem is worth solving.

Use real data to back up your claims – it will provide additional credibility and help your manager sell the project to other stakeholders.

Then organize your "sales pitch" in writing to minimize meetings and maximize alignment.

3. Shift left – eliminate ambiguity as early as you can.

The more unknowns there are between your current point of progress and the fully delivered solution, the higher the risk of failure.

Clarify that ambiguity early and often.

This process is also known as "shifting left." It applies equally well to granular coding tasks, large-scale project management, and everything in between.

Shift left using these 3 strategies:

a. Consult with subject matter experts on your team about the solution and its technical design.

b. Build small proofs-of-concept (POCs) to demonstrate feasibility of higher risk system components.

c. Proactively communicate about potential roadblocks, so others can help you push past them.

4. Document your chosen solution.

During the execution phase, you'll be collaborating with other stakeholders to implement your chosen solution.

To make sure you're all building toward the same north star vision, you'll want detailed documentation of the ideas that, until this point, have largely existed in your head.

This means authoring artifacts like technical specifications and scrum tickets which clearly define:

a. The thing you're trying to build, and

b. The steps required to build it.

Add visual components to these documents whenever possible, like screenshots from POCs, UX mocks, or data flow diagrams to help others quickly grasp the desired end-state.

Consider the context in which any artifact will be read, and ensure that its level of technical detail is appropriate for the intended audience.

This step is essential for larger projects that span multiple months and/or multiple teams, because the people working on the project may change over time. Don't let someone leaving the company be the reason your project gets scrapped or delayed.

The better your documentation, the easier it will be to onboard new stakeholders. Crystalize your knowledge of the solution and spread that understanding throughout the company.

5. Drive execution and lead by example.

Finally, it's time to bring your vision to life. During this phase of the project, it's your responsibility to oversee the timely delivery of your solution, while minimizing the chances of bugs reaching production.

Before beginning, identify which parts of the solution can be implemented in parallel, and which parts serve as blockers. Be ruthless when deciding if a feature is essential to the initial release. Communicate this information to your team.

Know how to measure the success of the project, and put any necessary measurement instruments in place. This often includes tracking specific metrics that quantify business impact.

Depending on your level of seniority, you'll be doing some or all of the implementation work. Any code being written by other engineers should be reviewed by you to ensure it satisfies the project's requirements.

Use this opportunity to maintain a high standard of excellence, and embody that standard within your own code.

6. Reflect on the outcome and extract learnings for next time.

If you've followed these first 5 steps, congratulations on owning and delivering your first project! In a perfect world, every project would be smooth sailing.

But you knew that wasn't going to happen, right?

Take advantage of this valuable learning opportunity to reflect on what worked and what didn't.

Organize a time for your team to go through this process together, and extract action items for individuals to follow up on. Ask key stakeholders for their honest feedback, then incorporate it into your next project.

Remember, failure is in the eye of the beholder. Either you win or you learn.

P.S. I'm still perfecting the art of project leadership too, you're not alone. Which step are you focused on right now? Comment below so we can all learn from each other!👇

0 comments

Big Tech Devs

skool.com/self-taught-web-developers-5417

A community of friendly software devs working at big tech companies.

Constantly sharing learnings to help each other earn that next promotion.