Why This Competency Matters

When interviewers ask 'tell me about a time you worked across teams' or 'walk me through a cross-functional project that succeeded', they are not testing whether you can attend meetings together. They are probing four signals at once:

[ Coordination ]      Did you create the structure that let teams move together?
[ Empathy ]           Did you understand what the other teams were optimising for?
[ Accountability ]    Did you build shared ownership rather than passing tasks?
[ Communication ]     Did you keep the right people informed at the right depth?

This matters at every level once you cross the L4 threshold, and is essentially the bar from L5 onward. Almost no consequential engineering work happens within a single team boundary. Whether it is a launch, a migration, a metric movement, or a piece of platform work, the success of the project usually depends on three to five teams pulling in roughly the same direction. The candidate who can describe how they made that happen scores; the candidate who only describes their own team's work undersells.

Candidates underperform on this competency for one of three reasons. They tell stories where the cross-team component was implicit (the teams happened to align without any work) rather than constructed. They describe collaboration in feel-good terms ('we worked closely with the other teams') without naming the mechanisms that made the collaboration work. Or they confuse cross-team collaboration with leading-without-authority, which is a related but distinct competency. This lesson disentangles all three.

The Failure Modes Specific to Cross-Team Work

Within a single team, alignment is usually free. People share a manager, an oncall rotation, a sprint cadence, and the same definition of 'shipped'. None of that is true across teams. The four failure modes that show up specifically at team boundaries:

[ Different priorities ]       Their roadmap and yours do not stack-rank the same way
[ Different timelines ]        Their sprint, planning, and launch cadences differ from yours
[ Different definitions of done ]  'Shipped' on their team may mean 'in canary' on yours
[ RACI ambiguity ]             Nobody owns the seam, so the seam falls

Strong cross-team stories show the candidate noticing one or more of these failure modes and constructing a mechanism that addressed it. 'We synced once a week' is not a mechanism unless the candidate explains what the sync was for; 'I noticed our launch definition was 'in production' and theirs was 'documented and supported on-call', so we explicitly wrote down what each team's launch contract included' is a mechanism.

When the failure mode is named in the story, it tells the interviewer 'this candidate has a model of cross-team work that goes beyond meetings'. Without it, the rubric reads collaboration-as-vibe.

How to Read Another Team's Incentives

The most common mistake in a cross-team story is asking the other team to absorb a cost that helps your team but not theirs. Strong candidates do the opposite work: they figure out what the other team is optimising for, then frame the request in those terms.

Four cheap ways to read a team's incentives before you pitch anything:

1. Read their roadmap or OKRs if you can see them. Most companies share roadmaps internally; if yours does, spend 15 minutes reading the next quarter's commitments before booking any meeting.

2. Talk to the lead, mostly listening. A 30-minute conversation with the team's tech lead or manager, with you doing 80% listening, reveals what they are stressed about, who they are answering to, and what work they are protecting time for.

3. Look at their oncall load. A team in a heavy oncall quarter cannot take on discretionary work. A team that just shipped a big launch may have unusual slack. Calibrate your ask accordingly.

4. Check what their PM cares about. Engineering teams answer to a product partner who has their own metrics. A request framed in language their PM cares about (customer impact, churn, contract value) is often easier to land than one framed in pure engineering terms.

This is 'pre-work', not asking. The candidate who shows up to the first cross-team meeting having already done this work has a 5x advantage in the conversation.

What Great Looks Like (Rubric)

Strong cross-team collaboration answers tend to score on six named signals.

1. The cross-team surface is named explicitly.

Not 'I worked with several teams', but 'I worked with engineering on the platform team, product on the growth team, design on the systems-design group, and data on the analytics team'. Strong candidates name the functions and roles, not just 'we collaborated'.

2. You did the listening work before pitching anything.

The story includes a beat where the candidate spent time with each team's lead before proposing the cross-team plan. Without this, the story reads as 'I had a plan and tried to drag everyone along'.

3. You constructed a coordination mechanism, not just attended meetings.

A shared doc, a weekly cadence with a specific format, a written launch contract, a status visualization, an explicit RACI for the seams. Strong stories name the mechanism and what it produced.

