The gap we helped create by staying in our lanes
Reaching Developing is real progress — and it's worth naming. Processes exist. Teams are performing. But this stage has a particular trap: we can mistake functional discipline for organizational integration. Product runs well. Engineering runs well. Design runs well. And they still don't move together. Before we look at the system, we look at how we may have contributed to that gap — by optimizing for our own area while the seams between us frayed.
Developing stage feels like arrival. Teams have rituals, some shared language, clearer accountability than before. The danger is that this comfort makes the remaining gap invisible. Integration requires something harder than good process — it requires each leader to genuinely hold the whole, not just their part. That's the shift this stage demands of us personally before we ask it of our teams.
The space between product, engineering, and design is where most integration breaks down. It's no one's explicit job — which means it's everyone's implicit one, which means it tends not to get done.
- "That handoff is between PM and engineering — not really my area"
- "We do well within our team; the coordination issues are an org problem"
- "I flagged it in the all-hands — someone should pick it up"
- "The seam between our teams is breaking — I'm going to name that and sit in the fix"
- "I asked my counterpart directly what's not working across our boundary"
- "We designed a working agreement together, rather than assuming one existed"
In Developing orgs, customer insight often lives in product. Engineering and design are told what customers need, rather than developing their own intuition. Integrated orgs treat customer understanding as a shared leadership responsibility.
- "Product handles the customer stuff — we build what they specify"
- "I haven't talked to a customer this quarter — that's not really my role"
- "We use the research product shares with us"
- "Engineering and design joined the last three customer calls — everyone has a direct line"
- "We built customer evidence into how we discuss and defend decisions across teams"
- "I pushed back on a roadmap item because I'd heard something different from customers directly"
Strategy documents exist in most Developing orgs. The gap is that they don't reach into everyday choices. Integration means strategy is alive in how people decide what to work on, what to stop, and what to say no to — not just in what gets presented at an offsite.
- "We have a strategy doc — it lives in Notion somewhere"
- "We revisit priorities quarterly but the day-to-day is driven by requests"
- "We say no to things but not always because of a clear strategic reason"
- "Our strategy is a live decision filter — we reference it when things conflict"
- "I can explain in two sentences how today's work connects to the one-year goal"
- "Our last 'no' came with a clear strategic reason that the team understood and agreed with"
Developing orgs ship consistently. Integrated orgs learn consistently. The difference is whether outcomes — what actually happened after shipping — are tracked, shared, and fed back into the next cycle. Without that loop, teams optimize for output, not impact.
- "We shipped it — tracking results is analytics' job"
- "We looked at launch metrics but didn't follow up at 30/60/90 days"
- "We moved to the next thing before we knew if the last thing worked"
- "We defined success criteria before shipping and reviewed them as a team afterward"
- "We shared what we learned from this release — including what didn't work — in the next planning cycle"
- "Outcomes from last quarter are informing what we're building this quarter"
Do this individually first, then compare. The cross-functional gaps tend to show up most clearly where people's answers differ.
We've been well-coordinated within our discipline but less so across product, engineering, and design
Our strategy exists as a document but doesn't visibly shape daily prioritization decisions
Customer understanding lives primarily in product — engineering and design don't have direct contact
We shipped things this quarter but couldn't say confidently what impact they had
We noticed a coordination failure between teams and waited for someone else to address it
We optimized for our team's performance in ways that made it harder for adjacent teams
"Integration isn't something that happens between well-run teams automatically. It requires leaders who are willing to hold more than their own area — who treat the seams as part of their job, not someone else's."
What the Developing → Integrated gap looks like in practice
These patterns are subtler than Stage 1. Things are working — which makes the remaining dysfunction easier to rationalize. Look for the gap between what the process says and what actually happens at the boundaries.
Well-run silos
Product, engineering, and design each perform well internally. But joint decisions are slow, tense, or just don't get made. The seams are where things fall apart.
Strategy stays in the room
Leadership understands the strategy. Teams have heard it. But it hasn't become a usable decision-making tool at the working level — it lives in slides, not in daily choices.
Output without outcome
The team ships consistently and on time. But whether what shipped actually worked — for users, for the business — is tracked loosely if at all. Velocity is visible; impact isn't.
Customer insight is one team's asset
Research and customer contact live in product. Engineering and design hear conclusions, not conversations. Empathy is secondhand — and decisions show it.
Coordination by escalation
Cross-team conflicts and trade-offs get resolved by going up rather than across. Leaders spend time refereeing decisions their teams should be making together.
Rhythm without reflection
Standups, sprints, planning cycles all run on time. But the cadence produces delivery, not learning. Retros recycle the same themes. The loop isn't closing.
Metrics that don't connect
Each team has metrics. They don't add up to a coherent picture of what the org is trying to do. No one can draw a clear line from their team's number to the business outcome.
Culture is declared, not demonstrated
Values are posted. The behaviors they imply are inconsistent. What actually gets rewarded and what gets tolerated tell a different story than what's written on the wall.
Cross-team decisions take significantly longer than within-team decisions — and the friction is political, not just logistical
We can't easily say what the last three things we shipped actually did — in user or business terms
Engineering and design leaders haven't spoken directly with a customer in the last 60 days
If you asked someone on the team to explain how their current work connects to the annual strategy, they'd struggle
Trade-offs between teams regularly escalate to leadership rather than being resolved at the working level
What we say we value and what actually gets rewarded in this team are not fully consistent
The thinking that keeps well-run teams from integrating
These patterns are harder to spot than Stage 1 because they often wear the clothes of professionalism and discipline. They're the mindsets of people who are genuinely good at their jobs — and who have unconsciously stopped at the boundary of their own area.
"A collection of well-run teams is not the same as an integrated organization. The gap between them is where most growth stalls — and where the most important leadership work actually lives."
What we're each protecting when integration stalls
The resistance at this stage is more sophisticated than Stage 1. It doesn't look like avoidance — it looks like professionalism. Understanding what's actually being protected helps us design conversations and structures that don't just demand integration, but make it feel worth the cost.
- Domain authority — deep expertise that loses primacy when decisions become truly cross-functional
- A high-performing team identity that feels threatened by being asked to slow down for integration
- The comfort of clear metrics in your own lane vs. shared metrics where others' performance affects your score
- Influence that comes from being the customer expert — which dilutes when everyone has direct access
- Speed — genuine integration requires more upfront coordination, which feels like a tax before it feels like a dividend
- Functional excellence as an identity — "we're a great engineering org" can resist becoming "we're a great product org"
- Existing power structures where functional leaders have more autonomy than cross-functional accountability would allow
- A planning process that's efficient but doesn't actually integrate — replacing it is disruptive before it's better
- The narrative of success — it's hard to say "we're good at delivery but not at learning" when delivery is what leadership celebrates
- Short-term predictability — integrated ways of working require a transition period where things feel less controlled
"The shift to Integrated asks people to hold a larger unit of success than they're used to — and that's genuinely harder, not just different. Acknowledging that cost honestly is part of what makes the invitation credible."
How to move from coordination to integration
Integration isn't a restructure. It's a set of deliberate practices that make cross-functional behavior the path of least resistance. Start with the seam that's causing the most pain — not the whole system.
Name your one most broken seam
As a leadership trio — product, engineering, design — identify the single cross-functional boundary that creates the most friction. Don't try to fix everything. Map that one seam specifically: what decisions live there, who owns them, what's unclear, and what a working agreement would look like.
Make strategy a decision filter, not a document
Take your current strategy and turn it into three to five questions that a team member can ask themselves when priorities conflict. "Does this move us toward X?" is a usable filter. "We are committed to building world-class Y" is a poster. Test the filter in the next planning cycle.
Put engineering and design in direct customer contact
Not as observers — as participants. One joint customer call per sprint, with engineering and design forming their own conclusions, not just hearing PM's synthesis. The shift in how people talk about users afterward is usually immediate and significant.
Define outcome metrics before the next thing ships
For the next release, agree on three questions you'll answer at 30 days post-launch: did it do what we expected for users, for the business, for the team's learning? Make reviewing those answers a scheduled ritual with the same rigor as the launch itself.
Resolve one cross-team conflict without escalating it
Pick a live trade-off that would normally reach leadership to referee. Design a working session where the teams involved resolve it themselves, with clear criteria for how to decide. Debrief what made that possible — or what got in the way.
Audit one value against actual behavior
Pick one stated value — "customer first," "move fast," "quality" — and honestly assess: where does behavior match it, and where doesn't it? Name one specific behavior change that would close that gap. Make it observable, not aspirational.
How we'll know we've reached Integrated
Integrated doesn't mean frictionless. It means the friction is productive — it surfaces real trade-offs rather than territorial disputes. These are the behavioral signals that integration is genuine, not performed.
Seams are managed, not avoided
Cross-functional boundaries are named and owned. Working agreements exist and hold. When they break, they get fixed at the working level, not escalated.
Strategy lives in daily decisions
People at every level can use the strategy to decide what to work on and what to stop. "That's not our strategy right now" is a complete and sufficient answer.
Everyone has customer contact
Engineering and design don't need PM to translate customers for them. They have their own recent, direct experiences to draw on when making decisions.
Outcomes are tracked and shared
What we shipped and what it did are connected in a visible, shared review. Learning from the last release shapes the next one — not as a hope, but as a practice.
Cross-team decisions are fast
Trade-offs between teams get resolved at the right level, quickly, without drama. The process for making joint decisions is known and trusted.
Values and behavior match
What's written on the wall is consistent with what gets rewarded, what gets addressed, and what gets hired for. New people notice the consistency.
Metrics tell a connected story
Team-level metrics roll up to org-level outcomes that connect to business goals. Someone can draw the line from their daily work to the thing the company is trying to do.
Learning is the rhythm
Retrospectives produce genuine insight, not just action items. What the team learned last cycle visibly shapes what it's doing this cycle. The loop is closed and closed fast.
"Integrated stage is when the organization starts to feel like a single organism rather than a confederation of capable teams. That shift is felt before it's measured — and it changes what's possible."
Where this thinking comes from
The Developing → Integrated transition draws on work about cross-functional alignment, outcome orientation, and the difference between process discipline and organizational learning. These are the sources behind the ideas in this stage.