Managing High-Performing Senior Teams

01/ The Tactical Resolution

The Case Study: The Clash of the Staff Engineers

The Problem

When I inherited the Core Infrastructure squad, it was composed of five Senior Engineers, two Staff Engineers, and zero juniors. On paper, it was a dream team. In practice, it was a gridlock.

We needed to rewrite our ingestion service. One Staff Engineer, Dave, was a Rust enthusiast who wanted to build a custom memory-mapped message broker. The other, Sarah, was a Go purist who argued that a standard Go service on top of Kafka was more than sufficient and significantly easier to maintain.

Both were brilliant; both were right in different contexts. But because they couldn't agree, the project stalled for six weeks. PR reviews became battlefields of pedantic comments, design meetings ran in circles, and morale began to sour. As their manager, if I stepped in and made the choice arbitrarily, I would lose the trust of one side. If I did nothing, we’d miss our product launch window.

The Playbook: The Council of Architects

Seniors do not need task management; they need context, clear boundaries of ownership, and structural guardrails for decision making.

Step 1: The Principle of "Single Threaded Ownership"

Egos clash when boundaries are blurry. Every major initiative must have one—and only one—Directly Responsible Individual (DRI).

• The Rule: Dave is the DRI for the ingestion pipeline’s data storage structure. Sarah is the DRI for the API integration layer.
• What this means: While they must consult each other, the DRI has the ultimate executive tie-breaking vote for that domain. If Sarah disagrees with Dave’s storage model, she can voice her opinion, but she must ultimately defer to Dave’s DRI status.

Step 2: The RFC & Business Matrix Decision Loop

When a deadlock occurs, force the discussion out of Slack and code reviews and into a structured document.

1. Co-authored RFC: Have the disagreeing parties collaborate on a single Request for Comments (RFC) document. They must list Option A and Option B side-by-side.
2. The Constraints Matrix: Score the options using a business-oriented matrix (not just developer preference):

| Evaluation Metric | Option A (Rust Custom) | Option B (Go/Kafka) |
| :--- | :--- | :--- |
| **Operational Complexity** | High (Custom operational runs) | Low (Industry standard patterns) |
| **Time to Market** | 12 weeks | 4 weeks |
| **Throughput/Cost Ratio** | 98% efficiency (Cheaper hosting) | 85% efficiency (Standard pricing) |
| **Team Skill Match** | 1 engineer knows Rust | 6 engineers know Go |

Once laid out like this, the choice becomes a business decision, not a personal one. Go/Kafka won because "Time to Market" and "Team Skill Match" outweighed the slight runtime efficiency of Rust.

Step 3: Peer-Led Code Ownership Review

To prevent gatekeeping, establish that no code review should focus on stylistic preferences. Use automated linters for syntax, and enforce a "Strong opinion, weakly held" culture. Introduce a rule: if a code review comment is stylistic or architectural preference and doesn't affect correctness, safety, or scalability, it must be prefixed with Nit: and cannot block a merge.

The Long-Term Impact

• Resolution Velocity: The ingestion rewrite choice was resolved within 48 hours of introducing the RFC Matrix.
• Collaboration: By separating ownership into distinct DRI blocks, Dave and Sarah stopped competing and started collaborating, leading to Go code running Kafka with Rust-based parser plugins where memory optimization was actually needed.
• Morale: The team felt their voices were heard, but appreciated the clear decision framework that saved them from perpetual analysis paralysis.