I've encountered many engineers and managers in my career who don't feel that tech planning is "worth it"—usually arguing that planning takes time away from writing code and often leads to debates about technical decisions and possible solutions. While these points are valid, I believe the time tradeoff is worth the benefits of planning and consider it a skill that every engineer should invest in and practice as they grow throughout their careers.

What is tech planning?

Tech planning is the act of taking the customer/product/business requirements of a problem to solve and documenting a plan for defining, delivering, and verifying the solution. Most often this plan is a document created by one or more engineers on the team responsible for the solution.

Tech planning is also sometimes called tech design or engineering design. The names aren't important; the activity is.

Why is tech planning important?

A tech plan results in a better solution. Because you have to think before doing when writing a tech plan, it acts as a forcing function for exploring areas you may not consider if you jump straight into execution mode. And because you share and discuss tech plans with your teammates, you get the best ideas earlier in the process so you can incorporate them into the solution you plan to deliver.

A tech plan helps you go faster. Once you know how you're going to solve a problem, execution is much easier—you already know what to build and what code to write. Coordination between teammates is also easier; you already decided what steps to take to deliver the solution, so dividing them among your teammates is straightforward.

A tech plan makes the implicit explicit. Often you have some ideas about how you want to solve a problem—writing a tech plan forces the ideas out of your head and into forms that you can share, discuss, and evolve. A written plan creates a shared understanding of the considerations being made in developing the solution and explicitly outlines the necessary steps to deliver it.

A tech plan creates alignment. Often two engineers can look at a problem and come up with two different solutions; indeed this is a beautiful feature of engineering! Discussing and documenting those differing solutions creates clarity between teammates about ideas and assumptions. It also provides a shared space in which the team can explore solutions, debate any contentious points, and ultimately decide on how to proceed.

A tech plan helps onboard new teammates. Tech plans capture a snapshot of the team's technical direction and serve as a history of decisions made by the team. They are a great way to answer the common question of "Why is this system built this way?" and thus help bring new teammates on board. Similarly, people outside the team can read a tech plan and understand the reasoning behind technical decisions.

When should tech planning happen?

There's no hard and fast rule; tech planning should happen any time a problem is sufficiently complex enough to warrant it. Remember that you are trading off time to execute with time to plan. Most often this means for "big" projects, but there are also small projects that can have interesting or ambiguous components that merit a tech plan. If you're not sure if you need one, try writing a summary of what you plan to do to solve the problem. If that doesn't clarify the plan enough for your team, you should probably invest in making a more fleshed-out tech plan.

What goes into a tech plan?

A great tech plan:

• Starts with the problem. Anyone who reads the tech plan should have a cursory understanding of the problem you're setting out to solve within the first few sentences of reading the document. Further reading will add more color and depth to their understanding, but the high-level points of the problem need to be specified upfront. Restating the problem and linking to product specs/other relevant docs is also useful here.

  • Example: “We want to make it easier for users to start using the app for the first time. Users currently struggle to know what to do first after signup, so we need a system that supports a more gradual introduction to the product.”

• Surfaces tradeoffs. At its core, a tech plan should contain an exploration and evaluation of potential solutions. The exploration should be as broad and deep as necessary for the complexity of the problem. The costs and benefits of each solution should be clear enough that others reviewing the plan understand the criteria by which you're weighing solutions. This can help others follow along with your thinking as well as identify potential gaps. Think through the tradeoffs as deeply as you can to ensure you're not missing important details. You can use bullet point lists of pros and cons, a table, or anything else that helps you visualize the tradeoffs, as long as they are clear.

  • Example: “We need a new backend component to build this system. We could use Typescript, which the team is already using, or we could Python, which other teams are already using. We believe that because we use Typescript on the frontend, we will be able to work faster in this language. However, this means we will not be able to use some of the libraries that we’ve built in Python.”

• Expresses preferences. Given that you're surfacing tradeoffs and aiming to choose a solution, the tech plan should also indicate which solution(s) you're most interested in and why. Often multiple solutions are roughly equal in terms of cost and benefit, but the team probably has a preference about which one to build. If there's no obvious winner, say so. If you have a favorite, include some details about why you think it's the best, and recognize that it's okay to propose something based on a feeling, as long as you make that explicit too. Have an opinion, but be willing to change your mind with new information.

  • Example: “Given the tradeoffs listed above, we prefer to use Typescript over Python. We do not expect to use this system for more than 6 months, so we think the efficiency improvement is worthwhile.”

• Establishes a timeline. The best tech plans are those that you turn into action plans for others on the team to run with. A big input in deciding which solution to build is time and complexity, so the plan should provide a breakdown of the major components required to deliver along with the sequencing and timing for delivering them. This part of the plan also establishes another vector for teammates to ask questions and apply 80/20 thinking to potentially arrive at simpler/faster solutions. Ideally, once the team aligns on a direction, you capture the timeline in your project management tool as well.

  • Example: “We’ll have a proof of concept of this system ready by the end of next week. Then we plan to have the first product milestone shipped on top of this system 4 weeks later. We should be ready to launch our private beta 1 week after that.”

• Includes a test plan. A tech plan should not only establish how you're going to solve the problem but also how you will show that you solved it. You're building a feature, so you should feel confident that you know how to verify that the feature works. At the very least, a tech plan should include a breakdown of how to verify that the happy path works as expected, but ideally, you also think through critical edge cases for the user's experience. The more specific you are about how to test, the easier it will be for the team to execute ahead of launch. You can always link to an external doc or come back and add more as you discover more during the build. This part of the tech plan should guide others (even potentially non-technical teammates) on how to show that the solution works as intended.

• Is shared. We don't make technical decisions in a vacuum—the choices one team makes will affect other teams now and in the future. You should consider each tech plan an RFC that invites dialogue, driving the team toward a solution that balances the needs of the team with the needs of the overall engineering organization and the business. Share your plan within your team initially, then with members of your group and other adjacent teams that may have other ideas or subject matter expertise to contribute.

Ready to get started tech planning? Try it for the project you're currently working on and see where it takes you!