Since we launched Hill Charts in Basecamp we’ve been fielding many interesting questions. One common question is: how do we catch more problems in the uphill phase so they don’t surprise us later?
What happens is, people think a piece of work is downhill, and then all of a sudden a problem comes out of nowhere. Especially when it comes to programming issues. “Why didn’t we catch this earlier?”
The reason often traces back to the uphill phase. An engineer looked at some work and imagined the solution in their head. “Yeah I don’t think that’ll be too hard.” They saw in their head how to do it, so they positioned the work at the top of the hill.
What happened next? After they got their hands dirty and started building, the reality turned out to be more complicated.
The problem is the uphill work was imaginary. Thinking about how you’re going to do something is not the same as rolling up your sleeves and trying.
The solution is to start at the bottom. If all of you’ve done is thought about the solution, then mark your status at the bottom left of the hill to show you haven’t built anything yet.
Now to move uphill, write some code to prove out the idea. Pick out the most essential steps or moving parts and write enough to validate the approach. Some teams call this “spiking” or “stubbing out” the work.
You’ll still run into the unknown. But the difference is now you and the rest of the team expect that to happen because you’re still in the uphill phase. In fact all of your development work on this side of the hill is about spiking the unknowns and finding these trouble spots.
You can’t bet on work that isn’t over the hill. So nobody will be surprised if a problem comes up on the left side. This is a healthy time to get stuck.
There could be a variety of solutions. Maybe you need to put heads together with your peers. Or get advice from someone senior. Or consider a different package or library to do what you want. Whatever the solution, everyone can see the problem as a step toward figuring out what’s going to work — what’s going to make it over the hill.
Having spiked out the most important parts of the problem, you can be confident that what’s left really is just a matter of execution. Sure there will be little surprises, but you’re less likely to run into something that blows the budget or breaks important assumptions.
The key point here is: imaginary work doesn’t count. Get to running code early. Or a rough interface. Or an outline of the copy. Whatever it is, the way to get uphill is to roll up your sleeves. Seek out the things that might go wrong and show evidence that the approach will cover them all. Then when you get to the top of the hill, your team can trust that the work is really going to ship as planned.
Real Work vs. Imaginary Work was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.