Decentralizing Decision Making with Shawna Martell & Dan Fike
- Aisha Washington
- 2 hours ago
- 7 min read
Engineering organizations often say they want teams to move autonomously. In practice, decisions still drift upward, stall in meetings, or depend on whichever senior architect happens to be available. Shawna Martell and Dan Fike describe a different model developed at Cartek: establish an explicit engineering strategy, then empower trusted technical leaders—called Navigators—to help teams apply it.
Their approach treats decentralization as more than delegating authority. People need shared principles, enough local context, access to experienced advisers, and a way to challenge or improve the strategy. When those pieces work together, individual contributors can make consequential decisions without forcing every question through management or a centralized architecture function.
Why Autonomy Requires an Engineering Strategy
Martell and Fike trace the Navigator program to a recurring problem: engineers wanted clearer guidance. Without an agreed framework, teams could not reliably judge competing technical options or know which organizational priorities should prevail.
The result was not necessarily bad engineering. It was inconsistent engineering. Two teams facing similar trade-offs might reach incompatible conclusions because each used a different, mostly implicit standard. The same debates resurfaced repeatedly, consuming time without producing durable organizational knowledge.
Centrally approving every choice would have addressed inconsistency by creating a bottleneck. Instead, Cartek sought to make the basis of good decisions widely available. Its engineering strategy became a shared reference point—a documented account of how the organization evaluates trade-offs and what it tends to value in particular circumstances.
Crucially, the strategy emerged in response to engineers asking for context. Martell and Fike do not present it as a mandate invented in isolation by executives. Its purpose was to give contributors the confidence to act while keeping their choices connected to a broader direction.
Start with Reality, Not an Aspirational Poster
A notable part of Cartek’s process was its emphasis on documenting how decisions were already being made. The team did not begin by describing an ideal future organization. It first examined the current state, including practices that appeared inconsistent or difficult to defend.
This kind of organizational archaeology matters because every engineering group already has a strategy, even when nobody has written it down. It lives in repeated choices: whether teams optimize for immediate performance or future scale, accept operational complexity to increase flexibility, or extend an existing system instead of creating a new service.
Past design documents and architecture decision records can expose these patterns. A useful record captures the alternatives considered, the benefits and costs of each, and the reason one option prevailed. Several records viewed together reveal the values behind those choices.
Martell and Fike distinguish those values from the decisions themselves. A decision says what happened in one case. A principle offers conditional guidance that can travel to another case—effectively, “When these conditions apply, favor this response.” Extracting such principles may require revisiting the people and circumstances behind older decisions, especially when documents record an outcome but omit its rationale.
Starting honestly also makes change measurable. An idealized strategy may sound inspiring while concealing the distance between policy and practice. A description of the real system creates a baseline from which the organization can deliberately become better.
Navigators Help Teams Read the Map
The program’s name captures an important division of responsibility. The engineering strategy functions like a map; Navigators help people interpret it in unfamiliar terrain. They contribute to the strategy, but their primary role is not to issue a master plan or personally decide every technical question.
At the time discussed, roughly a dozen Navigators supported an engineering organization of about 400 people. They came from several technical disciplines, including front-end and back-end engineering, reliability, and security. Their positions in the formal hierarchy varied: some worked deep within teams, while others operated closer to senior leadership.
Selection depended less on title than on demonstrated judgment, technical depth, and influence. Martell and Fike describe an informal network that exists alongside the management chart. Certain engineers naturally become the people colleagues consult when a problem is ambiguous. The Navigator model recognizes and connects those trusted figures rather than assuming authority flows only through reporting lines.
Navigators need substantial context about the products and systems around them. They should know which decisions are underway, recognize when work conflicts with the strategy, and intervene when a team needs help. That does not mean taking control. A Navigator can coach the team through the trade-off, identify relevant principles, or bring an unresolved issue into the broader Navigator group.
They also carry information in both directions. Strategy helps teams make local choices, while the difficulties teams encounter reveal where the strategy is incomplete. Navigators are therefore both interpreters and important contributors to its continuing revision.
Advice Without an Architecture Bottleneck
Cartek intentionally avoids making a formal architect the compulsory gateway for technical decisions. Staff engineers may perform architectural work where needed, but the organization does not want a permanent role that concentrates decision authority in one place.
Instead, its model resembles an architecture advice process. An engineer may make a decision after consulting the people affected, colleagues with relevant experience, the written strategy, and a Navigator when necessary. Authority remains distributed, but consultation is expected.
The strategy serves as a collective source of advice. It gives even less-experienced engineers a standard against which they can test a proposal. For example, it can clarify how the organization weighs performance against scalability or maintenance cost against speed of delivery.
Not every question can be reduced to universal guidance. Martell and Fike mention choices such as whether a capability belongs in an existing monolith or warrants a new service. An organization may have a general direction without a rule precise enough for every situation. In those cases, the strategy should acknowledge the ambiguity and direct engineers toward informed consultation.
This preserves judgment instead of replacing it with bureaucracy. The goal is not to encode every future answer. It is to make routine choices easier, expose genuinely difficult ones, and give people a consistent way to reason about exceptions.
Strategy Should Become Incrementally Less Wrong
Martell and Fike frame strategy as an evolving instrument rather than a finished doctrine. Initial principles will contain gaps. Some will be too broad, while others may fail under conditions their authors did not anticipate.
Real decisions supply the feedback needed to improve them. Teams compare an option with the strategy, discover where the guidance helps or breaks down, and report that evidence through their Navigators. Over time, both the individual decisions and the shared framework can become less wrong.
Allowing limited ambiguity is part of the design. Teams still need room to develop local “micro-strategies” suited to their systems and constraints. Navigators help ensure those local approaches remain compatible with the organization’s larger direction without forcing every team into an identical implementation.
The Navigators’ relationships with one another strengthen this feedback loop. They do not collectively own every decision, but they can consult peers when a problem crosses domains. Their mix of broad organizational awareness and deep specialist knowledge is particularly useful for concerns that span security, reliability, platform architecture, and product development.
Decentralization Is Also a Mentoring System
Distributing authority only works if more people learn how to exercise it. The Navigator role therefore includes an implicit responsibility to teach: how to identify trade-offs, seek appropriate advice, document reasoning, and decide with incomplete information.
This is especially important for engineers who have not previously been trusted with high-impact choices. Telling them to “take ownership” is insufficient if every consequential proposal is later overruled by an inaccessible senior group. Navigators can make the reasoning process visible and support contributors while leaving the decision close to the work.
Martell and Fike also separate the Navigator lens from the management lens. Managers must balance people, delivery, and team execution. Navigators provide deep technical judgment and connect local engineering choices to organization-wide strategy. The two perspectives should complement one another rather than collapse into a single role.
Candidates are recognized through their existing contribution and nominated by senior leaders rather than applying through a conventional process. Technical credibility alone is not enough. Someone unwilling to develop others or share judgment would struggle to fulfill the program’s purpose.
Measuring Success Through Better Decisions
The value of decentralization appears in concrete decision outcomes. Martell and Fike describe a team considering a new shared platform service for a problem seen across multiple domains. A superficially reasonable response might have been to build a universal solution and begin a lengthy effort to secure agreement from every stakeholder.
A Navigator compared the proposal with the organization’s strategy and concluded that a one-size-fits-all platform was not the preferred direction. Because the strategy already represented an agreed default, the Navigator could resolve the issue without rebuilding the entire argument from scratch.
This illustrates a meaningful shift in the burden of proof. Instead of advocates repeatedly persuading others that one direction is correct, the documented strategy supplies the starting position. Departures remain possible, but they require a compelling explanation.
Useful indicators of progress include faster decisions, fewer unnecessary escalations, clearer reasoning in design documents, and greater confidence among contributors. Qualitative signals matter too: engineers should feel less lost, and recurring debates should increasingly produce reusable principles rather than another temporary compromise.
How Engineering Leaders Can Begin
Martell and Fike are clear that appointing Navigators before articulating a strategy is unlikely to work. Without a shared map, trusted individuals may simply distribute their personal preferences more efficiently.
Leaders can begin by reviewing past architecture decisions and current design documents. They should identify recurring trade-offs, write down the least controversial principles first, and examine the gap between stated values and observed behavior. Discomfort with that record is useful evidence: it points to practices the organization may want to change.
A practical sequence is to:
document representative decisions and their reasoning;
extract conditional principles from recurring patterns;
identify areas where current practice conflicts with the desired direction;
find respected technical contributors who already advise others;
place those people where they can connect local work with organizational strategy;
revise the framework as real decisions reveal omissions or contradictions.
The deeper lesson is that decentralization depends on infrastructure for judgment. Written principles provide consistency, Navigators supply context and mentorship, and teams contribute the evidence that keeps the system grounded. Together, those mechanisms let authority move closer to the work without allowing the organization to fragment into incompatible technical directions.
