Work on the most important thing, with as many people as you can, until it is finished
It’s easy to think about software engineers as carpenters. In two weeks, a carpenter can lay down twice as many floorboards as in one week. An experienced carpenter can tell you how long the floorboards will take just by looking at the plans. In software, deadline predictions are decidedly harder to pin down. Much ink has been spilled over the difficult labor of estimating software projects (for over forty years!).
Many software companies adopt an Agile software development process to mitigate these unpredictable timelines. All flavors of Agile share the view that long-term predictions are inaccurate and should be avoided. Predictions are usually only accurate for the length of a sprint, and they consistently break down around one month in the future.
Unfortunately for companies that depend on sales-driven growth, limiting promises to one-month-in-advance is often unacceptable. For a new product, deals are closed by promising a feature months ahead of time. Furthermore, complex business models often have non-technical work that must be organized based on the schedule of the software delivery.
To succeed in these markets, teams must learn to predict the future. Incorporating dependencies and optimizing schedules is hard; when you don’t know how long something will take, it is impossible. As a result, I find that the best approach is to:
Work on the most important thing first…with as many people as you can…until it is finished.
Let’s break it down.
Prioritizing The Most Important Things (and committing to them)
In order to “work on the most important thing first,” you must first decide on the Most Important Thing. Pick your favorite methodology for gathering requirements and developing user stories. Focus on scoping features down to an MVP and validate ideas where possible. As you develop a short list of new ideas, force-rank them by comparing one against another. Factor in both importance and urgency: maybe the most important feature can move down in the list because of the current time in the business cycle.
Once you have a ranked list, draw a conservative line defining things that you can promise. These are the items you have deemed The Most Important, and which you can commit to externally. There should be a wide margin between the amount you promise and the amount of work you can get done in that time. Remember that making predictions is hard: if you end up doing exactly what you promised, it’s probably because you got lucky and nothing major went wrong (and next time you might not be so lucky).
Now you have a clear set of goals, and it’s time to execute.
Multiple People On Every Project: The Benefits of High-Parallelism
Imagine two carpenters installing floorboards in two adjacent houses in a development. If they each take one house, they may finish them both in a month. If they team up and work on the same house first, they might still complete both in a month, but they will complete the first house faster. If you add a third and a fourth carpenter, they might make the first house go even faster, but they might also get in each others’ way and slow down the total timeline for both houses.
This analogy roughly holds for resourcing a project with engineers. The obvious caveat: deciding how many engineers can work on a project is an art and not a science. Overcrowding an initiative doesn’t just slow it down, it also frustrates engineers and can lead to more bugs. At the same time, completing a software feature quickly has the compounding benefit that you can gather data on its use and improve it. Focus on building an intuition for the correct “max” number of engineers for a project, because having two or more people on a project has a ton of additional benefits.
Prioritizing your feature list speeds up execution. Identifying a project as top priority is the best way to make it move fast. Once identified, it becomes justifiable to tackle that project with as many resources as is useful. When everyone is in agreement about priority, it’s all-hands-on-deck to get the feature into users’ hands.
Assigning multiple engineers to a project makes the team resilient to distractions, so delays are less likely. If a project has only one engineer, project velocity can easily go from 100% to 0%. If you want to add a second engineer to compensate, nobody is free to teach them the requirements. If a project with one engineer lies untouched for even a week, deadlines often get pushed and commitments get broken. When your engineer takes a vacation, gets sick, or gets pulled into a high-priority issue (and your best engineers always will), redundancy allows the project to keep moving towards completion.
Parallelization also means collaboration. Engineers can learn more from one another when they are executing tickets from the same backlog and discussing design decisions. Also, once they’ve completed a commit, they have the necessary context do code reviews for one another.
Most engineers like to focus on a single project for at least a few days at a time. Having multiple engineers on a project means other engineers on won’t need to context-switch to help out if things go wrong. Also, you can justify keeping existing engineers on your top priority project, leaving other team members to fight fires.
Finally, group projects provide engineers with a fertile environment for growth as leaders and project managers. Allowing different engineers to plan projects helps to distribute responsibility, so that you as a manager are not a bottleneck for planning. Plus, putting a junior engineer on a project gives the lead engineer an opportunity to delegate and manage work.
Leave No MVP Unfinished
When you send a team off to tackle your highest priority project, make sure that they finish it. This final point may seem obvious, but a released feature is much more valuable than a still-in-development feature. An agile company will constantly reevaluate priorities based on new data, and it can be tempting to put down an in-flight project to attack an unexpected new priority. It is important to remember that if there is one week left of work to release Feature A, it is rarely worthwhile to get a one-week head start on Feature B.
It can be difficult to let a project sit untouched when it is planned and ready to execute, but when your resources are limited, focusing on what is most important, attacking it with as many people as possible, and seeing it through to completion are the best ways to reliably meet your users’ needs and build the best product possible.
