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).
The two org charts you're describing may actually be three: the one the org shows outward, the one on paper, and the one in the Slack channels.
The gap between them isn't necessarily dysfunction. Sometimes it's how an organization satisfies contradictory demands at once.
The trap for change agents, myself included, repeatedly, is treating that gap as a problem to solve rather than a system to read. Some gaps you close. Some you surf. Some you leave alone because closing them would break something quietly load-bearing.
The skill isn't just honesty. It's knowing which is which.
(The three-sides framing comes from Stefan Kühl, building on Luhmann.)
The product-map / team-map pendulum is the one we all see. There's another one swinging underneath: which teams can actually absorb the next piece of strategy, on what timeline, and at what cost to what they're already carrying. Product describes the world, engineering lives in it, and design usually ends up as the only function tracking that absorption capacity in real time, because they're the ones seeing the seams. Reverse Conway feels out of reach not just because of architectural inertia — we treat a team's capacity to absorb change as infinite and free, when it's the actual constraint.
That part about organizational history plays a lot into why things are the way they are today. Sometimes, even if the structure is extra messy, that history makes it unfeasible to untangle that piece of the mess without a huge amount of power and authority.
"Organizations need a legible, aspirational model of how things should work." And then "The hard part isn’t filling in the template. It’s the willingness to be honest about where you actually land."
It is hard to train orgs to be like such an organization—there are certain defaults. This comes down to what Peter Senge calls—signs of a learning organization.
It is less about how things are and how things should work—it is first about their belief system, why do they even exist collectively as an organization? There has to be some anchor that makes them *be honest* that you mentioned.
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).
The two org charts you're describing may actually be three: the one the org shows outward, the one on paper, and the one in the Slack channels.
The gap between them isn't necessarily dysfunction. Sometimes it's how an organization satisfies contradictory demands at once.
The trap for change agents, myself included, repeatedly, is treating that gap as a problem to solve rather than a system to read. Some gaps you close. Some you surf. Some you leave alone because closing them would break something quietly load-bearing.
The skill isn't just honesty. It's knowing which is which.
(The three-sides framing comes from Stefan Kühl, building on Luhmann.)
https://organizationaldialoguepress.com/book-author/stefan-kuhl/
The product-map / team-map pendulum is the one we all see. There's another one swinging underneath: which teams can actually absorb the next piece of strategy, on what timeline, and at what cost to what they're already carrying. Product describes the world, engineering lives in it, and design usually ends up as the only function tracking that absorption capacity in real time, because they're the ones seeing the seams. Reverse Conway feels out of reach not just because of architectural inertia — we treat a team's capacity to absorb change as infinite and free, when it's the actual constraint.
That part about organizational history plays a lot into why things are the way they are today. Sometimes, even if the structure is extra messy, that history makes it unfeasible to untangle that piece of the mess without a huge amount of power and authority.
"Organizations need a legible, aspirational model of how things should work." And then "The hard part isn’t filling in the template. It’s the willingness to be honest about where you actually land."
It is hard to train orgs to be like such an organization—there are certain defaults. This comes down to what Peter Senge calls—signs of a learning organization.
It is less about how things are and how things should work—it is first about their belief system, why do they even exist collectively as an organization? There has to be some anchor that makes them *be honest* that you mentioned.