4. You reframed the work in terms of each team's outcome.

The same project, pitched four different ways for four different teams. Strong candidates explicitly say 'I framed this as a churn-reduction win for the growth team and as an on-call burden reduction for the platform team'.

5. You handled at least one alignment failure actively.

Most cross-team projects have a moment where one team is not pulling weight, or a definition gets misaligned, or a deadline slips. Strong stories show the candidate catching it early and addressing it, not letting it slide.

6. Credit was distributed honestly at the end.

Strong candidates use 'we' and 'they' liberally for the implementation work, and 'I' precisely for the coordination work they actually owned. The rubric reads credit-grabbing as low-trust.

The Three Coordination Mechanisms

Three concrete patterns that show up in strong cross-team stories. Most candidates use two or three in combination.

1. Shared problem framing. A one-page document everyone agrees describes the problem. Often the highest-leverage 30 minutes of cross-team work is just writing down what the problem actually is, in language all the teams accept. Strong stories include this as an explicit beat: 'I drafted a one-page diagnosis and got the four leads to edit it before we proposed any work'.

2. Shared cadence. A weekly 20-minute sync with a specific format: each team reports progress on their slice, blockers are surfaced, decisions are made. The cadence is the mechanism; without it, the work happens in private and surfaces only at deadlines, when it is too late to course-correct.

3. Shared accountability. Each team's slice of the work is named in writing, with an owner and a date. The doc is referenced in every sync. Strong candidates often write this themselves and update it weekly because the value of the visibility is concentrated.

Avoid these counterfeits, which feel like coordination but score poorly:

• Big meetings with no decision. A two-hour meeting with eight people and no clear outcome reads as ceremony, not coordination.
• Status updates with no change. A weekly email that nobody reads is not a cadence; it is paperwork.
• Implicit ownership. 'We agreed it would get done' without naming who, by when, in writing.

Common Questions & Model Answers

The six prompts below cover roughly 90% of how this competency is probed. Each is a two-minute STAR answer that scores on the rubric above.

Prompt 1: 'Tell me about a time you worked across teams.'

Model answer (strong, four-team surface, all three mechanisms named)

'In Q3 2023 I was an L5 engineer at a 400-person SaaS company, leading the project to launch a new analytics dashboard for our enterprise customers. The work crossed four teams: engineering on the platform team (data pipeline), product on the growth team (which prioritised the work), design (the dashboard UX), and data (the metric definitions and the warehouse work). I was on the platform team and the project was the largest I had led across that many functions.

I owned the coordination and the launch outcome.

I started by reading the relevant roadmaps and having a 30-minute conversation with each of the three other team leads. The most useful thing I learned was that the data team was already over-committed for the quarter, so any ask of them needed to be precisely scoped. I drafted a one-page diagnosis: what the dashboard was, who it served, what each team would contribute, and the launch contract for each contribution. The launch contract was the highest-leverage piece; it was where I noticed that platform's definition of done (in production) and design's definition (signed off, no UX bugs) and data's definition (warehouse query under 3 seconds) were all different, and we needed each one explicitly.

I set up a weekly 20-minute sync, Wednesdays, with a fixed format: each team reports progress, blockers, and forecasted slip. I did the project tracking myself in a shared doc because none of the four teams had bandwidth to do it. When the data team ran into a query-optimisation problem in week six that would have slipped the launch by two weeks, the sync caught it, we agreed to ship a v1 that did one query rather than three, and the data team committed to v2 the following quarter.

The dashboard launched on schedule. In the first 60 days post-launch, 38% of our enterprise customers used it weekly (against a target of 25%), and three large accounts cited it in their renewal conversations. Looking back, I would have written the launch contract in week one rather than week three; the two-week lag in surfacing the definition-of-done mismatch made the design team carry uncertainty that they did not need to.'

What lands: explicit four-team surface, listening beat with each lead, all three coordination mechanisms (shared framing, shared cadence, shared accountability), an alignment failure caught in the cadence, and a reflection on the timing of the launch contract.

Prompt 2: 'Describe how you influenced stakeholders outside your team.'

