Why tech planning is worth your time

Planning ahead leads to better execution

PublishedMarch 28, 2023

I'm an engineering leader with experience running product and growth teams of many sizes. I'm currently focused on product and growth at Vanta.

Comments (5)

Join the discussion

Anjali Pant3y ago

As a developer, I always thought that planning before executing is not worth of time- this always happened to me whenever I tried to go for implementation, and the results were always negative. Reading this blog changed my thinking pattern and helped in getting good output as success.

Anthony Fung3y ago

I used to think so too. I now think of it like this: a project will take a certain amount of time, e.g. 1 week. I can either:

Spend a day upfront doing some planning, and then four days of implementing, or
Jump straight in and start implementing. I'll finish in 3, but then spend a 2 or more days rearchitecting the solution, or rebuilding it because of misunderstandings in the original design and/or requirements.

islam sulaiman3y ago

What planning tool do you prefer the most for mid level software projects? Clickup, Jira or Trello

Todd Royal3y ago

I don't have a specific project management software I prefer. I've used many at various sized organizations, Asana, Jira, Trello, Linear, Bugzilla. My advice is to go with whatever works for your company (it might be what you already use), and don't fight against the way the tool wants to be used.

Rafael dos Santos Miguel Filho3y ago

It is a very important subject indeed, touching on this subject is essential especially for developers who work directly on highly complex products, planning will always be essential.

Zack Somas3y ago

Great post! As developers, we tend to miss this part because of time constraints. But I think it helps to slow down a little bit and do the tech planning first.

Thanks for writing this.

Anthony Fung3y ago

I too know of people who love to just dive straight into writing code, but I completely agree that at least some form of planning upfront is worth it.

It’s very much like writing unit tests: by writing them, it makes us think in different ways that the system could operate. As a result, we might include additional handling for different use cases that we may not have otherwise thought of. The same is true with a project plan too.

When it comes to system design, I also think it’s helpful to draw up some diagrams. Architectural diagrams help with design and modularisation, and sequence diagrams can show how the systems will communicate with each other.

Once we have those, we have a clear direction and (as mentioned in the article) can move much faster as a result.

Gemma Black3y ago

I too know of people who love to just dive straight into writing code, but I completely agree that at least some form of planning upfront is worth it.

Definitely agree planning is needed. I love technical plans. Even for solo projects, I forget most of what I was doing, so to be able to read through them and get an understanding of the solution and design is invaluable for my future self :)

For me, I must admit that the fine balance is how much is too much or too little.

Too much planning can be costly because you can spend so much time planning, only to realise the plan is too rigid and you have to deviate from it. So I totally agree, focusing on the problem first and then overall design helps to prevent going into the implementation too much beyond the architecture.

Too little planning has been so costly, especially with a team - it's hard for everyone to move forward at pace with no vision to follow. 100 agree.

So I love planning up front, but I've learned I need to not go too far with it. I should incorporate more sequence diagrams into my plans though.

Anthony Fung3y ago

Gemma Black Yes, you're right. Much like everything else in software development, how much to plan is a delicate balancing act.

It's a bit like writing tests. Too little and making changes becomes scary as there's no safety net; too much and it takes too long and makes requirements changes painful.

I think the more we collectively do, the better we are to judge where the optimum point is.

More from this blog

Four steps to building engaged engineering teams

Note: This article was originally published for Intercom's blog in August 2020. I am republishing here for visibility and ongoing maintenance. Engaged teams are the backbone of a healthy organization. When you’re on a team that is highly engaged, the...

Apr 13, 20237 min read

Four steps to building engaged engineering teams

✌️ Todd Royal

2 posts

I'm an engineering leader with experiencing running teams of many sizes. Most recently I led revenue teams at Discord and growth teams at Intercom.

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!

Command Palette

Comments (5)

More from this blog

What is tech planning?

Why is tech planning important?

When should tech planning happen?

What goes into a tech plan?