Lead Across Functions Without Authority

Proof required

Submit: (1) a dependency map naming the two (or more) teams involved, the specific work that depends on them collaborating, and the current state of that dependency — how handoffs happen, what visibility each team has into the other's work, and where handoffs fail; (2) a failure evidence log: at minimum 4 specific incidents over the past 6–8 weeks where the cross-functional dependency produced a delay, rework, duplicate effort, or a decision made without the right team's input; (3) a root cause diagnosis (150 words minimum): the specific structural gap (incentive misalignment, visibility gap, no shared rituals, no escalation path) causing the failure pattern; (4) a pre-committed structural intervention — written before implementation begins.

What gets checked

• Dependency map is specific about the flow of work — not 'PM and engineering need to collaborate better' but 'PM specs features for engineering, but engineering only sees specs in sprint planning, not during discovery — engineering discovers design problems at the worst possible time'
• Failure evidence is incident-specific — each incident must name what was delayed, reworked, or duplicated, and what the cost was; 'we had some alignment issues' is not an incident
• Pre-committed intervention addresses the diagnosed structural gap — if the gap is visibility (engineering doesn't see PM discovery work), the intervention must provide visibility earlier, not more meetings; an intervention that addresses a different gap than the one diagnosed will not produce the expected result

Common mistakes

• Diagnosing the cross-functional collaboration problem as a personality conflict — 'the two team leads don't get along' may be true, but it is not a structural diagnosis; the structural question is what environment allows a personality conflict to create downstream delivery failures
• Proposing a kickoff meeting as the intervention — a one-time meeting is not a structural change; the intervention must change what happens on an ongoing basis (a shared backlog, joint discovery sessions, a decision-rights framework, a cross-team weekly sync with a specific agenda format)
• Mapping the formal org chart rather than the actual dependency flow — the formal chart shows reporting lines; the dependency map shows where work actually passes between teams and where it breaks

Resources

What a verifier looks for

• Dependency specificity: ask the submitter to trace one unit of work from start to finish across the two teams — where does it hand off, who owns it at each point, and where has the handoff failed
• Structural vs. interpersonal diagnosis: ask whether a new person in each role would have the same cross-functional failure pattern — if yes, the problem is structural; if no, it's interpersonal, and the structural intervention will not solve it
• Intervention logic: ask the submitter to explain how the proposed intervention addresses the specific structural gap diagnosed — an intervention that doesn't directly target the diagnosed gap is likely to be ineffective

Proof required

Submit: (1) an implementation log with at least 3 dated entries showing how the structural change was put in place, including what resistance or friction you encountered across the team boundary; (2) a 6–8 week post-change incident comparison: re-assess the same 4 failure incident categories from M1; for at least 2, provide a specific example of a situation that would have produced the failure under the old structure but was handled differently under the new one; (3) at least 2 direct observations from people on the other team (not your own team) noting a difference in how the collaboration feels from their side.

What gets checked

• Post-change incident comparison uses the same 4 failure categories from M1 — adding new categories or removing the hard-to-improve ones invalidates the comparison
• Cross-team perspective evidence is genuine — the observations from the other team must be attributed (a quote, a message, a retro comment) and must describe a specific change in experience, not just 'things are better'
• 'Would have failed' examples are specific — name the situation, what would have happened under the old structure, and what happened instead

Common mistakes

• Collecting only your own team's perspective on whether collaboration improved — cross-functional improvements must be validated from both sides; your team's perception of improvement is not sufficient evidence that the other team's experience changed
• Measuring activity (number of cross-team meetings, messages exchanged) rather than outcomes (rework prevented, decisions made earlier) — activity metrics are not outcome metrics
• Implementation friction dismissed as temporary — if the other team is not participating in the new structure, the structural change has not been implemented; friction that persists beyond 3 weeks is a signal that the intervention did not address the actual barrier

Resources

What a verifier looks for

• Other-team perspective: confirm that the 2 cross-team observations are from people on the other team — ask who each person is and their team affiliation
• Incident comparison quality: ask the submitter to describe the best example of a situation handled differently under the new structure — a real incident with before/after detail is more credible than a general observation
• Persistence: ask whether all parties across the team boundary are still using the new structure 6+ weeks in — if one side has drifted back to the old pattern, the improvement is not structural

Proof required

Submit: (1) a before/after summary: the M1 failure incident rate for the most prevalent category, the post-change rate, the structural change implemented, and 2 specific examples of situations handled differently; (2) a lessons-learned document (300 words minimum): what the structural change fixed, what cross-functional friction still exists, and what you would change about the intervention design if starting again; (3) documentation of a real-time Q&A session with a named reviewer who has ≥3 years of product management or engineering leadership experience and a verifiable professional profile — the documentation must include specific challenge questions and your responses; the reviewer must not be a member of either team involved.

What gets checked

• Before/after summary accounts for other changes — if the team composition or project type changed during the M2 period, the summary must acknowledge this as a possible confound
• Lessons-learned is honest about residual friction — no structural change eliminates all cross-functional friction; naming what still does not work well is more credible than claiming comprehensive improvement
• Reviewer is not a member of either team — a reviewer from within one of the two involved teams cannot give an unbiased view of whether the cross-functional change worked

Common mistakes

• Before/after summary with no confound acknowledgement — if headcount, project urgency, or leadership attention changed during the M2 period, these must be named as potential confounds in the attribution analysis
• Lessons-learned that credits the structural change without naming any residual friction — all cross-functional relationships have friction; a lessons-learned with no friction acknowledgement is either dishonest or insufficiently observed
• Reviewer from the same organisation who was aware of the change — a reviewer who knew about the intervention and may have been influenced by its reputation does not give an unbiased adversarial view

Resources

What a verifier looks for

• Reviewer independence: confirm that the reviewer is not a member of either team and was not aware of the intervention during the M2 period — ask who the reviewer is and their relationship to the two teams
• Confound challenge: ask the submitter what else changed between M1 and M3 — if team composition, project type, or leadership attention changed, ask how they are confident the structural change (and not those changes) produced the improvement
• Residual friction: ask what cross-functional friction still exists after the structural change — a confident answer with specific examples signals genuine self-assessment