Accelerating Technical Decision-Making by Empowering ICs with Engineering Strategy

As organizations grow, maintaining communication channels between individual contributors (ICs), managers, and executives is vital. At Carta, we have harnessed the power of a small group of senior engineers to bridge the gap between global strategy and local decision-making. We call this group the Navigators.

We combine a written engineering strategy with our Navigators, who help teams interpret the engineering strategy within their domains. Navigators replace a need for consensus and boost velocity by combining technical context, domain context, strategic alignment, and judgment to make engineering decisions quickly.

Technical Decision Making is Challenging

The simple mechanics of decision-making lie between "individuals operating unilaterally without even realizing which decisions they’ve made" and "executive decision makers that hold court periodically as opposing counsels pitch their options."

We’ve seen both extremes, and you’d be unsurprised to hear that you want to be somewhere in the middle. Perhaps more interesting than decision-making physics is the examination of why, in any given system, some decisions can be more challenging than others, even decisions whose outcomes carry equal weight.

More often than not, the extra-challenging decisions result from misalignment on A) who is making the decision or B) what the actual decision we’re making is.

Sometimes, people involved in a decision don’t know who is authorized to make the final call. This might be because those involved are uncertain. Or it might result from individuals seeking to abdicate responsibility and accountability to others. Or it might be a fear of including others and forcing more compromises. Often, those involved don’t know who is authorized to decide because nobody is, in fact, actually authorized to do so.

Alternatively, consider two people trying to decide between two actions:

1. Store our data across 10 different columns in a Postgres table.
2. Store our data in a single JSON column in a Postgres table.

In reality, they might not be deciding on the action but instead are deciding on which principles to apply:

1. If we expect to iterate new features here frequently, we should ensure they exist independently so they do not impact one another.
2. If we expect to iterate new features here frequently, we should ensure compatibility between our code and table schema is maintained easily.

But even that decision might instead be a proxy for trying to decide what situation you’re in:

1. We expect to iterate new features here frequently.
2. We do not expect to iterate new features here frequently.

It’s hard to decide with conviction when people are not aligned on who the decider is or the real decision basis.

The Inputs to Technical Decisions Aren’t Just Technical

So many things influence technical decisions, and many of them aren’t even technical. You need to make sure you’re considering your existing architecture patterns and preferred programming languages and performance needs, but you must also account for staffing, cost, and market conditions.

There are situations where the "clear" technical choice isn’t workable for various reasons. Imagine you have a problem that could be very trivially solved with Rust. However, none of your engineers know Rust, and you have no mechanisms for building or deploying applications using Rust, but your existing infrastructure supports JavaScript. So maybe Rust isn’t so trivial after all. When making technical decisions, we must account for all the constraints, not just the technical ones.

Most technical choices of any objective complexity have only one real answer: "It depends." Those dependencies can be hard to reconcile. Should we optimize for cost or performance? Maybe we should just buy something off the shelf? There’s no one right answer for every company or every circumstance. This is where our engineering strategy has provided a lot of value. The engineering strategy allows us to document what tradeoffs the organization wants today, allowing us to reconcile those dependencies more quickly.

When faced with many inputs, ensuring all those factors are accounted for and the dependencies appropriately resolved can be challenging. This is one reason we’ve found it essential to have a clear decision-maker responsible and accountable for ensuring that our decisions align with the company’s opinion on reconciling tradeoffs.

Previous Approaches to Making Technical Decisions at Carta

In our careers, we’ve seen several approaches to technical decision-making; like most things, there are tradeoffs.

Sometimes, highly autonomous teams are empowered to execute with little oversight. This works well when siloed projects need to move quickly. It gets harder when you need to maintain interoperability or move across team boundaries. Other times, decisions require wide consensus across many teams, and consensus gets pretty expensive, especially as organizations grow.

Over the years, Carta has tried a few variants of centralized decision-making bodies responsible for considering proposals and ensuring some degree of consistency across teams and projects. We started with something casual: a regular meeting with senior engineers to get open feedback. And while feedback is valuable, it’s not a decision. Engineers would leave the meeting unsure what to do next or how to reconcile conflicting feedback from different leaders.

We later transitioned to something more structured: a committee with a curated membership that could review and approve the most complex decisions. While these bodies provide for clear decision-makers and regular accessibility, the committee members were often too distant from the work to be able to provide direction consistently. Engineers would find themselves having to return to the committee multiple times, and eventually, the committee became a thing engineers wanted to avoid altogether.

