The staff+ playbook for derisking big decisions

Estimated reading time: 8 minutes

Key takeaways:

• Not all technical decisions are reversible: staff+ engineers must treat strategic bets differently from everyday code changes.
• Invest where it compounds: align architecture with business strategy, team strengths, and long-term velocity.
• Derisk big bets by building alignment early: architecture is a team sport, not a solo call.

As staff+ engineers, “it depends” is practically our catchphrase. We know that most of the time, the best choice will depend on the context, goals, and constraints at the time. 

Software is infinitely malleable. Most of the time we can change our choices if the circumstances change. Code can be refactored, modules reorganized, and libraries replaced.

Some decisions are harder to reverse. What languages or frameworks do we use? What investments do we make? When do we rewrite or break up a monolith?

These are the strategic choices that we are often tasked with making. How those decisions play out can determine how successful we are in our role. Choices that anticipate future needs can accelerate the business, while others can cause months or years of drag and toil.

How do we make these strategic, hard-to-reverse decisions wisely? Staff+ engineers need to build a broad understanding of how our organizations operate and evolve. We need to understand the mission and strategy of the company, the revenue and cost drivers of the business, how our product and engineering teams operate, and how our teams spend their time.

When should we make an investment?

Deciding to take time away from our near-term velocity to make an investment in future velocity is one kind of decision that may be hard to reverse. The time and money cannot be recovered, once spent. Partial investments – refactors and new systems – can leave our teams worse off if they need to navigate a codebase permanently split between two ways of operating.

These kinds of investments often take the form of new automations or abstractions that streamline common cases, in exchange for making rare cases more expensive.

Making a case for this kind of project should address a few core issues:

• Accelerate or improve the reliability of a common task. The amount of time saved needs to align with the amount of time taken, so the more frequent the activity, and the bigger the speed up, the better. Building systems that can empower other teams to act safely without engineering time at all are particularly compelling, since they eliminate a time sink and enable those teams to move more nimbly.
• Build on organizational expertise. The decision to build a system, rather than use an off-the-shelf solution, is often based on an underlying assumption that the system is something we know well-enough to build effectively. The more cross-functional expertise we have in something, and the more it is a core competency of the business, the better positioned we are to make good judgement calls about what tradeoffs to make.
• Be explicit about which trade-offs it makes. When designing new systems, we have to create the interfaces that consumers will use, and what functionality those interfaces will expose. This means choosing which functionality is available or easier to access, which changes the cost structure of future decisions. For example, design systems make it easy and fast to build user interfaces that are consistent, and make unique UI moments relatively more expensive.
• Be a well-organized project. It is easier to get leadership to say yes (and to build buy-in with engineering teams) on a project that is time-bound, has a clear definition of done – even if that just means having a base to keep building on – and provides at least some benefits as soon as possible.

Investing in core activities and core competencies of the business means that these are usually not upfront investments. This kind of expertise and context takes time for the organization to build, learning from smaller steps, and missteps, along the way.

For example, most large publishers have built their own content management and design systems. Even though many off-the-shelf content management system products exist, for these organizations, authoring and publishing content to the web is a core competency.

Building on that organizational expertise, publishers are able to make unique trade-offs to support their content strategy that more generic solutions cannot.

Which investment should we make?

Deciding between multiple paths that all require investing time is another hard-to-reverse choice. The further we get along one path, the more time we have already spent on it, the harder it will be to make the decision to start over. This isn’t purely because of sunk cost: the additional time to restart will need to outweigh the costs of finishing and using what we already have, even though it isn’t ideal.

A particularly challenging aspect arises when deciding whether to invest in people or tooling. On a previous team of mine, we needed to choose a language for some new backend services. The engineering org had built significant tooling around one language (in this case, Go) while the team members had experience in Node.

We needed to choose between investing time in building and maintaining at least some of the tooling and operational expertise in a new language – and potentially gaining it as a choice for the org as a whole – or investing in cross-training and mentoring the team in a new language, relying on the existing tools and expertise.