Model answer (strong, single high-stakes stakeholder)

'In Q1 2024 I was an L5 engineer building a new internal tool for our customer support team. The project was sponsored by our director of customer support, who I had not worked with before. They had been burned by two previous engineering projects that shipped tools support did not adopt, and they were sceptical about whether ours would land differently.

I owned getting their buy-in and keeping it through the project.

I started by asking for 45 minutes on their calendar in week one, mostly to listen. The two prior projects had failed for the same reason: engineering had built what they thought support needed, without spending time observing actual support conversations. I committed in that meeting to two specific things. First, I would shadow at least three support engineers handling real tickets before writing a single line of design. Second, I would set up a bi-weekly 20-minute review with the director and one rotating support engineer, where they could veto features in flight if the design was wrong.

I shadowed five support engineers over the next two weeks. The most useful thing I learned was that 70% of the friction in their workflow was not in the tool itself but in the handoff between two existing tools, which I had not anticipated. I rewrote the v1 scope around that handoff. I also kept the bi-weekly review going for the duration of the project, which surfaced two course corrections that would have otherwise been launch-day bugs.

The tool launched at the end of Q2. Adoption was 90% of the support team in the first month, against the typical 40 to 60% adoption for internal tools at our company. Time-on-ticket dropped 22% sustained over the next two quarters. The director became one of the strongest advocates for the platform team in subsequent quarters, including funding two follow-on projects. The reflection: I underestimated the value of shadowing for the first two days. I had budgeted half a day, then extended it to two weeks because the signal density was so high. I now default to a longer shadowing window for any internal tool and explicitly budget for it.'

What lands: a real sceptical stakeholder, the listening beat (45 minutes mostly listening), a specific commitment that addressed the prior failure pattern, the shadowing as the diagnostic, an explicit course correction, and a generalised lesson about budgeting for shadowing.

Prompt 3: 'Walk me through a cross-functional project that succeeded.'

Model answer (strong, multi-quarter, all three mechanisms)

'In Q2 2023 I was a senior engineer leading the project to reduce our customer onboarding time, which had grown to 11 days against a target of under 3. The project crossed four teams: engineering (provisioning automation, my team), product (verification flow), customer success (handoff playbook), and design (the onboarding UI). The metric we had committed to was time-to-first-value, and we had two quarters to land it.

I owned the metric and the cross-functional coordination.

The shared problem framing was a one-page diagnosis I wrote in week one, showing where the 11 days actually went: 4 days on us (manual provisioning), 3 days on the customer (verification), 4 days in the cross-team integration handoff. I shared the diagnosis with the four leads before proposing any work; two of them had different mental models, and we resolved the differences before committing to a plan. The shared cadence was a 25-minute Tuesday sync where each team reported their slice and we updated a shared progress doc. Shared accountability was a single shared doc with each slice owned and dated.

Two alignment failures came up. In week four, design slipped by 10 days because of an unrelated launch; we re-scoped to use existing patterns and v2 design was scheduled for the next quarter. In week eight, customer success was overloaded; I drafted a first version of their playbook based on customer calls I had observed, and they edited it in three days rather than building from scratch. Neither slip cost the launch.

Outcome: time-to-first-value dropped from 11 days to 4.3 in the first 60 days post-launch, against the under-3 target. We did not hit the target, but we cut the largest source of churn meaningfully. 90-day retention rose from 82% to 91%, sustained over four subsequent quarters. The follow-up projects (v2 design, more provisioning automation) brought time-to-first-value to 2.8 days within two quarters. The reflection: I would set up the cross-team coordination on a weekly cadence from week one, not week three; the two-week lag in setting up the cadence cost us about a week of slack.'

What lands: explicit cross-functional surface, the diagnosis as shared framing, both alignment failures handled actively, an honest 'did not hit target but cut the largest churn source meaningfully', sustained metric, and a process reflection.

Prompt 4: 'Tell me about a time you had to align with a team that did not want to align.'

Model answer (strong, real misalignment, structured resolution)