Whether decisions are made using a highly centralized or decentralized approach, there is often a lack of shared principles guiding technical decisions, which can result in decisions that feel arbitrary or unfair.

With the Navigators approach, we enable an autonomous decision-making model while providing a clear set of shared principles to guide our decision-making via our Engineering Strategy.

The Navigators Pattern

Carta has 12 Navigators for our ~400-person engineering organization. Those Navigators are directly accountable to the CTO. We maintain a one-to-many relationship between Navigators and Engineering teams. Every team is in scope for exactly one Navigator, so there’s never uncertainty about who the Navigator is for a given project. These Navigators serve three sets of people in different ways.

First, they serve the engineers and managers on their assigned teams. Navigators are engineers and members of the same teams they serve. They have and maintain a clear understanding of their team’s work and challenges. They balance that with the company's needs and challenges more holistically to make decisions locally that minimize disruption to the team while optimizing for the company.

Second, they serve the engineering executive. While Navigators exist as engineers within the company’s standard org chart, they also sit near the root of a hypothetical second "influence org chart." They connect directly to our executive and act as influential multipliers to carry the executive’s voice deep into the org chart. In turn, they can also carry the voice of engineers up to the executive. This shortcut of information flow does not relieve our directors and managers from doing similar work; instead, they tend to cover different (though overlapping) sets of information and context that are key to making good decisions at all levels. This plays out in situations like roadmap planning. A navigator’s technical knowledge can help them identify dependencies that might not be immediately obvious to management or the product.

Finally, the Navigators serve each other. While they don’t operate as a collective or committee, they support each other with additional context, perspective, or feedback. They’ll also often collaborate to make decisions that intersect multiple projects or teams.

How Engineering Strategy Supports Navigators

We just discussed above how Navigators help teams make decisions that align with wider company priorities. Our Engineering Strategy is a carefully crafted summary of decision-making principles that, when applied, achieve that outcome. Our strategy helps our Navigators make decisions, and it helps others understand and accept those decisions, as the Engineering Strategy carries the authority of our engineering executive. We’d argue it actually helps us skip the decision entirely, as it often leaves no doubt about how to proceed.

This might help an engineering team understand where we can accrue tech debt and where we cannot. It might help an Engineering Manager and Product Manager understand when to prefer consistency over performance. It might help an Engineering Director understand when to generalize a solution into a platform utility.

The concept of "strategy" can feel pretty abstract, so here are a couple of examples from Carta’s engineering strategy:

• The best platform solutions enable simplicity, not complexity, and they are built simply
• Prefer "buy" over "build"

When making a decision about architecture or sequencing, focusing on simplicity for both the solution and its customers can make those decisions much easier. To put it simply, our Strategy is the principles or guidance that drives our decision-making.

Creating a compelling and succinct strategy is complex, and Navigators help teams navigate through edge cases where the Strategy seems to apply, but the direction needs to be clearer. There’s always room for interpretation. Sometimes, our strategy’s guidance is "Do X, not Y. Exceptions can be approved by the CTO." The Navigator is typically well-equipped to determine if it is worth pursuing an exception.

Impact and Benefits of Navigators

Beyond the accomplishments we described above, Navigators has also provided some unexpected benefits. Our engineers appreciate a clear contact for input and advice, which is less intimidating than a manager. Shawna has had several cases where an engineer from one of the teams she’s navigating would approach her with a question they felt was too silly to take to their manager. Shawna doesn’t write their performance review, so she was a "safer" choice for a potentially silly question. These always turn out to be completely reasonable questions; we’re glad they get asked!

Engineers are also pleased with much faster decision-making. It makes their work less laborious. They don’t feel like decisions are frequently relegated, as was sometimes the case with pre-navigators.

Finally, the written strategy has offered all our engineers a new tool for making decisions and communicating priorities. You don’t have to be a Navigator to leverage the strategy, and we have seen multiple examples of our engineers using it in their day-to-day work.

Conclusion

A written strategy combined with a dedicated group of senior ICs who act to apply that strategy within their teams can decentralize decision-making, reduce the need for consensus, and increase velocity in decision-making.

We’d encourage everyone to start by writing an engineering strategy, no matter where they sit in the organization. Individual contributors can begin with their team’s strategy and become the Navigator locally, teaching others how to use it to make decisions. Executives and other senior leaders can assemble the thought leaders in the organization and collaborate on the strategy. ICs who feel ownership of the strategy will feel more empowered to leverage the strategy to make decisions.