The Value of Prep Work
January 19, 2025
A few years ago, my wife and I replaced all the windows in our home.
When it came time to install it, I figured it would take the better part of a week (it’s about 22 windows).
Instead, the company said, “Oh, it takes about two days.” I was skeptical but guessed they would send a larger crew or something than I had imagined.
On installation day, two guys showed up. Two! How were two guys going to replace all my windows in two days? To make it even better, I asked one guy, who responded, “We’ll replace all the windows today. Tomorrow is finishing work.”
I was curious to see what would happen next.
Here is what they did.
- One guy got out each replacement and identified where in the house it would go, setting the replacement window down at the foot of the house below the old one
- While that was happening, the other guy went to each window on the inside and removed the blinds, checked each window, etc.
- Once the windows were setup and the inside checked, they set up their ladders at each window
- Once it was all set, they went as a unit to each ladder; one guy footing the ladder, the other guy climbing up and replacing the window
- When they had replaced every window, they put all the ladders away
To be fair, this isn’t a groundbreaking process or anything like that. I’m sure other crews operate the same way.
But seeing these two guys work so well together helped me better understand how effective teams operate.
The Value of Prepwork and a Plan
The first standout was the amount of prep work they did. Instead of going window by window first, they knew that making sure the right windows were on the truck and then placed in the right spot for installation would mean only going over the order details once.
This prep work meant that when it came time to install, they wouldn’t need to go back and forth to the truck to ensure they got it right; they already had. They knew that instead of moving a single ladder around the house, it would be silly, so they decided to set up a different ladder everywhere they needed.
They also inspected and ensured all the windows inside were ready to be removed. The same idea: go through the house once on the inside, and then you can install all the windows in one sweep later.
I think we often get this wrong on a software team. In a world of “fast-paced” environments and the need to be agile, we’ve reached a point where we don’t do enough prep work. We decide that since things will change, we don’t need to plan much at all; we just dive in and figure it out.
What I’ve seen in my career is that the genuinely agile teams (with a little “a”) are the ones that plan more. Instead of having a quarterly planning meeting and a lengthy requirements gathering meeting that is stale when the proverbial ink is dried, great teams ask, “What can we get done this week?”
They review the acceptance criteria of their upcoming work, ensuring everyone agrees on the expected outcomes. They seek to know who is doing what, when, and why. They set up their proverbial ladders so when it’s time to get to work, they can “just do it.”
To some engineers, that might sound micro-manage; perhaps, in some extreme cases, it is. And yet the only times I’ve felt micro-managed is when I’ve worked on a team that didn’t plan, and my manager has to now tell me everything they think I need to do and how because… we never had a plan :)
Plans change, of course; I’m not saying to be inflexible. But I’d rather have a plan open to change than no plan or prep work at all.
Evaluating the Right Cost
Another thing that stood out immediately was that they brought so many ladders! If this company had a truck that had ten or more ladders or more, and say they had ten crews, that is a lot of ladders. And good ladders aren’t cheap.
But it hit me: they knew the cost of an extra nine ladders per crew was still way less expensive than having to either a) hire more installers per crew or b) the cost of long install times, which would prevent them from doing more jobs and therefore less revenue to the company.
One of the most significant costs in software isn’t paying for tools or even an AWS bill: it’s the engineers.
Your engineering team’s ability to write high-quality code as quickly as safely possible is vital to your company’s ability to create real value.
To keep your engineering team effective in that goal requires some cost. It may be tools, AI, good laptops, or providing generous learning budgets. Whatever the investment is, for many teams, the cost of properly equipping your engineers will often be less than the cost of not equipping them.
Make sure engineers have access to the right systems, create the proper channels for teams to make reasonable requests for new resources or tools, and give your team the time to improve their daily work (which is the most important work anyway).
What Work Should and Should Not Be Parallelized
The last thing that impressed me about how this installation team worked was they knew clearly when to work together on a single thing and when to split off and work independently. They knew they could parallelize placing the windows outside with sweeping on the inside of the house because the effort for either was a) acceptable for one person to do and b) minimal risk if something were to go wrong.
But when it came to installing the windows, one person always footed the ladder. They knew that having someone footing the ladder - standing there and keeping the installer safe - would decrease the risk of a fall and give the installer the confidence to finish their work faster. On paper, someone might say, “You could finish the job faster if each person go on their own ladder”, but you would quickly realize that would slow the installation down.
I was reminded of this while listening to a Developer Tea podcast. Jonathan Cutrell observes that some of the most critical work you do isn’t getting your own work done; it’s helping others finish theirs.
Footing the ladder is the term he used to describe small-effort but large-impact (i.e., high-leverage) actions you can take as an engineer to help your team succeed. Code reviews, document reviews, answering a question in the Slack channel, or even a quick pairing session to help unblock a teammate are all examples. Adding your effort to help someone else accomplish their work will likely increase your team’s throughput and decrease the risk of failure.
As a quick note of caution: you can take this too far and be helping everyone all the time and neglect your own work. There is a happy middle ground here to be had. A good technique that works for me is blocking off long periods of focus time as well as setting aside shorter blocks to review code or docs each day.
If you want to be the fabled 10x engineer, the easiest way isn’t through writing mountains of code or being an expert in every possible technology possible. The easiest way is to help your team win by creating a plan, giving them the resources they need, and footing the ladder when possible.
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.