As a software engineer, as you grow in seniority, at some point you may be asked to lead the delivery on a feature, an initiative, or a project of some sort. But what if you haven’t delivered a project yet? Or have tried to deliver a project or two and it didn’t go as well as you hoped?
In this series of posts, I’ll introduce a few informal project management techniques that should help you do better. These are based on my experience in the last 15-ish years of leading various software projects in four different companies on teams ranging from internal software to platform engineering to SaaS product teams.
The techniques will specifically address:
Making sure that everyone is on the same page—including you.
Discovering dependencies, risks, and surprises early.
Producing a reasonable effort estimate.
Staying on top of delivery and having it go smoothly.
Having a smooth rollout.
All of this won’t fit into one post, so I’ll break it up into three parts:
Part 1 (this part): Initial notes and kicking off a project
Part 2: Technical design and planning
Part 3: Staying on top of delivery
But first…
What’s a “project”?
For the purpose of this post, it’s a chunk of work that:
Has a clear “start” and “done”, like a new feature, an infrastructure upgrade, a refactor, or a minimum viable product for a new system; and
Has a delivery time between a single engineer working for a month on the low end and a team of 5-7 working for a couple quarters on the high end.
Different organizations call this type of work by different names: epic, initiative, feature, or something else. For the purpose of this post, I’ll call it a “project”.
The principles from these posts would still be useful for work outside of this definition, but the specific techniques I present would be overkill for a week-long task and insufficient for a multi-year cross-department program.
Also, every company, team, and project is different, and what you’ll work on is not what I’ve worked on. So treat these posts less like rigid step-by-step instructions and more like a toolkit or a starting point for your own process.
With that in mind, let’s begin.
You just got a new project. Now what?
As a software engineer, your first instinct on a new project may be to start designing a solution or thinking through the code you’d write.
Suppress that instinct.
Instead, the first thing you’ll need to do is make sure that:
It’s clear why the project is being done and what success looks like,
There are clear expectations for what exactly will be built, and
The right people agree on the direction.
If you don’t do this, you might confidently deliver something that no one needs, and you’ll discover that only late into the project.
The rest of the post will focus on how to get those three things done. To do that, we’ll need to start one document and have a few meetings.
Step 1: Start a project outline document
To begin, we’ll need to document what we know about the project so far, and what kind of questions need to be answered. A great way to do that is to start a project outline document.
It can be a Word/Google doc, a page on the internal wiki (like Confluence), a PowerPoint deck, or any other document; the main criteria are that (1) it should be whatever your company uses for similar documents, and (2) bonus points if it can be easily shared and collaborated on.
In it, add several blank sections:
Overview
What’s out of scope
Requirements (feel free to rename it to “Details” if you or your org are uncomfortable with the word “Requirements”)
Open Questions
Risks
Don’t worry too much if you cannot complete—or even start—some of these sections until you’ve spoken to some stakeholders1. But do try to fill out as much as you can eventually.
Here’s what goes into each section.
“Overview” section: add a couple paragraphs with the project motivation for those who’re new to it, what goals it’s trying to accomplish, and what success looks like. It can also include a brief summary of what exactly would be built.
“Out of scope” section: clearly state what the project will NOT deliver, or what may be delivered later but not this time around.
“Requirements” section: this is usually the biggest section. In it, outline what you think the project is supposed to do, how it’s supposed to interact with any existing features/components/systems. For user-facing features this could also include outlines of user flows; for internal migrations or upgrades this could include the end-state vision and list of systems to upgrade. And so on.
You don’t need to include the fine details like the exact UI fields and validation error messages, but it should be clear enough that by the time you get to working on a detailed technical design, there are minimal surprises.
This is also a good time to look around and do a quick gut-check of whether the project is even possible by briefly taking a look at the code (probably with AI’s help these days), or reviewing the documentation for any external systems you’d be interfacing with (add a link to these in the doc). It’s also a good time to note which parts would be responsibilities of another team. Feel free to start sketching out the implementation too (see Part 2 for details), but don’t go too deep into it—we’re not at that stage yet, and a lot can still change.
“Open questions” section: As you write out the requirements, you will inevitably run into spots where you’re not sure what exactly the expectations are. In those cases, stop and leave a bullet point in the “Open questions” section noting what should be clarified and who it should be clarified with. Alternatively, you can leave comments straight in the document, or you can add questions inline in a different color (like this?).
“Risks” section: you can fill this out later during design/planning, but as you go it’s good to ask yourself what can go wrong. Usually it’s questions or concerns like “we probably can’t deliver X by the end of the quarter with only two people”, or “what if their API doesn’t support this?”, or “is team Y willing to deliver this by the end of the next month?”. Some of these can be answered by looking up the relevant info right away (e.g. the API question), but for others, you’ll need to follow up with the right people—more on that later.
Step 2: Talk to the stakeholders
Next, it’s time to book some meetings with people who can give you the necessary information. This can include the decision-makers like your managers or clients, subject matter experts in the relevant domains, or even developers on other teams who can explain how their systems work.
The main goals of these meetings will be to:
Clarify what exactly needs to be delivered,
If you’ve written down anything in your project doc, confirm that it makes sense and is on the right track,
Answer any open questions you have, and
With the main decision-makers: establish the priorities, especially if some parts of the project cannot be delivered on time or will require more resources.
I usually first meet with the people whose opinion matters the most, like my boss or the product manager or the client, and then work my way through everyone else.
You can also try to do this via chat or emails, but I find that at least at the start, it’s better to have a meeting because asynchronous communication doesn’t work as well until after the common expectations have been established.
Update the document as you learn new information and as the open questions and risks get addressed. Add the new risks and open questions as needed.
Descoping and reprioritizing the work
Sometimes it becomes clear that some things are bigger than originally thought or that they’re not realistically deliverable. These can become candidates for “descoping”: reducing the expectations or eliminating them entirely.
If you’re the full owner of the project with the power to make decisions on what gets done, then go ahead and cut or re-prioritize as needed—keeping in mind the project’s ultimate success criteria. Though depending on where things stand, you may need to have a chat with some stakeholders first to get their opinions or at least give a heads-up.
If someone else is the ultimate owner, I recommend against just saying “we cannot do this” or “we won’t do this”. Instead, I suggest stating the constraint and offering choices: “I don’t think we can realistically deliver both X and Y, which do you think should be a priority?”, or “there’s a high risk we cannot deliver X on time with two developers; do you think a third can be added? Or are we OK with X going into the next month/quarter/milestone/etc?” Then let them make the decision.
Anything that ends up being cut, moved, or deprioritized should be added to the “Out of scope” section in your project document together with any appropriate notes.
Handling disagreements between major decision-makers
Sometimes several important decision-makers disagree on key details or priorities.
In this case, the approach that worked best for me is to book a meeting titled something like “Agree on (topic of disagreement)” and invite all decision-makers—or, at least, the disagreeing ones—and let them discuss the issue and come to a conclusion. In my experience, they will almost always come to some sort of understanding. If they still disagree, the next steps are highly dependent on your circumstances; it can be anything from escalating the question to upper management to giving up on the project altogether.
Last step: Final alignment
Once most of the project details have been nailed down, it’s often useful to have one additional meeting with all the decision-makers and project participants where you’d go over the final outline of what will be done and what will not be done.
Depending on how your organization works, this can be either a dedicated meeting or it can be part of another meeting like bi-weekly refinement. Or you might even be able to do it asynchronously via email or chat. Though I do find it helpful to have everyone in the same room for this step.
Keeping the project expectations up-to-date
You now have a set of initial expectations for the project that everyone understands and agrees on. However, don’t be surprised if things change, especially if this is a larger project with a longer delivery time. When that happens, sometimes all key decision-makers will already be aware of it and in alignment, but sometimes they won’t. In that case, it’ll be your job to have any follow-up meetings or discussions to make sure that everyone is on the same page about the new project direction.
Moving on
Now that we’re clear on what’s to be done, we can move on to the next step: detailed design and planning.
Coming soon: Intro to project management for developers - Part 2: Technical design and planning
A “stakeholder” is basically anyone who can materially affect the project or will be materially affected by it. In practice, some stakeholders’ opinions matter more than others, and some stakeholders are also decision-makers, but the terms aren't synonymous.