'In Q4 2022 I was an L5 engineer pushing for a shared error-tracking format across our top three customer-facing services. Two of the three teams owning those services were on board immediately. The third (owned by a peer team I had not worked with directly) pushed back. Their tech lead said they did not see the problem, their team was busy, and they were sceptical that adopting our format would help them.

I owned getting alignment, and pushing through this disagreement was the harder half.

I started by trying to understand their position rather than re-pitching mine. I asked for a 45-minute conversation, mostly to listen. Their concerns were specific and reasonable: they had a custom format that was wired into their existing dashboards, switching would cost them about three engineering days of dashboard rework, and they had not seen evidence that the inconsistency was actually causing problems for users of their data. I had not made the cost-of-inaction case in my original pitch.

I went away and built it. I pulled three months of cross-service incident data and showed that 8 of the 14 multi-service incidents that quarter had taken longer to diagnose specifically because of the inconsistent error format, with an average of 22 extra minutes per incident. I sent that doc to the team's lead with a follow-up offer: if we agreed on the shared format, my team would do the dashboard migration work for them, scoped to about three engineering days of our own time. They agreed within two days.

The format rolled out across the three services over the next two months. In the next quarter, the average diagnosis time on multi-service incidents dropped from 47 minutes to 28. Six months later, the same lead reached out about a different cross-service initiative, which I read as evidence that the way the alignment landed was healthy. The reflection: I should have brought the data first, not the proposal. I had assumed the case was self-evident, and that assumption cost me about three weeks of latency in getting alignment. I now lead with the cost-of-inaction analysis on any cross-team ask of meaningful size.'

What lands: a real misalignment with a legitimate counter-argument, the listening beat that surfaced the actual concern, a data-led re-pitch with an offer to absorb part of the cost, the relationship surviving (the same lead reaching out later), and a reusable lesson the candidate now applies.

Prompt 5: 'Describe a project where you worked across engineering, product, and design.'

Model answer (strong, classic three-function project, focus on shared definitions)

'In Q3 2024 I was a senior engineer working on the redesign of our pricing page, a project that had been attempted twice before and stalled both times. Engineering was my team, product was led by a mid-level PM I had worked with on smaller projects, and design was led by a designer who had been at the company longer than either of us. Each prior attempt had stalled at the same point: the three functions had different ideas about what 'launched' looked like and the disagreement only surfaced four weeks before the originally-planned launch.

I owned avoiding the third stall.

The first thing I did was propose a 60-minute kickoff with a single agenda item: write down what 'launched' means for this project, in one document, edited live. The PM defined launch as 'shipped to 100% of new visitors with the new pricing structure'. The designer defined launch as 'shipped with all four breakpoints, with the visual system pieces I am building reusable for the next two pages'. I defined launch as 'shipped behind a feature flag with rollback under 90 seconds and the success metric instrumented'. Three different definitions. We spent the rest of the meeting reconciling them into a single launch contract that all three of us signed.

The contract caught a real issue early. The designer's reusable-system requirement was a quarter of the design work and would not directly affect the v1 user experience; we agreed to defer that to a follow-on, which the designer then prioritised in their own roadmap. We also agreed that the PM would own the metric instrumentation requirement until the success metric had stabilized, not just until launch day.

The redesign shipped in 11 weeks, against an estimated 14. Conversion on the pricing page improved by 19% in the first 60 days, sustained over two quarters. The follow-on design-system work shipped the next quarter and was reused in the redesign of two other pages. The reflection: I should have made the launch-contract kickoff a default for any project crossing two or more functions, regardless of size. The previous two attempts had stalled exactly because nobody had written this down.'

What lands: an explicit history of stalls (which gives the listener context), a structured kickoff with a specific artefact (the launch contract), three different definitions of done explicitly reconciled, a defer decision that respected the designer's longer-term work, sustained metric, and a generalised principle.

Prompt 6: 'Tell me about a time a cross-team initiative did not work.'

Model answer (strong, honest failure with three named mistakes)

'In Q1 2023 I tried to organise a cross-team effort to standardise how four services emitted operational metrics. The premise was reasonable: each of the four services had drifted to slightly different metric formats, which made the unified dashboards harder to maintain. The effort did not land in the quarter I had planned for, and ultimately took 18 months to reach the level of standardisation I had originally proposed for one quarter.

