In this article
Before you start
Why interviewers ask this
The question separates managers who can describe influence from managers who have exercised it without authority. A candidate who answers "I told the teams to adopt it" has described a mandate, not a change. Interviewers at large technology companies are reported to ask a long version of it: a big change you wanted to make, why it was controversial, what you did differently from earlier attempts and what the outcome was.
A weak answer lists activities: meetings, a document, a launch email. A strong answer names the reason the change was hard, the specific thing that was different this time, and a result that someone else could check. It also shows the cost, because a change that moved people always cost something.
The question sits in the leadership part of a loop; the leadership interviews hub shows the neighbouring questions on strategy, prioritisation and org design, and the project, program and agile hub covers the delivery side of the same work.
Driving a big cross-team change from first principles
- Cross-team change
- A cross-team change is a shift in tools, process or ownership that pays off fully only when several teams adopt it, so no single team's manager can complete it by deciding alone.
- Coalition
- A coalition is a small group of people from different teams who agree on the change, hold real influence in their own teams and take visible actions for it, so the change does not depend on one person's authority.
- Pilot
- A pilot is a first adoption of the change by one willing team, with a measure agreed in advance, used to find defects cheaply and to produce evidence that other teams can read.
In plain words
Moving a big change across teams is like getting several households to share a garden. Nobody can finish it alone. Each household has its own reasons to say no. One house that tries first and grows tomatoes persuades the street faster than a leaflet. The analogy breaks on authority. Households can walk away, but teams have bosses and goals that pull them back. So an engineering manager (EM) must also settle whose decision it is.
Said precisely, the work has five steps. Name one owner. Learn why earlier attempts failed. Assemble a coalition and decision rights. Run a pilot. Make the change the default. John Kotter's eight steps for leading change cover the same ground in more stages, from creating urgency to instituting the change, and he wrote them after watching more than 100 organisations try to change (Kotter, Harvard Business Review, 1995).
Step 1: Name the problem and one owner
The first step turns a complaint into a problem with a single owner, because a change that belongs to everyone belongs to no one. The input is a pain several teams feel, such as three different deployment processes. The output is a one-paragraph problem statement with a number attached and one named owner, often you. Kotter's first step is to create a sense of urgency, and in practice that means showing the cost: hours lost, incidents caused or customers affected.
Pairwise agreement does not scale. Among 6 teams there are 15 possible pairs that could need to agree, and among 12 teams there are 66, while one coordinator talks to each of the 12 once1. The owner is the coordinator. What you now know: who is accountable and how large the problem is.
Step 2: Find out why earlier attempts failed
The second step is to find out why earlier attempts failed, because the same cause will stop you unless you remove it. The input is the history: who tried, what they proposed and where it stopped. The output is the one reason your attempt will be different. Ask the people who tried before, and ask the teams that said no.
Failures tend to have a recognisable cause: no owner, no incentive for the teams that must change, no proof the change worked, or a rollout that hit every team before any defect was found. The Kotter page frames the same point as enabling action by removing barriers. Name which cause you removed. "The earlier proposal asked six teams to migrate in one quarter with no capacity; I gave each team a slot in its own plan and started with one." That sentence answers the follow-up before it is asked. What you now know: your difference from the previous attempts.
Step 3: Build a coalition and agree who decides
The third step builds the coalition and agrees who decides, so that support does not rest on your persuasion alone. The input is the list of teams affected. The output is two or three respected people from other teams who back the change in public, and a written decision owner. Atlassian's Team Playbook describes DACI (Driver, Approver, Contributors, Informed) and stresses that a decision has only one approver (Atlassian, Team Playbook, read October 2026); the Driver gathers input and gets the decision made by an agreed date.
Netflix describes the same shape: each major decision has an informed captain who makes the call, and captains are expected to "farm for dissent", then everyone disagrees and commits (Netflix culture page, read October 2026). Amazon's 2016 letter shows a leader asking for a commitment when there is conviction but no consensus (Amazon, 2016 letter to shareholders). What you now know: who can say yes, and who will say so publicly.
Step 4: Pilot with one team and show a win
The fourth step is a pilot with one willing team and a measure agreed before it starts. The input is the coalition and the measure; the output is a result and a list of defects found while only one team was exposed. In the worked example below, one team out of 12 means 1 team-week of rework instead of 12 if a flaw appears1.
Awareness, Desire, Knowledge, Ability and Reinforcement (ADKAR) is a model of individual change; ADKAR is, in Prosci's words, sequential but not linear (Prosci, read October 2026). A pilot serves the middle elements for the next teams: a peer can answer "what does it cost me" better than you can. Share the result, including the bad news, in the places those teams already read. What you now know: the change works for one team and where it breaks.
Step 5: Roll out and make it the default
The fifth step spreads the change in waves and removes the old way, because a change that is optional decays. The input is the pilot result; the output is a new default that is cheaper to follow than to avoid, such as a template that new services start from or a check that fails the old pattern. Kotter's last steps, sustaining acceleration and instituting the change, point at the same need: tie new behaviour to how the organisation works day to day.
Roll out in waves of increasing size, here 1, 3 and then 8 teams, so that each wave can fix what the previous one found. Then measure adoption and the original pain. If the measure moved, say so; if it did not, say that too. What you now know: the change is the normal way of working, and you can show it.
Step-by-step description
- Name the problem and one owner.
- Learn why earlier attempts failed.
- Agree who decides and who backs it.
- One team first: 1 of 12 exposed.
- Waves of 1, 3 and 8 teams.
- The owner is the coordinator among the teams.
- A pilot with one team exposes only 1 of 12 teams to a defect.
- Waves of 1, 3 and 8 teams reach all 12.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
The arithmetic below uses made-up but plausible inputs to show why order matters: 12 teams must adopt one deployment process. Both calculations come from a short script whose output was saved.1
The first calculation counts coordination.
| Teams affected | Pairwise channels | Channels via one coordinator |
|---|---|---|
| 2 | 1 | 2 |
| 4 | 6 | 4 |
| 6 | 15 | 6 |
| 8 | 28 | 8 |
| 12 | 66 | 12 |
The formula for pairs among teams is , so pairs grow much faster than teams (15 at six, 66 at twelve) and pairwise agreement gets expensive fast, which is why Step 1 names an owner.1
Text description of the diagram
- Pairwise channels among 12 teams number 66.
- One coordinator needs 12 channels for 12 teams.
The second calculation compares rollouts. Suppose a defect costs each affected team 1 team-week to repair; this cost is illustrative. A big-bang rollout exposes all 12 teams (100 percent) and costs 12 team-weeks. A pilot first exposes 1 team (8.3 percent) and costs 1 team-week, and waves of 1, 3 and 8 teams reach 1, 4 and then 12 teams.1
Trade-offs and edge cases
A pilot-first rollout is slower to start and cheaper to be wrong with, and the right choice depends on how reversible the change is.
- Reversible change, small blast radius. A two-way door, in the words of the Amazon letter, can use a light process and move fast; a long pilot is waste.
- Irreversible or shared infrastructure. If every team must switch together, such as a shared database migration, a pilot is a rehearsal rather than a gradual rollout, and the owner needs a rollback plan.
- No authority over the other teams. Lean on the coalition and on the shared pain; escalate the decision to a manager both sides trust, not the argument.
- Sceptical senior stakeholder. Ask for their objection in writing and answer it in the pilot's measure; "farming for dissent" is cheaper than a late veto.
- The change cost something. Say what slowed down: a team that gave up a roadmap slot, or a migration that took two quarters. Interviewers trust a story with a cost.
| Choice | Exposure to a defect | Rework in the example | Proof for later teams |
|---|---|---|---|
| Big bang | 12 of 12 teams | 12 team-weeks | None before launch |
| Pilot first | 1 of 12 teams | 1 team-week | A measured result |
Text description of the diagram
- A big-bang rollout exposes 12 of 12 teams and costs 12 team-weeks if a defect appears.
- A pilot first exposes 1 of 12 teams and costs 1 team-week.
How to answer it in an interview
Tell me about a big cross-team change you drove and what you did differently from earlier attempts.
Six teams used three deployment processes, and an earlier attempt had asked everyone to migrate in one quarter with no capacity. I made myself the owner, interviewed the people who had tried before, and found the missing piece was time in each team's plan. I recruited one respected lead from each of two other teams, agreed that one director approved the design, and piloted with one willing team. Their first defect cost one team-week instead of six. Then I rolled out in waves, made the new template the default, and median deploy lead time fell from two days to under a day within the quarter. It cost us one feature slot.
The numbers in this answer are illustrative; use your own.
The spoken structure is: problem and owner, why earlier attempts failed, coalition and decision, pilot and result, and the cost. Say the cost out loud; it is what makes the story believable.
Common mistakes
- Describing activity, not change. (wrong) "I ran weekly syncs and sent updates." (right) "The measure moved from X to Y because Z."
- Skipping the history. (wrong) "No one had tried this before." (right) "Two earlier attempts stalled because teams had no capacity; I fixed that first."
- Claiming consensus. (wrong) "Everyone agreed." (right) "One team disagreed; we agreed a decision owner and committed."
- Starting with every team. (wrong) "We launched to all teams in the same week." (right) "We piloted with one team, then widened in waves."
- Hiding the cost. (wrong) "It went perfectly." (right) "It cost one feature slot and one quarter of slower delivery."
Follow-up questions
How do you achieve buy-in on your team, across teams, and with your managers?
Give each group the reason that matters to it. Your team wants to know what changes in their week, other teams want to know what it costs them, and managers want the measure and the decision owner. Buy-in is shown by actions, such as a slot in a plan, not by agreement in a meeting.
Why was the initiative controversial, and what did you do differently from the people who tried before you?
Name the real objection, not a polite one, and the one thing you changed. Typical differences are an owner, capacity for the teams, a pilot that produced proof, or a decision made by one named approver after dissent was heard.
How do you move a team in a direction it does not agree with?
Say what you heard, what you decided and why, and how you committed the team anyway. The "disagree and commit" idea in Amazon's letter fits: ask for the commitment openly, and review the decision later.
What if you have no authority over the other teams?
Use the shared pain, a coalition of respected people, and a pilot. If the teams still disagree, escalate the decision, not the argument, to someone who owns both sides' goals.
How do you know the change has stuck?
When the old way is harder to follow than the new one and the original measure stayed improved a quarter later. A leader who left the room and saw no regression has evidence; one who sees a relapse has an unfinished Step 5. For prioritisation, see the leadership interviews hub, and for the neighbouring product side see the product management hub; the opener for any such story is the same as in tell me about yourself.
- Name one owner; pairwise agreement among 12 teams means 66 channels.
- Find why earlier attempts failed and say what you changed.
- Build a coalition and agree one decision owner before you launch.
- Pilot with one team, then widen in waves, and make the new way the default.
- State the cost; it makes the story believable.
Sources
- The 8 Steps for Leading Change — Kotter Inc (page undated; read 2026-10-24), 24 Oct 2026
- Leading Change: Why Transformation Efforts Fail — Harvard Business Review (John P. Kotter, March-April 1995), 1 Mar 1995
- The ADKAR Model — Prosci (page undated; read 2026-10-24), 24 Oct 2026
- DACI: a decision-making framework, Team Playbook — Atlassian (page undated; read 2026-10-24), 24 Oct 2026
- 2016 Letter to Shareholders — Amazon (Jeff Bezos), 12 Apr 2017
- Netflix Culture — Netflix (page undated; read 2026-10-24), 24 Oct 2026
