When I worked with Awareness Inc as a fractional growth advisor, one of the first things I mapped was how the engineering team was structured. The teams were organized around technical systems - backend, frontend, data - which made sense from an infrastructure standpoint and made almost no sense from a product standpoint. The product decisions being made reflected the structure: the roadmap was a queue of technically coherent work items rather than a prioritized response to customer problems.
Reorganizing around customer segments rather than technical systems changed what the team built and in what order. The same people, the same headcount, the same codebase. Different structure. The output improved within a quarter, not because anyone worked harder but because the team finally understood who they were building for. (see also: product org structure)
That experience shaped how I think about team structure across every engagement since. The org chart is not a formality. It determines what gets prioritized, what gets ignored, and who has the standing to say no.
The org chart is not a formality. It determines what gets prioritized, what gets ignored, and who has the standing to say no.
Structure Determines the Roadmap
Most product teams do not realize their roadmap problems are actually structure problems. When a team is organized around technical domains, engineers optimize for technical cleanliness. When a team is organized around customer journeys, they optimize for customer outcomes. Both are internally coherent. Only one produces the right product decisions.
At EverQuote, expanding from auto insurance to a multi-vertical marketplace required restructuring how product and engineering teams were paired. Each new vertical needed full-stack ownership - someone who understood the demand economics, the supply side, and the integration points. Cross-functional pods organized around verticals moved faster than any shared-services model would have allowed.
The pattern is consistent: teams organized around what they build optimize for the artifact. Teams organized around who they serve optimize for the outcome. The roadmap reflects the organizing principle whether you intend it to or not.
Size Thresholds That Change Everything
The structure that works at 8 engineers breaks at 25 and breaks again at 80. The inflection points are predictable. At roughly 15 to 20 engineers, informal coordination stops working and you need explicit team boundaries with clear ownership. At 50 or more, you need a deliberate decision about whether teams are organized by product area, customer segment, platform layer, or some combination.
The mistake I see most often is holding onto a structure past its useful life because changing it is uncomfortable. The team grew. The structure did not. Now the roadmap is a negotiation between teams with conflicting incentives rather than a statement of product priorities. This is not a people problem. It is a structure problem that will persist through any personnel change. (see also: directly responsible individuals)
The signal that you have hit an inflection point: decisions that used to resolve quickly in one conversation now require multiple meetings and still do not fully resolve. The coordination cost has exceeded the benefit of the existing structure.
How Structure Shapes Technical Decisions
Team structure does not just affect the roadmap - it affects the architecture. Conway's Law observes that organizations design systems that mirror their communication structures. A team organized around technical layers produces layered architecture. A team organized around customer journeys produces service boundaries that map to customer experiences.
This is not deterministic but it is strong. I have seen product teams restructure around customer segments and find, six months later, that the technical architecture had begun to shift in the same direction - not through a deliberate technical initiative but through the accumulated effect of who was talking to whom about what.
The implication: if you want a technical architecture that supports a particular product strategy, the team structure needs to support that strategy first. You cannot get there by drawing the architecture you want and hoping the team structure catches up.
Remote and Distributed Teams Are a Structure Problem
Distributed teams fail for structure reasons more than timezone reasons. The common failure mode: a team that worked well in-person tries to go distributed without changing how work is coordinated. Daily standups move to video. Everything else stays the same. Six months later, things that used to resolve in a two-minute hallway conversation are taking a week of async threads.
The fix is not more meetings. It is making decisions explicit that were previously implicit. Who owns what. What requires synchronous input versus what can be decided asynchronously. What the escalation path is when two teams disagree. What the definition of done is for each team's output. These things existed informally in-person. Distributed teams need them written down and agreed upon.
The teams that handle distributed work well treated the move to distributed as an opportunity to make their coordination structure explicit rather than assuming the existing informal structure would survive the transition.
When to Restructure and When to Wait
Restructuring has a high human cost even when it is the right decision. People's roles, reporting relationships, and career paths change. The teams that handle restructuring well communicate the why specifically and early, give people maximum lead time, and acknowledge the disruption honestly rather than packaging it as purely positive.
The conditions that justify restructuring: the existing structure is producing systematic misalignment between what teams optimize for and what the product needs; the coordination overhead is measurably slowing down important decisions; or the company's strategy has changed in a way that the current structure cannot support.
The conditions that do not justify restructuring: a single difficult project, a specific interpersonal conflict, or pressure to do something in response to a product failure. These problems require different interventions.
The teams that handle restructuring well communicate the why specifically and early, give people maximum lead time, and acknowledge the disruption honestly rather than packaging it as purely positive.
What to Optimize For
The right team structure minimizes coordination cost for the decisions that happen most frequently and maximizes ownership clarity for the things that matter most to the product. In practice, most team structures optimize for historical reasons - how the company was founded, who got hired first, which executive had the most organizational gravity at a particular moment.
Revisiting structure deliberately - asking 'if we were designing this from scratch today, would we do it this way?' - is one of the higher-leverage things a product leader can do. Not to restructure constantly, which destroys continuity, but to understand clearly where the current structure creates friction and whether that friction is worth the cost of changing it.
