TBM 423: Why Defining Teams Is So Hard
Hint: It’s not some magic skill.
This post is for anyone who has tried to answer “What is a team?” and been caught between three things: confusion at why such a simple question was so hard, a gut feeling that if people could just describe reality honestly things would get so much better, and the deflating experience of watching that honesty get met with resistance.
Why is it so easy to describe how an organization actually works, and so hard to say it out loud?
Chris Argyris called these “undiscussables”: things everyone in the room can see, but that are tacitly off-limits to name. Not because the description requires special expertise, but because the act of describing threatens existing narratives, incentives, and power structures. The skill barrier is low. The potential political costs are high.
This post is about one of the most common undiscussables in product and technology organizations: the gap between how teams are described and how they actually work.
In workshops, provided we’ve built enough psychological safety, I’ve never had trouble unpacking the various “frames” of organizational design.
The product-centric view: capabilities, features, value propositions, business outcomes.
The design view: end-to-end experiences, customer journeys, touchpoints, information architecture, service blueprints that map the full service delivery chain including what happens behind the curtain.
The technology view: architecture, interfaces, code ownership, the services that actually run in production. The platform view: deeper in the stack, a couple hops away from the customer, something that can absolutely be treated as a product but is an order of magnitude more complex to organize around.
And then there’s the collaboration view: who is actually talking to whom, which Slack channels carry the real decisions, which meetings actually unblock work, which cross-team relationships hold things together that the org chart says should be separate. This one rarely shows up on any diagram, but it’s often the most accurate picture of how work gets done.
It was never rocket science.
These frames are in the room. People can describe them. People know them. The question is what to do next. How to take that reality and deal with it. Or not.
The Tension Between Frames
Even in organizations that have ostensibly adopted cross-functional teams, product management, design, and technology hold different views of team structure, purpose, and ownership.
Product divides the world into capabilities, “products,” feature areas, whatever framing the strategy demands. Design sees customer segments, end-to-end journeys, and touchpoints that often span multiple product areas. Technology has varying degrees of real-world alignment to either mental model. Not because they don’t want to be aligned with value. They do. But they’ve got systems and architecture to contend with, and the legacy of decisions made over years.
It is easy to McKinsey on in and say “these are your real products.” But McKinsey wasn’t there during the time the company was running a well-oiled feature factory and building a massive amount of organizational and technical debt in the process.
A mapping needs to take place. And teams fall across a spectrum: from high coherence, where the product view and the tech org naturally align, to deep misalignment, where the technology organization reflects architecture, and technical domain ownership that bears little resemblance to how product or design thinks about the world.
The cracks start to show first with UX and product.
Designers get assigned to multiple teams, or to a single “product” that multiple engineering teams serve. A designer might see the customer journey as one continuous experience while product has carved it into three capability areas and engineering has split it across five services. PMs compete with each other over a shared “resource” (a team). One PM needs the coordination of a dozen teams to deliver on what they see as a single capability. Elsewhere, four PMs are fighting over the efforts of one team because it owns a service at the intersection of multiple product areas. This is common.
This is often heavily dependent on architecture.
You can’t just flip a switch and magically rearchitect everything, or staff up, or will your way to perfect coherence. As Will Larson puts it: “The fact that something stops working at significantly increased scale is a sign that it was designed appropriately to the previous constraints rather than being over-designed.” The architecture was built for a different reality. The reverse Conway maneuver, intentionally restructuring teams to match the architecture you want, is compelling in theory. But the existing architecture constrains how quickly you can actually pull it off. And most aspirational models underestimate this.
And all of this assumes the org has a strategy that’s stable enough for the definitions, capabilities, personas, levers, jobs, to actually hold. The product taxonomy itself might still be in flux.
The Pendulum
I see a pendulum swing here.
First, a swing into “what are the actual products?” The org goes deep in that direction: naming capabilities, drawing taxonomies, mapping customer journeys, defining experiences. But that only gives you part of the view.
Then a swing into “but how are our teams actually structured?” Which tilts you to the technology reality: the actual org chart, the actual services, the actual on-call rotations, the actual code ownership. Design, meanwhile, is trying to hold the customer experience together across both frames, seeing the seams that neither product’s taxonomy nor tech’s org chart acknowledges.
The problem is that it’s very hard to have both going at once. You’re either looking at the product map or the team map, and the two rarely overlap cleanly. This is the crux.
It is actually relatively easy to name product areas and capabilities from a more academic angle. It is much harder to actually align architecture, incentives, funding, and team structure around those things.
There’s a history here worth remembering. In the mid to late 2010s, it became wildly popular to call everything “a product.” Every team was a product. Every service was a product. Every internal tool was a product. But that left companies with a vast complex of product-in-name-only. These weren’t products. They were teams relabeled to fit a narrative.
Now the pendulum has swung the other way. Companies are looking to “simplify,” so they claim to have very few products, or very few “journeys” or “experiences.” And that actually goes in the other direction: it obscures the collaboration reality for the purpose of simplicity. When you say you have three products and the truth is that each of those “products” requires the coordination of fifteen teams across four architectural layers, you haven’t simplified anything. You’ve just made it harder to talk about what’s actually happening.
If there’s an enterprise architecture trap, where capability maps get built in a vacuum and end up as a “museum of boxes” that nobody uses, there is also a market-tecture or product framework trap.
It picks one convenient model, like experiences, journeys, or jobs, squints, and imagines this to be true because somehow the categories are mutually exclusive and collectively exhaustive. They rarely are.
Design can fall into its own version of this: the service blueprint or journey map that elegantly describes the customer experience as a continuous flow, when in reality that flow is stitched together by six teams who don’t share a PM, a codebase, or a planning cadence. The domain-driven design community understands this: bounded context boundaries should match team boundaries, but those boundaries are discovered, not invented, and they rarely match existing org charts. Service boundaries, as one consulting group puts it, are “organizational confessions.” They reveal power structures and historical accidents more than intentional design.
And the domains themselves aren’t static. Strategic shifts are normal. What looks like a clean boundary today may fragment tomorrow. DDD can slip into replicating the semantics of a domain at a point in time while ignoring that a lot of the understanding is emergent, that we don’t know yet.
There’s another layer that often gets lost: organizational history.
Every team carries the sediments of decisions from past re-orgs, past strategies, past leaders. There’s knowing what they are now, but also understanding the evolution that got them here, which may have been lost to the sands of time. A team that looks puzzlingly structured today may make perfect sense when you learn it was the remnant of a 2019 platform bet that was half-funded and never fully unwound. But that context is rarely written down, and the people who carried it have often moved on.
Triad Fractals
The idea of “fractal” triads, product, design, and engineering mirrored at every level of the org, is very compelling. And it exists in many cases. But the incentive structures for those groups can be very different, even when the intent is aligned.
I’ve written about this before. Cross-functional teams are a mirror of the managers they report into. If the product director, design director, and engineering manager don’t know, trust, and actively collaborate with each other, the front-line team will struggle no matter how well-structured it is on paper. As David Dame observed: “The C-suite is cross-functional with complete oversight. The team is cross-functional with limited sight outside the teams. The middle management continues to be functional.”
The self-similarity breaks at the manager level. And it breaks because the incentives are not self-similar. Product, tech, and design managers face structurally different pressures: headcount costs, reliability accountability, matrixed assignments, career ladder ownership. The fractal looks clean on paper but fractures at the management layer.
There’s something else here that doesn’t get talked about enough. Engineering culture matters in many companies, more than org designers tend to acknowledge. Engineering managers actually manage people. They build team culture. They own long-term systems and the relationships around them. They run on-call rotations. They hire, mentor, and create career paths. These are the people building and shipping.
I’ve seen models that try to pull engineers into an overall “product is everyone” tent, only to discover that PMs are largely solo operators. Product orgs don’t do team culture nearly as well as they would like to believe. You can’t dissolve engineering’s team-building function into a product-centric model and expect the same cohesion to emerge. Engineering culture is a load-bearing wall, and ripping it out to satisfy an org chart aesthetic has real consequences. Larson is emphatic on this point: “Sustained productivity comes from high-performing teams, and disassembling a high-performing team leads to a significant loss of productivity, even if the members are fully retained.”
I’ve observed CTOs create complete parallel goal systems under the premise of the “technology strategy,” their managers running a separate set of OKRs alongside the team’s shared goals. Everyone reports into two goal hierarchies simultaneously. And I think this ultimately happened because the CTO was under pressure around reliability, performance, and technical debt, pressures that the product-centric model doesn’t absorb or even acknowledge.
Why It Stays This Way
Most systems in companies flatten this reality. You end up with a flattened version of what exists, a single org chart, a single taxonomy, a single set of team names, when the truth is that some product-team pairings have high coherence and others require elaborate mappings just to make sense of the world. There is resistance to calling out that complexity, because it strikes at incentives, org structure, hints of re-orgs, maybe even layoffs.
Herbert Simon defined design as “devising courses of action aimed at changing existing situations into preferred ones.” The gap between present and preferred is literally design’s subject matter. But design theory also warns that the “preferred future” org chart carries embedded assumptions about power, investment, and complexity that typically go unexamined. Whose future gets designed? Whose reality gets erased? Those questions are usually left implicit.
Tech actually carries the headcount costs. Product can name things whatever they want, capabilities, products, areas, but the salaries sit in the engineering budget. Product management is a small, lightweight function. Maybe 1 PM per 8-12 engineers. They can propose structures with relatively low personal risk. If the taxonomy doesn’t work, they rename it. The cost of being wrong is low for them.
Consider how this asymmetry plays out in practice. A single PM might be responsible for a “product area” that requires coordinated work from a dozen engineering teams. That PM draws a box on a slide and calls it their product. But each of those engineering teams has a manager, a budget, a hiring plan, an on-call rotation, and a set of systems they’re accountable for. When the mapping is bad, teams split across domains, specialists stranded, on-call rotations fragmented, tech leaders absorb the operational pain. Which then leads to attrition, burnout, reliability incidents, slowed delivery.
Meanwhile, in another part of the org, four PMs are fighting over the efforts of one team. That team owns a critical shared service. Each PM has their own roadmap, their own priorities, their own stakeholders. The team can’t satisfy any of them fully, and every sprint planning is a negotiation about whose work comes first. Product gets to describe the world; tech has to live in it.
Design sits in the worst position: a small team, usually matrixed or shared, with no budget authority and no structural home. They’re asked to be “part of the team” but spread across multiple product surfaces. They’re thinking in journeys, touchpoints, and service blueprints, seeing the customer experience as a continuous whole that spans all these arbitrary product boundaries. They can often see where the seams are, but have no organizational power to push back.
So you get a pattern. Product defines the narrative with relatively low cost if they’re wrong. Tech resists or quietly maintains a shadow structure because the cost of change is high. Design absorbs the incoherence because they have no structural power to fix it.
The engineering manager incentives reinforce this. Headcount scales with influence and promotion eligibility. Managers who own a technology area can recruit specialists and offer clear career ladders. They’re accountable for uptime and incidents regardless of the org model. Honestly describing misalignment can trigger a re-org where the reality-teller loses their role. And product strategy shifts quarterly while architecture pays off over years, so eng leaders rationally resist being reorganized around something that might change again in six months.
These are structural incentives, not character flaws, and treating them otherwise misses the point.
Pragmatic Change Aversion
What a lot of frameworks miss is that this is a highly politically charged situation. I experienced this in my past when I would do Kanban-related work. The act of dumping reality onto a board was theoretically easy. It was MUCH harder when that reality bumped up against the narrative tension that exists in most orgs.
And this manifests in ways that can’t be pinned immediately as “change aversion.” You have a manager whose team has been perpetually underfunded, who has been advocating for a platform approach for years, suddenly told that “you are a platform,” when realistically they are very early in that journey. And leaders have all these economies-of-scale assumptions around that, which the manager knows are very far off. Or you have the leader who is perpetually tired of explaining all the dependencies for their group, and knows they have worn that argument thin, basically pushing back on yet again showing those dependencies. Or the director who knows leadership’s penchant for glossing over the real-world complexity of things, and “knows how things go.”
This isn’t bad-faith politics. It’s earned skepticism from people who have context. The underfunded manager, the dependency-weary leader, the director who’s seen glossy narratives collapse: they’re reacting rationally to past experience. Calling it “politics” flattens legitimate, informed pushback into something dismissable. The political charge comes from the fact that surfacing reality threatens existing narratives, not because people are acting in bad faith.
Nils Brunsson’s “organized hypocrisy” theory offers a useful lens here. Organizations may actually need a gap between what they say and what they do. It lets them satisfy contradictory demands from different stakeholders simultaneously. The aspirational model keeps executives, boards, and customers happy. The real model lets practitioners get work done. The delta can be functional, a North Star you’re genuinely moving toward. But it becomes dysfunctional when it’s permanent theater that no one believes or acts on. The key question is whether leadership treats the gap as something to incrementally close, or as a convenient fiction to avoid hard decisions.
So What?
Organizations need a legible, aspirational model of how things should work. They also need an honest account of how things actually work. Most orgs struggle to hold both at once.
Closing the gap requires honest assessment, resource reallocation, structural change, and patience, all of which threaten the people and incentives currently in place. The tension is self-reinforcing.
Describing reality is not a hard skill. It’s not an expert activity. You can start with templates, spectrums, plain-language dimensions: relationship to technology, relationship to customers, how work arrives, how performance is assessed, what mandate the team actually has. Place your team along each spectrum. No certification required.
The hard part isn’t filling in the template. It’s the willingness to be honest about where you actually land. The skill barrier is low. The courage and trust barrier is high.
The question isn’t whether you can see the two (or more) org charts. You already can. The question is whether your organization can hold both views at once, and do something with the gap.
A note for change agents: don’t internalize this tension. It may just be the way it is. The organized hypocrisy may feel unbearable, the gap between the slide deck and the Slack channel may wear you down, and the impulse is to take it personally or burn out trying to close it yourself. But the incoherence isn’t yours to fix alone, and it may not be fixable in the way you imagine. What you can do is surf it. Find the pockets where the two org charts happen to overlap, where a team has enough coherence to move, where a leader is honest enough to work with reality instead of against it. The tension is where the opportunity lives. Not because the tension is good, but because it’s where the system is most ready to shift, if someone is paying attention.
Questions
If someone outside your company asked “how are your teams organized?”, could you give one answer that product, design, and engineering would all agree with?
What would happen if you put the real map of how work flows across teams on a wall in a room full of your leaders?
Which teams in your org are carrying the weight of multiple team types at once, and does anyone acknowledge that?
Where is the biggest gap between what your teams are called and what they actually do?
Are there things about how your teams work that everyone knows but no one will say in a planning meeting?
When was the last time a reorganization actually changed how work got done, versus just changing who reported to whom?
If you removed all the team names and org chart labels, could you still describe who depends on whom to ship something?
Are you trying to describe your teams as they are, or as you wish they were, and do you know which one you’re doing?
Teams are easy to draw on an org chart and hard to draw around actual work. In 15+ years running engineering portfolios the recurring trap was defining teams by reporting line — then discovering the real delivery unit was a cross-cutting group nobody had named. Defining a team is really deciding which dependencies you're willing to make someone else's problem.
I learned that a Team is a group of interdependent people working together to achieve a shared goal. Each has a part to play, without which the goal could not be accomplished. A team may consist of a designer, product manager, several kinds of engineers, and perhaps some others. A "team" on an org chart could be a group in reality.
A group is a collection of people working relatively independently. You might have a group of account managers (that don't share accounts).