Chapter 29: Cross-Team Technical Leadership
leadership, influence, cross-functional, stakeholder management, organizational navigation, technical advocacy
Introduction
In late 2022, a major financial services company launched an initiative to deploy large language models across its organization. The AI platform team had built an impressive internal system: a managed inference service, a prompt management platform, and a comprehensive evaluation framework. Technically, it was excellent work. Six months later, adoption was at 12%. Product teams continued building their own solutions, the data science group had chosen a different stack, and the customer service division had contracted with an external vendor for their chatbot.
The platform team’s lead engineer was bewildered. “We built exactly what they asked for,” she told me. “The technology is objectively better than what they’re using instead.” She was right about the technology. But technology was never the problem. The initiative failed because it was designed, built, and launched by one team without meaningful collaboration from the teams expected to adopt it. There was no shared ownership, no early involvement in design decisions, no consideration of each team’s unique constraints and priorities. The platform was handed down rather than built together.
This pattern repeats across organizations attempting to scale AI capabilities. A central team builds infrastructure. Other teams resist adoption. Leadership mandates compliance. Engineers find workarounds. The organization ends up with fragmented systems, duplicated effort, and lingering resentment.
Cross-team technical leadership is the discipline of driving initiatives that span organizational boundaries. At the staff and principal level, your impact depends less on what you personally build and more on how effectively you can align diverse stakeholders, establish standards that others willingly follow, and create the conditions for organization-wide success. This is fundamentally different from leading within a single team. You have no direct authority. People don’t report to you. Success depends entirely on influence, communication, and building genuine consensus.
This chapter explores the principles and practices of cross-team leadership, with particular attention to why AI initiatives present unique coordination challenges and how to navigate them effectively.
Why AI Initiatives Demand Cross-Team Leadership
AI projects are inherently cross-functional in ways that traditional software projects are not. Consider what’s required to deploy a production AI system:
Data dependencies span the organization. Training and fine-tuning require data from systems owned by other teams. A recommendation system needs user behavior data from the product team, transaction data from the commerce team, and content metadata from the content team. Each data owner has their own priorities, privacy concerns, and technical debt.
Expertise is distributed. The machine learning engineers who understand model architecture aren’t the same people who understand the business domain, and neither group necessarily understands production infrastructure at scale. Effective AI systems require sustained collaboration across these specialties, not handoffs between siloed teams.
Risk is shared but ownership is unclear. When an AI system produces harmful outputs, who is responsible? The team that trained the model? The team that deployed it? The team whose data was used? The product team that integrated it? This ambiguity creates organizational friction and makes teams reluctant to participate in shared initiatives.
The technology is rapidly evolving. In traditional software, you can often make architectural decisions and live with them for years. In AI, the landscape shifts quarterly. What was state-of-the-art when you started may be obsolete by launch. This creates pressure to continuously reassess and realign across teams.
Outcomes are probabilistic. A well-designed software system generally works as intended. AI systems have inherent uncertainty. The same model can perform brilliantly in one context and fail unexpectedly in another. This makes it harder to set expectations, define success criteria, and assign accountability.
These characteristics mean that AI initiatives cannot be successfully executed within a single team, no matter how talented. They require sustained coordination across organizational boundaries. And that coordination is the job of cross-team technical leaders.
What You’ll Learn
This chapter covers:
- Influence without authority: How to build the credibility and relationships that enable you to lead when you don’t have organizational power
- Consensus building: Frameworks for achieving alignment among stakeholders with different priorities, constraints, and incentives
- Technical standards creation: How to establish standards that people willingly follow rather than grudgingly tolerate
- Navigating organizational dynamics: Understanding power structures, managing up and across, and knowing when and how to escalate
- Decision-making frameworks: When to standardize versus allow variation, how to handle technical disagreements, and how to drive adoption of new capabilities
Prerequisites
- Technical foundation in AI/ML systems (Part II)
- Experience leading individual projects (Chapter 22)
- Technical communication skills (Chapter 23)
- Understanding of system design tradeoffs (Chapters 5-8)
The Theory of Organizational Influence
The Psychology of Resistance
Understanding why people resist cross-team initiatives helps you address the underlying concerns rather than fighting the symptoms.
Autonomy threat. Self-Determination Theory, developed by Deci and Ryan, identifies autonomy as a fundamental human need. When a central team imposes standards or platforms, other teams experience this as a reduction in their autonomy. The resistance isn’t necessarily about the technical merits; it’s about having control over their own domain. Smart cross-team leaders preserve autonomy wherever possible, offering choices within constraints rather than mandates without flexibility.
Not-invented-here syndrome. Groups tend to value their own solutions more highly than equivalent external solutions. This bias, documented extensively in organizational behavior research, is partly about autonomy but also about identity. A team’s technical choices are part of their identity. Asking them to abandon their solution for yours feels like a criticism of their judgment. Effective cross-team leaders acknowledge the value of existing work and frame new solutions as evolution rather than replacement.
Coordination costs. Adopting cross-team solutions often creates real costs: time spent learning new systems, effort to migrate existing work, and ongoing dependency on a team you don’t control. These costs are concrete and immediate while benefits are often abstract and future. Leaders who dismiss these concerns as parochialism fail to understand that teams are making rational calculations about their capacity. The solution is either to reduce the adoption costs or to make the benefits concrete enough to justify them.
Trust and reliability concerns. Teams reasonably worry about depending on systems maintained by others. Will the platform team prioritize my bug fix? Will they maintain backward compatibility? Will they still be around in two years? These concerns are especially acute in AI, where rapid evolution means today’s platform may be obsolete tomorrow. Building trust requires consistent reliability over time—there are no shortcuts.
The Structure of Organizational Networks
Cross-team leadership operates through organizational networks, and understanding network structure helps you work more effectively.
Research by Morten Hansen at Harvard and Berkeley demonstrated that organizations function as networks of relationships, not just hierarchies of roles. Some people occupy “bridging” positions connecting otherwise disconnected groups. These bridges are disproportionately valuable for cross-team initiatives because they enable information and influence to flow across boundaries.
Hansen’s research also identified “search costs” and “transfer costs” as key barriers to knowledge sharing. Search costs are the difficulty of finding relevant expertise in other parts of the organization. Transfer costs are the difficulty of actually transferring complex knowledge once you’ve found it. Effective cross-team leaders reduce both: they maintain broad networks (reducing search costs) and invest in relationships deep enough for effective knowledge transfer.
The practical implication is that building your network is not optional. You need relationships across the organization before you need them. The time to build connection to the infrastructure team is not when you’re blocked on a deployment issue; it’s months earlier, when you can offer to help with something they care about. The time to understand the data science team’s priorities is not when you’re asking them to adopt your platform; it’s before you even start building it.
Mental Model: The Influence Portfolio
Think of your organizational influence as a portfolio of relationships, each with its own “balance.”
For each relationship, you make deposits (helping them, sharing credit, providing information, supporting their initiatives) and withdrawals (asking for their time, requesting priority for your work, needing them to change their plans). A healthy relationship has substantially more deposits than withdrawals. A strained relationship has the reverse.
Unlike financial accounts, influence balances decay over time. Deposits made two years ago provide less current influence than deposits made last month. Relationships need ongoing maintenance.
The portfolio view helps you make strategic choices. Before launching a major initiative that will require significant support from the infrastructure team, check your balance with them. If it’s low, invest in the relationship first. Help them with something important. Demonstrate that you understand and value their work. Build the capital you’ll need before you need it.
This mental model also helps you avoid a common mistake: treating relationships transactionally. If you only engage with people when you need something, your deposits are actually withdrawals in disguise. People quickly recognize instrumental relationships and discount them accordingly. Genuine deposits come from authentic interest in others’ success, not from calculated investment in future leverage.
Building Consensus in AI Initiatives
“Four teams were each building their own LLM gateway. Same auth, same rate limiting, same logging, four different codebases. I called a meeting and got blown off three times—everyone was too busy maintaining the thing the meeting was about. So I just wrote a 6-page doc proposing a shared interface, attached it to a calendar invite I described as ‘optional review,’ and gave a hard deadline for written objections. Two teams pushed back in writing, we resolved it async in comments, and the spec was approved 11 days later. The meeting that didn’t happen was the one I’d been trying to schedule for two months. The doc that did happen moved everyone forward. Sometimes the right meeting is no meeting.”
— Staff Engineer at a developer infrastructure company
The Alignment Problem (Organizational Version)
In machine learning, the alignment problem refers to the challenge of ensuring AI systems pursue intended objectives. Organizations face an analogous challenge: ensuring that independent teams with different objectives coordinate toward shared goals.
This organizational alignment problem is particularly acute in AI initiatives for several reasons:
Uncertainty about outcomes. Traditional projects often have clearer definitions of success. Build a feature, ship it, measure adoption. AI projects have more uncertain outcomes: the model might not work well enough, or it might work technically but fail to deliver business value. This uncertainty makes teams reluctant to commit resources.
Long feedback cycles. Traditional software offers rapid feedback—deploy, measure, iterate. AI systems often require extended periods of data collection, training, and evaluation before you know whether the approach is working. This means teams must commit to collaboration based on projected rather than demonstrated value.
Evolving requirements. AI capabilities often reveal new possibilities not anticipated when the initiative started. This is good for innovation but challenging for alignment. Teams that signed up for one scope find themselves being asked to support an expanding vision.
Effective alignment isn’t about getting everyone to agree. It’s about getting everyone to commit to a course of action despite disagreements. The phrase “disagree and commit” captures this distinction. You need enough buy-in that teams will invest real effort, not enthusiastic agreement that may never come.
Consensus-Building Frameworks
The Interest-Based Approach
Roger Fisher and William Ury’s “Getting to Yes” introduced the distinction between positions (what people say they want) and interests (why they want it). Positional bargaining—where each party defends their stated position—often leads to deadlock or suboptimal compromises. Interest-based negotiation looks for solutions that satisfy the underlying interests of all parties.
In AI initiatives, this manifests as follows. A platform team’s position might be: “All teams should use our centralized inference service.” A product team’s position might be: “We need to manage our own model deployments.” These positions are in direct conflict.
But what are the underlying interests? The platform team likely wants: consistent security posture, operational efficiency, ability to enforce guardrails, career-building through visible impact. The product team likely wants: fast iteration, control over their roadmap, predictable performance for their use cases, ability to debug issues without dependencies.
Once you surface these interests, creative solutions become possible. Perhaps the platform team provides a self-service infrastructure layer that gives product teams deployment control while enforcing security requirements. Perhaps there’s a tiered model where high-risk applications use the managed service while lower-risk experiments have more autonomy. The specific solution matters less than the approach: understand interests, not just positions.
The Pre-Mortem Technique
Gary Klein’s pre-mortem technique asks teams to imagine that a project has failed and work backward to identify potential causes. Applied to cross-team alignment, this means asking: “Assume this initiative fails to achieve adoption. What went wrong?”
This exercise surfaces concerns that stakeholders might not articulate directly. Someone might not want to say “I don’t trust the platform team to maintain this,” but they might identify “the platform team got reorged and priorities shifted” as a potential failure mode. The pre-mortem creates psychological safety for raising concerns and helps the group anticipate and address issues proactively.
For AI initiatives specifically, valuable pre-mortem prompts include:
- The models didn’t perform well enough for production use—what would cause this?
- Teams started using the platform but abandoned it within a year—why?
- A major incident occurred related to AI usage—what happened?
- The project consumed significant resources but was cancelled—what led to that decision?
The Graduated Commitment Model
When stakes are high and trust is low, asking for full commitment upfront often fails. The graduated commitment model proposes small, reversible steps that build confidence over time.
For an AI platform initiative, this might look like: 1. Discovery phase: Platform team embeds with two volunteer product teams to understand their needs deeply. Commitment: 4 weeks of team time. 2. Prototype phase: Build a minimal solution for the two partner teams only. Commitment: one quarter. 3. Pilot phase: Expand to 3-5 teams who volunteer. Define success metrics together. Commitment: two quarters. 4. Rollout phase: Based on pilot results, expand more broadly. By now, you have demonstrated value and built relationships.
Each phase requires only limited commitment and produces evidence that informs the next decision. Teams reluctant to bet heavily on an unproven initiative can agree to limited experiments. Success in early phases builds the credibility and relationships needed for broader commitment.
Building Consensus on Who Owns Model-Harm Risk
The hardest consensus to reach in an AI initiative is rarely about architecture. It is about who owns the risk when the model does something harmful—hallucinates a fact a customer relies on, produces a biased recommendation, or leaks information it shouldn’t have. The introduction named this ambiguity; here is how you actually resolve it.
The difficulty is structural. A traditional service has a clean ownership boundary: the team that operates it owns its SLA, its on-call, and its failures. Model harm refuses to sit inside one boundary. A biased output might originate in the data team’s training set, be amplified by the model team’s fine-tuning choices, be exposed by the product team’s prompt and UI framing, and create liability the legal and trust-and-safety teams have to answer for. Each team can plausibly point to one of the others. The result is the diffusion-of-responsibility pattern: a risk everyone touches and no one owns.
This is why model-harm ownership differs fundamentally from owning a normal service SLA. An SLA is a threshold on a metric the owning team controls—if latency exceeds 200ms, the owning team is paged and fixes it. Model harm has no single controllable metric, no single point of remediation, and often no clear detection signal at all. You cannot assign it the way you assign an error budget, because the failure is distributed across the very seam your cross-team initiative is trying to bridge.
The frameworks already in this chapter are the tools for resolving it. Start with interests, not positions (Fisher and Ury). The data team’s position—“we just provide data, we don’t control how it’s used”—masks an interest in not being blamed for downstream misuse they can’t see. The product team’s interest is shipping without becoming accountable for model internals they don’t understand. Surfacing these lets you design an ownership model that addresses the underlying fear (being held responsible for something outside your control) rather than fighting over the position.
A workable consensus usually decomposes the single scary word “ownership” into distinct, assignable responsibilities:
- Detection ownership: Who monitors for the harm and raises the signal? (Often the team closest to production output.)
- Remediation ownership: Who can actually change the system to stop it—retrain, adjust the prompt, add a filter, roll back?
- Accountability ownership: Who answers to leadership, customers, or regulators when it happens?
These three frequently land on different teams, and naming them separately dissolves the standoff. A pre-mortem (“a major incident occurred related to AI usage—what happened, and who was on the hook?”) is an effective forum for surfacing exactly where these responsibilities are currently unassigned. The cross-team leader’s deliverable is not a perfect model of harm; it is a RACI that every team can live with before an incident, recorded somewhere durable. Reaching that agreement under calm conditions, using the relational capital you’ve built, is far cheaper than negotiating it in the middle of a postmortem when every team is incentivized to point at someone else.
Case Study: Unified Embedding Service
Consider a composite case study drawn from several organizations I’ve worked with.
A large e-commerce company had embedding models scattered across teams. Search used one set of embeddings, recommendations used another, fraud detection used a third. Each team had independently built embedding infrastructure, chosen different models, and created incompatible interfaces.
An enterprising ML platform engineer proposed a unified embedding service. The technical case was compelling: consolidated GPU resources, consistent embedding quality, simpler operations. She drafted a proposal and presented it to the AI steering committee.
The proposal met resistance. The search team worried about latency regressions for their high-traffic service. The recommendations team had specialized embeddings fine-tuned on their data. The fraud team had security concerns about centralizing sensitive data access.
The initial attempt at mandated standardization failed. Teams found ways to delay, argue about requirements, and continue using their existing solutions.
A year later, the same engineer took a different approach. She spent three months doing something unusual for a platform engineer: helping other teams with their problems. She helped the search team optimize their embedding model quantization. She helped the recommendations team debug a training pipeline issue. She helped the fraud team design a more efficient feature serving architecture.
Only after building these relationships did she return to the platform proposal. But this time, she started with extensive interviews. What did each team actually need? What were their constraints and concerns? She discovered that latency guarantees mattered enormously to search but the recommendations team cared more about embedding quality. The fraud team’s security concerns were addressable with specific isolation guarantees.
She proposed a federated architecture where each team could run their own embedding models on shared infrastructure, with the option to use centralized models where that made sense. The platform would provide the operational benefits (GPU management, monitoring, deployment tooling) without forcing model standardization.
She structured the rollout as a partnership: the platform team would work intensively with each adopting team through the transition, with success defined by the adopting team. The first two teams were those she’d already helped, with accumulated relational capital.
Eighteen months later, adoption was at 85%. Not because it was mandated, but because teams found genuine value. The remaining 15% had legitimate edge cases that the federated model couldn’t address, and exceptions were granted without drama.
What made the difference? Not better technology (the underlying systems were similar). The difference was approach: 1. Build relationships before asking for commitment 2. Understand interests, not just positions 3. Co-design solutions rather than hand down mandates 4. Start with willing partners and demonstrate value 5. Preserve autonomy within shared infrastructure
Creating Technical Standards That People Follow
The Paradox of Standards
Technical standards create a fundamental tension. On one hand, standardization enables efficiency: shared tooling, reduced cognitive load, easier collaboration. On the other hand, standardization restricts local optimization: one size rarely fits all, and mandated approaches may not suit specific contexts.
Research on platform adoption, particularly work by Annabelle Gawer and Michael Cusumano, shows that the most successful platforms balance standardization with flexibility. They standardize interfaces and core constraints while allowing variation in implementation. They provide defaults that work well for common cases while offering escape hatches for edge cases.
For AI initiatives, this means distinguishing between:
Hard standards (non-negotiable requirements): security controls, privacy compliance, ethical guardrails, audit requirements. These should be uniformly enforced because the risks of variation outweigh the costs of standardization.
Soft standards (recommended approaches): model serving frameworks, evaluation methodologies, prompt engineering patterns. These should be defaults that make common cases easy while allowing justified deviation.
Conventions (community norms): naming conventions, documentation formats, review processes. These emerge from practice and are enforced through culture rather than policy.
This taxonomy is clean until you apply it to the most contentious question in AI governance: is a shared evaluation harness a hard standard or a soft one? The placement above filed “evaluation methodologies” under soft standards, but that classification hides a genuine tension rather than resolving it.
The case for soft: teams resist a mandated eval methodology for legitimate reasons. A search team and a summarization team are measuring fundamentally different things; a single prescribed metric set will be wrong for at least one of them. Forcing a common harness can produce numbers that are consistent and meaningless—everyone reporting the same score that doesn’t reflect what actually matters for their task. Treated as a soft standard, eval methodology respects that different tasks need different measures.
The case for hard: the entire reason an organization invests in cross-model coordination is to reason about its models together—to decide which model to fund, which to deprecate, whether the platform is improving. If every team evaluates differently, cross-team model comparison becomes impossible. There is no shared denominator. Two teams can each claim their model is “better” with no way to adjudicate, and leadership cannot tell whether the org’s AI is getting safer or more capable over time. Inconsistent eval doesn’t just inconvenience the platform team; it makes organization-wide judgment impossible, which is exactly the kind of shared-risk concern that justifies a hard standard.
Both arguments are correct, which is why “is it hard or soft?” is the wrong question. The resolution—worked through in detail in the Evaluation Standardization Debate case study below—is to split the harness along the same seam as the standard itself: a thin hard core (a small set of operational and safety metrics every team must report identically, so cross-model comparison is possible) wrapped in a soft layer (domain-specific metrics each team defines and justifies). The contention dissolves not by picking a side but by recognizing that an eval harness is not one standard; it is a hard kernel inside a soft shell, and the leader’s job is to draw that boundary as narrowly as the comparison goal allows.
When to Standardize
Not every difference across teams represents a problem to solve. Some variation is healthy exploration. Some reflects genuinely different requirements. Standards should target variation that creates significant costs without corresponding benefits.
Standardize when: - Inconsistency creates integration friction (incompatible APIs, conflicting dependencies) - Each team is independently solving the same problem (duplicated infrastructure, repeated mistakes) - Risk is shared but practices vary (security, compliance, ethics) - Scale benefits depend on uniformity (shared tooling, operational efficiency)
Allow variation when: - Different use cases genuinely require different approaches - The space is evolving rapidly and optimal practices aren’t clear - Local context matters significantly - Standardization costs exceed coordination costs
Example decision: Model monitoring
Should all teams use the same model monitoring infrastructure?
Standardization case: Consistent monitoring enables organization-wide views of AI health. Centralized tooling is more cost-effective to maintain. Standards ensure all teams meet baseline requirements for detecting model drift.
Variation case: Different model types require different monitoring approaches (classification vs. generation vs. embedding). Teams have different latency budgets for monitoring overhead. Some teams have specialized requirements (real-time fraud detection vs. batch recommendation scoring).
A sensible middle ground: Standardize the monitoring infrastructure (metrics collection, storage, alerting) while allowing variation in what metrics each team collects. Require baseline metrics (performance, latency, error rates) while allowing teams to define domain-specific metrics. Provide default dashboards while allowing customization.
The Adoption Curve
Technical standards follow an adoption pattern similar to technology adoption curves, but with important differences.
Innovators (first 5-10%): Teams that actively want to try new approaches. They’ll adopt even incomplete standards if the direction is compelling. These are your design partners, but their willingness to tolerate rough edges can lead you to overestimate readiness.
Early majority (next 30-40%): Teams that want proven solutions but will move once they see successful examples. They need demonstrations of value from the innovators, clear documentation, and reasonable migration paths.
Late majority (next 30-40%): Teams that prefer their current approach and will only change when the costs of non-adoption exceed migration costs. They often have legitimate reasons for their reluctance (working systems they understand, constrained bandwidth for change). They need significant enabling support and sometimes organizational pressure.
Resisters (final 10-20%): Teams that will not adopt without mandates, and even then may seek workarounds. Sometimes they have genuinely exceptional circumstances. Sometimes they’re protecting territory. Distinguishing between these requires relationship and judgment.
Effective standards adoption works through this curve deliberately. Start with innovators who want to partner. Use their success to demonstrate value to the early majority. Invest in enablement (tooling, documentation, migration support) that addresses late majority concerns. Apply organizational pressure only for true resisters, and be willing to grant legitimate exceptions.
Case Study: Prompt Engineering Standards
A technology company attempted to standardize prompt engineering practices across its AI product teams. Their first approach failed; their second succeeded.
First attempt (failed): The AI platform team observed that different product teams were using inconsistent prompt patterns, leading to variable output quality and difficulty sharing learnings. They drafted a comprehensive “Prompt Engineering Standard” document specifying required prompt structures, mandatory safety prefixes, approved model parameters, and a review process for new prompts.
The document was published, presented at an all-hands meeting, and… largely ignored. Product teams continued their existing practices. When asked why, responses included: “The required structure doesn’t work for our use case,” “We can’t meet the review SLA for iteration speed,” and “We weren’t consulted and don’t agree with the recommendations.”
Second attempt (succeeded): A new technical lead took a different approach. She started by creating a Slack channel for prompt engineering discussion. No requirements, just a place to share learnings. She actively solicited examples of what was working and what wasn’t.
Over three months, patterns emerged organically. Certain prompt structures consistently worked better. Certain safety approaches were more effective. She documented these as “patterns” rather than “requirements,” explicitly noting that they were observed best practices rather than mandates.
She then worked with the legal and safety teams to identify the genuinely non-negotiable requirements: specific safety mitigations, audit logging, and human-in-the-loop for certain use cases. These became the “hard standard”—a short document focused on the actual constraints, with clear rationale for each.
For the soft standards, she created templates and tooling. Instead of requiring a specific prompt structure, she provided a library of proven templates that teams could use or modify. Instead of mandatory reviews, she offered optional office hours where teams could get feedback on their approaches.
Adoption grew organically. Teams used the templates because they worked well, not because they were required. The Slack channel became a genuine community where practitioners shared learnings. The hard standards achieved near-universal compliance because they were clearly justified and narrowly scoped.
What differed: 1. Started with observation rather than prescription 2. Distinguished between hard constraints and soft recommendations 3. Made compliance easy through tooling and templates 4. Created community rather than mandates 5. Respected team autonomy while addressing genuine needs
Decision-Making Frameworks for Cross-Team Initiatives
The Reversibility Heuristic
A useful heuristic for cross-team decisions is to consider reversibility. Some decisions are easily reversible—you can try an approach, learn from it, and change course. Other decisions create significant switching costs or lock-in.
For reversible decisions: Move quickly. Gather enough information to make a reasonable choice, then try it. You’ll learn more from implementation than from extended deliberation. Cross-team processes can slow down even simple decisions; fight this by defaulting to action for reversible choices.
For irreversible decisions: Move carefully. Seek input widely. Consider second-order effects. Document the reasoning so future teams understand why you made the choice. These decisions deserve the overhead of formal cross-team review.
Example: Which model framework to standardize on?
This is a partially reversible decision. While migration between frameworks is costly, it’s not impossible, and teams can often run multiple frameworks in parallel. A reasonable approach: choose a default framework based on current needs, make adoption voluntary initially, and commit to revisiting in a year. Don’t treat this as an irreversible decision requiring months of analysis; don’t treat it as trivially reversible either.
The Disagree-and-Commit Protocol
Amazon popularized the “disagree and commit” norm: after genuine debate, those who disagree with a decision still commit to its success. This prevents both endless deliberation and passive resistance.
For cross-team decisions, disagree-and-commit requires:
Genuine debate: Those who disagree must have the opportunity to make their case fully. This means ensuring they’re in the room, giving them time to articulate concerns, and genuinely considering their perspective. If people don’t feel heard, they won’t commit.
Clear decision ownership: Someone needs the authority to make the call. In cross-team initiatives, this might be the executive sponsor, a designated decision owner, or a working group with defined authority. Ambiguous ownership leads to unresolved disagreements.
Explicit commitment: After the decision, those who disagreed explicitly acknowledge they will support the decision despite their disagreement. This isn’t mere compliance; it’s active support. No undermining in hallway conversations. No “I told you so” if things go wrong.
Good faith post-decision: The decision owner must treat commitment as genuine, not as grudging compliance to be monitored. And those who disagreed must genuinely work to make the decision succeed, while reserving the right to advocate for revisiting if new information emerges.
This protocol breaks down if any element is missing. If debate isn’t genuine, commitment won’t be either. If decision ownership is unclear, disputes continue indefinitely. If commitment isn’t explicit, passive resistance flourishes.
Disagree-and-commit under probabilistic outcomes. There is an AI-specific wrinkle that the standard protocol doesn’t anticipate. Disagree-and-commit was formulated for deterministic deliverables: you commit to building a feature, and you can be held to whether you built it. AI initiatives often ask teams to commit to an outcome no one can promise—that the model will clear an accuracy bar, that hallucination rates will drop below a threshold, that quality will be good enough to ship. No amount of debate resolves this, because the disagreement isn’t about approach; it’s about an empirical fact that won’t be known until after training and evaluation. Committing to “we’ll hit 95% accuracy” is fundamentally different from committing to “we’ll ship the login page,” because the first is a bet on an uncertain result and the second is a bet on your own execution. The fix is to be precise about what teams are committing to: not the result, but the path and the decision rule. Teams disagree-and-commit to running the experiment, to the success criteria that will be used to judge it, and to what happens if the model misses the bar—not to the bar being met. This keeps commitment honest. A team that “commits” to a probabilistic outcome it privately believes is unachievable hasn’t committed; it has set itself up to be blamed, which breeds exactly the quiet resistance the protocol exists to prevent. Pairing disagree-and-commit with the graduated commitment model earlier in this chapter is what makes this tractable: each phase asks teams to commit only to the next reversible step, with a real off-ramp if the evidence comes back negative.
Handling Technical Disagreements
Technical disagreements in cross-team initiatives often have non-technical roots. Before trying to resolve the technical question, check for underlying issues:
Is this actually a priority disagreement? “We should use approach A” and “we should use approach B” might really mean “our team’s goals prioritize X” versus “our team’s goals prioritize Y.” Resolving the priority question first often dissolves the technical disagreement.
Is this an autonomy concern? Resistance to a technical approach sometimes reflects resentment about being told what to do rather than genuine disagreement about the approach. Involving people earlier in the decision often addresses this.
Is this about trust? “Your approach won’t scale” might mean “I don’t trust your team to build something reliable.” Addressing the trust issue directly—perhaps through closer collaboration, clearer SLAs, or joint ownership—may matter more than the technical details.
When the disagreement is genuinely technical:
Seek data over debate. “Let’s benchmark both approaches under realistic load” is more productive than extended argumentation about which approach is theoretically better. Propose experiments that could resolve the disagreement empirically.
Define evaluation criteria first. Often disagreement persists because parties are optimizing for different criteria. One team prioritizes latency; another prioritizes development velocity. Explicitly naming the criteria and their relative weights can clarify whether you genuinely disagree about the technical facts or about what to optimize for.
Consider hybrid approaches. “Both approaches in parallel” or “approach A with elements of B” sometimes captures most of the value from each perspective while resolving the conflict.
Accept that some decisions are judgment calls. Not every technical disagreement has a demonstrably correct answer. When reasonable engineers with full information disagree, someone needs to make a judgment call and others need to commit to it.
Case Study: The Evaluation Standardization Debate
An AI organization debated whether to standardize model evaluation frameworks. The ML platform team advocated for a single evaluation service with consistent metrics. Individual model teams preferred flexibility to use domain-specific evaluation approaches.
The debate went in circles for months. Each side presented compelling arguments. The platform team showed how inconsistent evaluation made cross-model comparisons impossible. The model teams showed how standardized metrics missed important domain-specific considerations.
A senior technical leader proposed a structured resolution process:
Step 1: Define the actual goals. What problems were they trying to solve? - Platform team’s goal: Enable organization-wide understanding of model health - Model teams’ goal: Ensure evaluation captures what matters for their specific use cases - Shared goal: Make it easy to evaluate models rigorously
These goals weren’t actually in conflict. The apparent conflict was about approach, not objective.
Step 2: Define constraints. - Non-negotiable: Every model must have documented evaluation methodology - Non-negotiable: Core metrics (latency, error rate) must be standardized for operational purposes - Flexible: Domain-specific metrics can vary by use case
Step 3: Design for the constraints. A two-tier evaluation system emerged:
- Tier 1: Standardized operational metrics, automatically collected, used for organization-wide health dashboards
- Tier 2: Domain-specific metrics, defined by model teams, required to be documented and justified
Step 4: Pilot and iterate. Three volunteer teams implemented the two-tier system. Refinements emerged: better tooling for Tier 2 metrics, clearer documentation requirements, and a process for promoting useful Tier 2 metrics to Tier 1.
Lessons: 1. Surface the underlying goals, which are often compatible 2. Distinguish constraints from preferences 3. Design systems that satisfy constraints while preserving flexibility 4. Pilot before broad rollout to discover refinements
Research Foundations
Organizational Behavior Research
Cross-team leadership draws on decades of organizational behavior research.
Coordination theory (Malone and Crowston) provides frameworks for understanding how organizations coordinate work. Their taxonomy distinguishes between resource dependencies (sharing limited resources), producer-consumer dependencies (output of one process is input to another), and simultaneity constraints (activities must happen at the same time). Each dependency type requires different coordination mechanisms. AI initiatives often involve all three types simultaneously, making coordination particularly challenging.
Boundary spanning research (Tushman, Ancona) studies individuals who connect different organizational units. Effective boundary spanners translate between groups (adapting language and framing for each audience), filter information (identifying what each group needs to know), and link groups for joint work. Cross-team technical leaders are boundary spanners, and developing these skills deliberately improves effectiveness.
Psychological safety research (Edmondson) demonstrates that team performance depends on members feeling safe to take interpersonal risks—asking questions, admitting mistakes, proposing ideas that might fail. For cross-team initiatives, this means creating forums where participants can raise concerns without fear of judgment or retaliation. Technical leaders who create psychologically safe environments get better information and more genuine engagement.
Technical Leadership Literature
Emerging literature on technical leadership in software organizations provides relevant insights.
Camille Fournier’s work on engineering leadership distinguishes between management (formal authority over people) and technical leadership (influence over technical direction). Staff engineers and principal engineers often have significant technical leadership without management authority, requiring different skills and approaches.
Will Larson’s writing on staff engineering emphasizes that senior technical contributors must learn to “work on the meta” rather than doing all the work themselves. For cross-team initiatives, this means designing systems and processes that enable others to contribute effectively, rather than trying to personally write all the code or make all the decisions.
Tanya Reilly’s work on “being glue” identifies the often-invisible work that makes cross-team collaboration possible: noticing what’s not being done, connecting people who need to talk, documenting decisions, following up on commitments. This work is essential but often unrewarded. Cross-team leaders must both do this work and ensure it’s visible enough to be valued.
Platform Thinking
Research on platforms and ecosystems (Gawer, Cusumano, Parker, Van Alstyne) offers models for cross-team technical initiatives.
Successful platforms create value for participants that exceeds the cost of joining. They enable “network effects” where the platform becomes more valuable as more participants join. They carefully balance standardization (creating coherent ecosystem) with flexibility (enabling diverse participants to thrive).
Applied to AI infrastructure initiatives: think of your platform as creating an ecosystem. What value do teams get from participating? How do network effects manifest (shared learnings, compatible tools, consistent interfaces)? Where is standardization essential and where should you preserve flexibility?
Building Intuition for Organizational Complexity
The Landscape of Stakeholder Interests
When navigating a cross-team initiative, mentally map the landscape of stakeholder interests. For each stakeholder:
What do they want? Not just their stated position, but their underlying interests. Career advancement? Technical excellence? Team autonomy? Reduced risk? Understanding interests helps you find solutions that work for everyone.
What do they fear? Often more important than what they want. Loss of control? Being blamed for failures? Technical debt accumulation? Addressing fears, often more than appealing to desires, enables buy-in.
What are their constraints? Limited headcount, competing priorities, technical debt, regulatory requirements. Understanding constraints helps you design initiatives that are actually achievable for participants.
Who influences them? Their manager, their team, peer leaders, or organizational norms. Sometimes the path to alignment runs through someone else.
This mapping shouldn’t be cynical manipulation—it’s understanding the organizational reality in which you’re operating. Initiatives that work for stakeholders succeed; initiatives that work against stakeholders fail, regardless of technical merit.
Reading Organizational Signals
Organizations communicate through multiple channels. Developing fluency in reading these signals helps you navigate more effectively.
What gets funded? Budget allocation reveals true priorities, which may differ from stated priorities. If AI is a “top priority” but no headcount was allocated, adjust your expectations.
What gets celebrated? What successes are amplified in all-hands meetings? What behaviors are recognized and rewarded? This reveals the organization’s actual values, which may differ from stated values.
What gets tolerated? What behaviors persist despite official disapproval? If shadow IT solutions proliferate despite a standardization mandate, the mandate isn’t actually enforced. If teams regularly miss commitments without consequence, deadlines aren’t real constraints.
Who gets promoted? Career advancement decisions reveal what leadership actually values. If technical excellence is professed but managers get promoted while individual contributors plateau, the incentive structure pulls toward management.
These signals help you understand what’s actually possible and what’s merely announced. They help you predict how initiatives will actually unfold, beyond the optimistic projections in planning documents.
Building Your Leadership Presence
Cross-team leadership requires a particular kind of presence. You need to be seen as competent enough that people respect your technical judgment, collaborative enough that people want to work with you, and principled enough that people trust you to handle conflicts fairly.
Competence signals: - Deep knowledge in your core technical area - Ability to engage meaningfully across technical domains - Track record of successful delivery - Sound judgment on tradeoffs
Collaboration signals: - Genuine interest in others’ perspectives - Credit-sharing behavior - Willingness to compromise on non-essentials - Follow-through on commitments
Principle signals: - Consistency between stated values and actions - Fairness in resolving disputes - Transparency about reasoning - Willingness to change position based on new information
This presence is built through accumulated interactions over time. Every meeting, every review, every Slack message contributes to others’ perception of your leadership. There are no shortcuts, but there are mistakes that destroy credibility quickly (claiming credit for others’ work, committing and not delivering, advocating for positions you don’t actually believe).
Common Pitfalls and How to Avoid Them
The Mandate Trap
Symptom: Believing that executive mandate will solve adoption problems.
Reality: Mandates can compel compliance but not engagement. Teams that are forced to adopt a solution will invest the minimum required, find workarounds, and abandon the solution when attention shifts.
Alternative: Build genuine value proposition. Make adoption attractive, not just required. Use mandates sparingly, for genuine non-negotiables (security, compliance), not for things that should succeed on merit.
The Perfect Design Trap
Symptom: Spending months designing the ideal cross-team solution before getting feedback.
Reality: Your understanding of others’ needs is necessarily incomplete before you work with them. Extensive upfront design often produces solutions optimized for hypothetical rather than actual requirements.
Alternative: Design collaboratively. Start with rough proposals and iterate with stakeholders. Embrace that the design will change based on what you learn. Ship incrementally rather than waiting for completeness.
The Hero Leader Trap
Symptom: Trying to personally drive all aspects of a cross-team initiative.
Reality: Cross-team initiatives are too large for any individual. Attempting to personally control everything leads to burnout and bottlenecks.
Alternative: Build coalitions. Identify champions in each team who can drive local adoption. Delegate ownership of components while maintaining coordination. Your role is orchestration, not execution of everything.
The Avoiding Conflict Trap
Symptom: Seeking universal agreement, avoiding difficult conversations, letting disagreements fester.
Reality: Conflict is inevitable in cross-team work. Avoiding it doesn’t make it go away; it just moves it underground where it’s harder to address.
Alternative: Surface conflicts early. Create forums for disagreement. Treat conflict as information about different perspectives, not as failure. Practice direct, respectful confrontation of issues.
The Ignoring Politics Trap
Symptom: Believing technical merit is sufficient, dismissing organizational dynamics as “politics.”
Reality: Organizations are composed of humans with interests, relationships, and histories. Ignoring these realities doesn’t make them go away; it just means you’ll be surprised when technically sound proposals fail.
Alternative: Engage with organizational reality. Understand stakeholder interests. Build relationships deliberately. Recognize that navigating organizations effectively is a legitimate skill, not a distasteful compromise.
Key Takeaways
Influence derives from value creation - Build influence by helping others succeed, demonstrating expertise, and building genuine relationships. Authority can be delegated; influence must be earned.
Consensus requires understanding interests - Effective alignment comes from understanding stakeholder interests, not from persuading people to accept your position. Solutions that work for everyone are more sustainable.
Standards succeed through value, not mandates - Standards that provide genuine value get adopted. Standards that impose costs without clear benefits get circumvented. Make the right thing easy.
Organizations are human systems - Technical merit alone doesn’t determine success. Initiatives succeed when they work with organizational dynamics. This isn’t politics to avoid; it’s reality to engage.
Build coalitions rather than going solo - Cross-team initiatives are too large for any individual. Identify champions in each team, delegate ownership of components, and focus on orchestration.
Summary
Cross-team technical leadership is fundamentally about enabling collective success across organizational boundaries. Unlike individual contribution, where your impact flows from your own work, cross-team leadership multiplies impact through others.
The core principles:
Influence derives from value creation. You build influence by helping others succeed, demonstrating expertise, and building genuine relationships. Authority can be delegated; influence must be earned.
Consensus requires understanding. Effective alignment comes from understanding stakeholder interests, not from persuading people to accept your position. Solutions that work for everyone are more sustainable than mandated approaches.
Standards succeed through value. Technical standards that provide genuine value get adopted. Standards that impose costs without clear benefits get circumvented. Focus on making the right thing easy, not on making the wrong thing forbidden.
Organizations are human systems. Technical merit alone doesn’t determine success. Initiatives succeed when they work with organizational dynamics, not against them. This isn’t politics to be avoided; it’s reality to be engaged.
Leadership is a practice. These skills develop through deliberate practice over time. Seek opportunities to lead cross-team initiatives, even small ones. Reflect on what works and what doesn’t. Build your network and reputation systematically.
AI initiatives particularly require these skills because they inherently span teams, involve uncertainty that makes commitment difficult, and evolve rapidly enough that ongoing coordination is essential. As AI capabilities become more central to organizations, the ability to lead cross-team AI initiatives becomes correspondingly more valuable.
Practical Exercises
Exercise 1: Stakeholder Analysis
Select a current or recent cross-team initiative you’re involved with. For each significant stakeholder:
- What is their stated position on the initiative?
- What underlying interests might drive that position?
- What concerns or fears might they have?
- What constraints do they operate under?
- What would success look like from their perspective?
For stakeholders with concerns, design an engagement approach that addresses their underlying interests while advancing the initiative’s goals.
Exercise 2: Decision Analysis
Identify a pending cross-team decision that has stalled or become contentious.
- Characterize the type of disagreement (technical, priority, autonomy, trust)
- Propose an approach to resolve the underlying issue
- Design a decision process that ensures genuine debate and clear ownership
- Draft the commit protocol for after the decision is made
Exercise 3: Standards Design
Design a technical standard for an area in your organization that currently lacks consistency.
- Define the problem the standard addresses
- Distinguish between hard requirements and soft recommendations
- Design the adoption path (innovators through late majority)
- Create an enablement plan (tooling, documentation, support)
- Define the exception process
Exercise 4: Network Assessment
Map your current professional network across your organization.
- Which teams do you have strong relationships with? Weak or missing relationships?
- For each gap, identify someone who could bridge to that team
- Identify 3 actions to strengthen relationships in the next quarter
- Plan how to build new relationships in areas where you lack coverage
Exercise 5: Influence Mapping
For a current or planned cross-team initiative:
- Identify all stakeholders and their roles (decision-maker, influencer, blocker, champion)
- Map their interests and concerns
- Design an engagement approach for each key stakeholder
- Identify potential coalition partners who share your goals
Self-Assessment Checkpoint
Conceptual Questions
Q1. [IC2] What does “influence without authority” mean? Why is it essential for cross-team leadership?
Answer
Influence without authority: Getting people to do things when you can’t simply tell them to. You have no organizational power over them—no hiring/firing, no performance reviews, no resource allocation control.
Why essential: (1) Cross-team work involves people from other reporting lines. Their managers have different priorities. (2) Mandates breed compliance, not commitment. People find workarounds to mandated solutions. (3) Technical decisions need buy-in. Imposed standards get ignored or worked around. (4) Collaboration is voluntary. People choose whether to engage meaningfully. (5) Your success depends on others who don’t report to you.
Building influence: (1) Technical credibility: Demonstrate you know what you’re talking about. (2) Track record: Deliver on commitments. (3) Understanding their needs: Show you care about their constraints, not just your initiative. (4) Reciprocity: Help them first, before asking for help. (5) Relationships: Invest time before you need something.Q2. [IC2] Distinguish between positions and interests in negotiation. Why is focusing on interests more effective?
Answer
Position: What someone says they want. “We need to own this data pipeline.”
Interest: Why they want it. “We need to ensure data quality because we’re accountable for downstream metrics.”
Why interests matter: (1) Positions are often one solution; interests can be satisfied multiple ways. (2) Positions can conflict when interests don’t. Both teams want “ownership” but for compatible reasons. (3) Focusing on interests opens creative solutions. “What if you own quality validation and we own infrastructure?” (4) Interests are harder to argue against. “You don’t deserve ownership” is attackable; “ensuring data quality is important” is not.
Application: When someone takes a position you disagree with, ask “What would that give you?” or “What problem does that solve?” Understand the interest, then explore whether there are other ways to satisfy it.Q3. [Senior] How do you create a technical standard that teams willingly adopt rather than grudgingly comply with?
Answer
Common failure: Standards created by one team, imposed on others. Result: resistance, workarounds, resentment.
Effective approach:
Involve early: Include representatives from adopting teams in design. Their input improves the standard and creates ownership.
Solve their problems: Standards should make teams’ lives easier, not just enforce consistency. “This saves you from building auth” beats “use this for consistency.”
Allow exceptions: Create exception process. People accept rules better when escape valve exists. Exceptions also surface where the standard needs improvement.
Lead with carrots: Provide tooling, documentation, support. Make compliance the easy path.
Demonstrate value: Pilot with willing early adopters. Let success speak.
Gradual enforcement: Start with “recommended,” move to “required for new projects,” finally “required for all.”
Listen to feedback: Standards that don’t evolve breed workarounds.
Q4. [Senior] A cross-team initiative is stalled because two teams disagree on a technical approach. How do you diagnose whether this is a technical disagreement or something else, and how do you move forward?
Answer
Diagnosis—types of disagreement:
Technical: Genuine disagreement about best approach. Both teams are trying to solve the same problem, just differently.
Priority: Teams agree on what’s right but disagree on when/whether to invest. “Your initiative isn’t my priority.”
Autonomy: Teams resist being told what to do. Not about the technical choice, but about who gets to decide.
Trust: Teams don’t believe the other will execute well. Past experiences color current discussions.
Diagnosis approach: (1) Can they articulate the other team’s position fairly? If not, might be autonomy or trust. (2) Would they accept the approach if they proposed it? If yes, probably autonomy. (3) If given more resources, would they proceed? If yes, probably priority. (4) Are the stated technical objections consistent or shifting? Shifting suggests technical isn’t the real issue.
Moving forward:
- Technical: Structured decision-making (criteria, evaluation, RFC)
- Priority: Escalate to leadership for resource/priority alignment
- Autonomy: Find way to give them meaningful ownership
- Trust: Build relationship, start with smaller collaboration, earn credibility
Q5. [Staff] How do you balance standardization versus team autonomy? What principles guide this decision?
Answer
Tension: Standardization enables reuse, consistency, and efficiency. Autonomy enables innovation, speed, and ownership. Both are valuable; neither should fully dominate.
Principles for deciding:
Standardize interfaces, not implementations: Teams can build however they want if they conform to shared contracts.
Standardize what’s painful to vary: Auth, observability, deployment pipelines—where inconsistency creates operational burden.
Allow autonomy where innovation matters: Product features, model architectures—where teams have unique context.
Standardize where failure is costly: Security, compliance, data handling—where mistakes affect the whole organization.
Allow autonomy where risk is contained: Internal tools, prototypes—where experiments can fail safely.
Decision framework: - High blast radius (affects many teams) → Standardize - Rapidly evolving technology → Allow autonomy - Commoditized capability → Standardize - Differentiating capability → Allow autonomy - Safety-critical → Standardize
Implementation: Start with recommendations, graduate to requirements only where necessary. Make the standard the easy path through tooling and support.Spot the Problem
Problem 1. [IC2] An engineer’s approach to cross-team work:
“I designed the new API standard and sent it to all the teams for feedback. I gave them two weeks to comment. Most teams didn’t respond, so I assumed they agreed. Now I’m presenting the final standard to leadership.”
What’s wrong with this approach?
Answer
Problems:
Design done in isolation: Teams have no ownership because they weren’t involved in creating it.
Email-based feedback: Passive feedback mechanism. Silence usually means “not my priority,” not “I agree.”
Assumed consent: “No response = agreement” is dangerous. People are busy; they’ll object when it affects them.
Presenting as final: Leadership presentation implies decision is made. Later objections feel like undermining.
No relationship building: Zero face-to-face engagement. No understanding of team constraints or concerns.
Problem 2. [Senior] A staff engineer’s cross-team initiative:
“The data team keeps blocking my proposal. I’ve explained the technical benefits multiple times, but they refuse to agree. I’m going to escalate to my VP to force a decision.”
What’s missing from this approach?
Answer
What’s missing:
Understanding their interests: “Explained technical benefits” focuses on your perspective. What are their concerns? What are they protecting? What constraints do they have?
Relationship: “They keep blocking” suggests adversarial dynamic. Have you invested in understanding their world?
Creative options: Have you explored alternatives that address their concerns while meeting your needs?
Diagnosis: Is this really a technical disagreement, or priority, autonomy, or trust?
Coalition: Are you isolated, or do you have allies who share your view?
Escalation risks: (1) Damages relationship long-term. (2) Even if you “win,” implementation will suffer without buy-in. (3) VP may not understand context and make poor decision. (4) You appear unable to work across teams.
Before escalating: (1) Understand their position well enough to articulate it fairly. (2) Identify their underlying interests. (3) Explore creative options that satisfy both. (4) If truly stuck, ask their preferred escalation path—they may prefer joint escalation to adversarial.Problem 3. [Staff] An AI platform team’s adoption challenge:
“We built a great AI platform with all the capabilities teams need. We presented at all-hands, sent documentation, and offered office hours. But adoption is only 15%. Teams keep building their own solutions. We’re considering having leadership mandate platform usage.”
What’s the real problem and what would you recommend instead?
Answer
What’s really happening: (1) Teams weren’t involved in defining “what they need.” (2) Platform may solve problems teams don’t have. (3) Migration cost isn’t justified by perceived benefits. (4) Teams don’t trust platform to meet their needs. (5) “Build their own” may actually be appropriate for some teams.
Why mandates fail: (1) Compliance without commitment = workarounds. (2) Teams will meet letter of mandate, not spirit. (3) Resentment damages future collaboration. (4) If platform has issues, mandated teams are trapped.
Better approach:
Diagnose: Interview non-adopting teams. Why aren’t they using it? What would change their mind?
Segment: Some teams may have legitimate reasons for alternatives. Others may be persuadable.
Improve: Address common objections. Maybe platform is missing critical features.
Champion early wins: Find teams where platform provides clear value. Make them successful. Let them advocate.
Make migration easy: Reduce switching cost. Offer migration support.
Create positive incentives: Priority support, feature requests, recognition.
Accept some non-adoption: 80% adoption with willing teams beats 100% mandate with resentful teams.
Design Exercises
Exercise 1. [Senior] You’re leading an initiative to establish organization-wide AI governance standards. This affects data science, engineering, product, legal, and compliance teams. Design your stakeholder engagement approach: How would you identify key stakeholders, sequence your conversations, build coalition support, and handle expected resistance?
Guidance
Stakeholder identification: (1) Map all affected teams. (2) Identify decision-makers vs. influencers vs. implementers. (3) Find potential champions (early believers). (4) Identify likely blockers and understand why.
Sequencing: (1) Start with potential champions—build momentum. (2) Engage legal/compliance early—their constraints will shape everything. (3) Listen to potential blockers before proposing—understand their concerns. (4) Build coalition before broad announcement. (5) Present with cross-functional support, not as engineering proposal.
Coalition building: (1) Find shared interests. Risk/compliance people want governance; so do you. (2) Give credit and ownership. “Joint proposal from X, Y, and Z teams.” (3) Address concerns visibly. “Based on data science feedback, we added…” (4) Create working group with representatives from key teams.
Handling resistance: (1) Diagnose type: technical, priority, autonomy, or trust? (2) For priority: Help them see why this is urgent for them. (3) For autonomy: Give them meaningful ownership of portions. (4) For trust: Start small, build credibility. (5) For technical: Structured decision process with their input.
Timeline: Allow 3-6 months for major cross-org initiative. Rushing creates resistance.Exercise 2. [Staff] Two platform teams in your organization provide overlapping AI capabilities. Each has different strengths, and engineering leadership wants to consolidate. Both teams are resistant. You’ve been asked to drive the consolidation. How would you approach this politically sensitive initiative?
Guidance
Understand the dynamics: (1) Why do both platforms exist? Different requirements, different history? (2) What are each team’s concerns about consolidation? Job security? Loss of ownership? Technical disagreement? (3) What does “consolidation” mean to each stakeholder? Merger? One wins, one loses?
Stakeholder concerns: (1) Team A: “We built X; it should be the standard.” (2) Team B: “Their solution doesn’t meet our requirements.” (3) Engineers on both: “Will I have a job?” (4) Leadership: “Stop the duplication.”
Approach:
Listening tour: Meet both teams individually. Understand their perspectives without judgment.
Find common ground: What do both teams agree is important? Shared values reduce conflict.
Reframe: “Consolidation” implies one wins. “Unified platform” or “best of both” reframes.
Co-design the future: Joint working group to design the target state. Both teams have input.
Address people concerns explicitly: What happens to team members? Clear answers reduce fear.
Define transition path: Gradual migration with clear milestones. Both teams contribute.
Celebrate contributions: Acknowledge both teams’ work in final solution.
Connections to Other Chapters
Cross-team leadership builds on and extends other leadership skills:
Chapter 23 (Technical Communication): Communication skills essential for influencing across organizational boundaries.
Chapter 26 (Technical Decision Making): ADRs and RFCs as tools for building cross-team consensus on technical decisions.
Chapter 22 (Project Ownership & Delivery): Managing complex projects that span team boundaries.
Chapter 24 (Mentorship Foundations): Developing others’ leadership skills and building organizational capability.
Chapter 25 (System Design at Scale): Technical patterns that require cross-team coordination to implement.
Further Reading
Essential
- Reilly, “The Staff Engineer’s Path” - Practical guidance on staff-level cross-team work and organizational navigation.
- Cohen and Bradford, “Influence Without Authority” - Foundational text on influencing without formal authority.
- Fisher and Ury, “Getting to Yes” - Interests-versus-positions framework for consensus building.
Deep Dives
- Larson, “An Elegant Puzzle” - Engineering leadership including cross-team dynamics.
- Meadows, “Thinking in Systems” - Organizations as systems with feedback loops.
- Patterson et al., “Crucial Conversations” - High-stakes discussions and conflict navigation.