I owned the coordination and the failure to land it on the original timeline.

Three things I got wrong, in retrospect. First, I had not done the listening work with each of the four teams before proposing the standardisation. I had a plan in my head, brought it to a kickoff, and discovered there were two technical disagreements about the format that needed to be resolved before any team would commit. Resolving those took six weeks I had not budgeted for. Second, I had no shared cadence; I had assumed teams would update each other through their existing channels, and they did not. The first six weeks of the project happened in private inside each team, and the misalignments compounded. Third, I had no shared accountability doc. Each team thought their slice was someone else's priority, and the work slipped quietly.

I tried to recover three months in. I held a 60-minute reset meeting where I named all three of the above and proposed a rebuild: a shared diagnosis doc, a 20-minute weekly sync, an explicit per-team owner and date. Two of the four teams committed; the other two had moved on to their own quarter's priorities and politely declined. The standardisation eventually landed, but in pieces over the following 18 months, mostly through me catching opportunities as adjacent work happened on each service.

What I changed: I now do the per-team listening conversation before any cross-team kickoff, and I do not call a kickoff until I have a shared diagnosis doc that each team's lead has edited. I have led six cross-team initiatives since with this approach and none have stalled in the same way.'

What lands: a real failure on a real timeline, three specific mistakes named, an honest 'I tried to recover and only partially succeeded', durable behavioural changes, and evidence those changes have worked since.

Pitfalls Specific to This Competency

Four traps that show up most often in cross-team stories:

1. Vague 'we worked closely together' framing. Stories that describe collaboration in feel-good terms without naming the mechanisms read as collaboration-as-vibe. Replace 'we worked closely with the other teams' with 'we set up a 20-minute Tuesday sync with a fixed format, and a shared doc each team owned a slice of'.

2. Skipping the listening step. Stories that go straight from 'I had a plan' to 'I proposed it cross-team' miss the highest-signal beat: understanding what each team was optimising for. Without this, the rest of the story reads as drag-along, not collaboration.

3. Confusing cross-team collaboration with leading without authority. They overlap but the rubric is different. Cross-team collaboration is about constructing the coordination structure; leading without authority is about influencing a decision. Many stories serve both, but be explicit about which competency you are showcasing on which prompt.

4. Credit landing entirely on you. Strong cross-team stories use 'I' for the coordination work the candidate genuinely owned (drafting the diagnosis, running the sync, writing the launch contract) and 'we' or 'they' for the implementation work. Stories where the candidate is the protagonist of every implementation beat read as inflated.

Practice Prompts & Exercises

For each prompt below, draft a 250 to 350 word STAR answer using a real story.

1. Tell me about a time you worked across multiple engineering teams.
2. Describe a cross-functional project that succeeded.
3. Walk me through a project that involved engineering, product, design, and one other function.
4. Tell me about a time you had to align with a team that did not want to align.
5. Describe a stakeholder outside your team you had to keep informed and bring along.
6. Tell me about a cross-team initiative that did not work.
7. Walk me through how you handled a definition-of-done mismatch between two teams.

For every story, name explicitly the cross-team surface (which functions, which teams, which roles), the listening you did before pitching, the coordination mechanism you constructed, and at least one alignment failure you handled actively.

Bridge / Cross-References

This lesson opens the Teamwork & Collaboration category and overlaps significantly with the prior category. The most useful Foundations companions:

• star-method and story-banking give you the structure and the inventory of stories.
• crafting-compelling-stories shapes the cross-team narrative around shared problem, conflict, and resolution.
• quantifying-impact is what makes the Result row defensible in cross-team work, where credit is naturally distributed.
• reading-the-question is particularly useful here: cross-team prompts and leading-without-authority prompts can sound similar but are graded differently.

The next lesson, Conflict Resolution, picks up where this one leaves off. Cross-team work and conflict are deeply related: most cross-team initiatives have a moment of friction that needs to be handled well, and most workplace conflicts originate at team boundaries. The next lesson treats the friction directly.