Planning for momentum

Planning for momentum

On reimagining planning as a dynamic and generative process.
Part of
Issue 19 November 2021


For many engineers, planning represents the antithesis of what we love about building software. We relish exploring new problems, researching and designing solutions, and delivering code we’re proud of. But an inflexible or unrealistic plan can be a bucket of cold water that rouses us from our dreamy fantasies of pure engineering to the cruel, cruel world of mind-bending Gantt charts, weekly check-ins, unforeseen hurdles, and missed due dates.

Plans and estimation are hard. After all, each project and feature represents something you’ve never built before, and the complexity inherent in software development means there will always be surprises—and not the kind you’d want to get on your birthday. That’s why iterative approaches to software development, such as agile, focus on delivering work continuously and in small increments so teams can adapt to the unexpected. 

However, even planning in smaller chunks has its challenges. We’ve all had a sprint blow up on us due to that one-hour ticket that took a whole week to complete. So why not stop estimating altogether? The #NoEstimates movement popularized on Twitter takes a radical view on planning and estimation, suggesting that instead of spending time calculating every piece of desired functionality in a requirements document, engineers should simply pick the highest-priority item, break it down into its component parts, and deliver it as quickly as possible.

Given that planning is perceived by many as fraught with issues, old-fashioned, and cold sweat–inducing, some might think it’s time to consign formal plans to history. But what if we could reimagine planning as a generative process rather than a restrictive one?

A shift in focus

I think plans have gotten a bad rap. They’ve become synonymous with deadline pressure, arbitrary rigidity, and execution at all costs. Too often, they’re merely a thin veneer masking the imperfect, and to some degree unknowable, realities of our work. But if we acknowledge that plans can’t eliminate uncertainty, we can take advantage of their true potential. 

Plans, at their best, aren’t about endless deadlines and rigid performance guidelines. They’re about creating momentum. They breathe life into new products and features and align teams around a common goal. When developed with this framing in mind, they can make the distance between where we are and where we want to go feel more traversable. 

Consider the sense of possibility and excitement you experience when you book a vacation. Do you get fired up about planning the drive to the airport? Does mapping out a second-by-second itinerary induce feelings of calm and relaxation? Probably not. You’d likely find it much more enjoyable to focus on the bigger picture: where you’re going and what you’re going to do. Keeping in mind that your plans might change—you can’t predict whether a hike will be rained out, or the water park will be closed—you’re prepared to adapt.

Likewise, if we let go of the idea that a plan has all the answers, we can acknowledge that a dramatic change in the plan doesn’t mean we’ve failed. It just means finding another path forward. To wax philosophical and paraphrase Heraclitus, change is the only constant in life. 

What’s more, accepting that plans can and will change can lead to better outcomes. To extend our vacation analogy, imagine you discover a breathtaking hiking trail you hadn’t planned to visit. Changing your plan might just result in the best day of your trip. Now, imagine you discover through early user testing that your solution addresses your customers’ needs after just a few weeks of work instead of the months you’ve scoped out. Revising your plan will grant you the freedom to solve other problems for your users, rather than spending time adding extraneous features and frills to the existing solution. 

Planning to think

The kinds of products, features, and applications that we as software engineers produce require some serious thought—and planning is a fantastic way to get thinking.

In a 2014 talk at the University of Chicago, Larry McEnerney, the renowned former director of the university’s writing program, suggested that people who work in complex domains shouldn’t try to solve entire problems in their heads and then implement the solution. Instead, they should write about them first. The writing process, he said, allows us to fully express and refine our ideas and proposed solutions. We continue to reflect and iterate on them as they materialize on the page. 

Planning, like writing, produces tangible artifacts. For example, you could create a design document for all nontrivial additions to your codebase, such as new features, architectures, and changes in functionality. A design document is a structured template that allows you to plan your approach to the problem at hand while also providing a resource for future engineers that explains why a particular part of the system was structured a certain way. It prompts you to ask and answer critical questions up front, before writing the code. What does this new feature do, and where does it sit within the system? What context does it need, and what contract should it have with neighboring components? What scale are you aiming for? 

These written artifacts—your plans—can take many forms. You could create a short document with ideas for the technical direction of a new feature, or write a vision statement for your new flagship product outlining the functionalities you’d love to build. You could produce a design doc that follows a formal structure. The form is less important than the function it serves: detailing your ideas, producing a record for soliciting feedback, and enabling your plans to evolve over time. And evolve they should.

Failing faster

There’s no such thing as a perfect plan. Your initial architecture may have unforeseen flaws, or you may encounter unexpected performance bottlenecks when ingesting data at scale. Maybe another team at your company is working on solving the same problem, and you’ll be better served by joining forces and collaborating on a solution.

Sharing your plan allows you to tease out those unknowns and identify and solve problems more quickly. By creating a planning document and soliciting input from your team, project stakeholders, and key senior engineers, you’re opening yourself up to new ideas and perspectives and inviting others to find the holes in your plans. That might feel uncomfortable, but in truth it’s wonderful—it gives you an opportunity to patch up your plans before you’ve put time and effort into writing the code. 

With each layer of feedback your plan will become more airtight, and you’ll increase buy-in around your approach. You can make changes before it becomes expensive to implement them, and the resulting feature will be more fit for purpose. Consider the alternative: If you don’t solicit feedback, you might only uncover a weakness—say, a security gap in certain edge cases—during the pull request, at which point you’d have to go back to the drawing board and rewrite the feature. You’d have missed out on a major opportunity to fail fast and with less friction. Quite in contrast to the unyielding blueprints of the waterfall era, your plan can become a tool of agile development instead of an impediment to it.

Plan for propulsion

When we understand plans as a tool for creating momentum rather than a set of inflexible and sometimes stifling parameters, they can provide a sense of direction and orient us around a shared objective. Agile is all about collaboration and continual iteration, and planning can be too. We don’t need to cut code in order to start collaborating; we can cut words and diagrams to clarify our vision, and continue to hone it as we build.

The next time you begin planning a new feature, architecture, or refactor, write a design document or a vision statement and see how it helps sharpen your ideas. Share it with your colleagues for their feedback. Patch up the holes your collaborators have generously pointed out, and keep moving toward the crispest version of your vision. Let it fuel an ever-evolving plan that propels your teams forward.

About the author

James Stanier is director of engineering at Shopify, where he helps enable millions of merchants to sell, ship, and process payments anywhere. Outside of work, you might find him running around in the Cumbrian Fells.


Artwork by

Tim Peacock

Buy the print edition

Visit the Increment Store to purchase print issues.


Continue Reading

Explore Topics

All Issues