Another challenging decision many teams face as they mature and grow is whether to invest in, or break up, a monolith or to rewrite an aging system that is not scaling well. Both paths will require building new tools, processes, and expertise in maintaining and operating a new architecture at a new scale.

Some things to consider when forming an opinion on this kind of question:

• Existing expertise on the team. What does the team already know? What technology choice would be the safe, ‘boring’ one? It is much easier to pick a new direction when there is an existing critical mass of skills to support that direction.
• Hiring markets. Staffing can be one of the hardest-to-reverse decisions. Hiring is extraordinarily expensive, and firing (or managing out) can take months. The choice to enter a new hiring market, for example to tap into a larger talent pool, may take years to pay off.
• Operational complexity. Larger, more mature teams tend to mean larger, more complex software systems. How those systems interface and interact balances different needs and benefits. For example, microservices tend to emphasize strong interfaces, encapsulation, and proactive failure management. Meanwhile, monoliths emphasize reliability, flexibility of interfaces, and shared context. Each choice has its own complexity beyond the inherent complexity of the product itself.

Derisking strategic architectural choices as staff+ engineers

Strategic architectural choices have an outsized impact. They can affect the makeup of the team for years. The tradeoffs they make today will change the decisions future team members will need to make. With that impact in mind, we should be deliberate about derisking and understanding the impact of these choices.

Here are four major areas of risk to consider and attempt to mitigate. This may not be an exhaustive list in all cases, but it is a useful starting point and familiar to many product teams.

1. Value risk. How will each available path provide value to the business? Will common tasks speed up? Will new workflows become possible? Will our teams be able to execute the business strategy more effectively?
2. Usability risk. Will each path be something that the team is able to make use of? Are there additional investments that we will need to make, for example new developer tools or automation, to support our teams?
3. Feasibility risk. Can we do each path? Are there unknowns about whether a path will even work? Can we provide the necessary support and training to the team to enable them to be successful?
4. Business viability risk. Does this path require investments that the business can actually make? Can we afford to slow down some day-to-day work for now to speed it up later? Will we be able to hire, or will we need to hire, to support this path?

London • June 2 & 3, 2026

LDX3 London agenda is live! 🎉

See lineup

Identifying the impact of strategic choices

The impact of strategic choices often spreads over years, and may not be immediately obvious. Part of the role of a staff+ engineer is to build buy-in and momentum for these choices by identifying validating examples and sharing them, both internally and with leadership.

During the first steps of a strategic decision, staying close to the work not only helps keep it on track, it gives us an opportunity to observe those moments.

For example, at a previous employer in the insurance space, we decided to build software to make it faster for us to build and validate customer- and employee-facing forms, with the intent that, eventually, engineering would not need to be involved in most cases.

Early on, well before the vision was realized, an engineer shared that a development task was completed in a couple of hours that previously would have taken several days. That anecdote and quote helped validate with leadership that we were on the right track, and helped sell the opportunity to other engineers or teams that were skeptical about his new direction.

Gathering hard data can be difficult, since we often have to look at before/after a change, rather than running parallel experiments. Recording and sharing anecdotal feedback from cross-functional stakeholders impacted by an architectural choice can help assess how the decision is going and build social proof and momentum among hold-outs.

Collaborative decision-making for staff+ engineers

While staff+ engineers are often accountable for making strategic architectural choices with significant impact, we do not need to make them alone. Gathering input and feedback from stakeholders – other technical leaders, engineers, cross-functional partners, and leadership – and sharing the derisking work before committing to a path can help build an early consensus or identify issues that may make us pivot.

Software engineering is a team sport, especially when we are making decisions that may impact dozens of people over the course of several years. Staff+ engineering can be a high pressure role. Building together not only helps us feel more supported and less alone, it helps us leverage the wisdom of the whole organization and make better choices.