Six engineers, three quarters in. Weekly standup, retro every two weeks, sprint planning Monday, sprint review Friday, an architecture review the second Tuesday of the month, OKR tracking, the usual mix of Slack channels. The team ships, but the velocity chart has been flat for two quarters and three engineers are quietly looking. Retros produce theme complaints (too many meetings, scope creep) and no underlying diagnosis. From the outside the team looks well-managed; from inside it feels like rituals running on inertia. Nobody can answer “what is this team’s process actually for” without falling back on the names of meetings.
The reflex is to cut meetings. Cancel one, the others stay; the calendar gets quieter, the velocity stays flat, and the same three engineers keep looking. The problem isn’t meeting volume. The team has no process design: no answer to what each person is at the team to produce, what role they fill, what output flows from them to whom. Cutting rituals doesn’t add design. It removes friction from a system that wasn’t producing anything in particular.
Process beats capacity
NYC port had less infrastructure than Boston or Charleston in 1817. By 1830 it was the dominant Atlantic port and stayed that way for the next century. The difference was one decision in 1818: Black Ball Line started running ships on a published monthly schedule from NYC to Liverpool, full hold or not. Boston ran ships when there was cargo. Charleston the same. Traders started routing through NYC because they could plan around the schedule. Volume followed predictability, predictability compounded into market position, and the gap kept widening for a century. The engineering equivalent is the same shape. A team that ships on schedule draws downstream commitments. Partner teams plan around it. Leadership trusts it with bigger scope. Customers stop hedging. A team that ships fast when convenient does not.
Andy Grove’s High Output Management opens with a breakfast service. Same people, same stove, same eggs. With role design (one cook on the line, one runner, one dishwasher) the kitchen produces roughly twice the output of the same people working as a generalist mob. Grove’s frame is that a manager’s output is the output of the organization under their influence, and the leverage is in process design rather than in the manager’s individual speed at any task. An engineering team is the same shape. A team where everyone does everything looks egalitarian and produces less than a team where each person owns a role that uses their strengths and feeds the next person’s input.
NASA’s Apollo mission control ran the same shape under maximum stakes. Each flight controller owned a specific system: FIDO for trajectory, RETRO for the return burn, EECOM for electrical and life support. The Flight Director consolidated. Each role had a clear handoff to the people whose decisions depended on theirs. The same engineers working as generalists across every screen would have caught nothing in time. When Apollo 13’s CO2 scrubber failed, the room routed the problem to the right console in seconds. The role design was what made that speed possible.
These run on the same mechanism: consumable chunks on a held schedule, each station fed by the one before it. The Toyota Production System named the principle decades later. Place each person where the work arrives. Arrange the layout so output flows to the next station without wasted motion. A line designed that way produces more than the same people working as a generalist mob, because the design strips out the waiting, the searching, and the reaching that eat individual capacity. Engineering teams that ship reliably run the same shape, with whatever chunks and whatever schedule the work can sustain.
Roles as the unit of design
Each station on that line is a role. Team Topologies frames a team as exposing an API: the interface other teams plan against. The same shape applies inside a team. A role is an interface. The rest of the team needs to know what outcome it produces, who is accountable, and the cadence it runs on. Take the code-review queue. Reviewing PRs is the activity, not the role. The engineer on this week’s rotation is accountable for the queue. The outcome is PRs reviewed within four hours, with reviewers learning from each other in the process. The cadence is weekly: the rotation rolls every Monday. A team with that interface explicit has a designed role. A team with just the activity has a queue that may or may not produce anything. Roles fit together by design: one role’s output is another’s input, and engineers cooperate at the boundaries instead of throwing work over a wall. Owning a scope means accountability for what comes out of it, not territory.
A team’s process is the set of roles it runs and the way work passes between them. A team without designed roles still has roles. They emerged accidentally, drifted to whoever was loudest or most senior, and rarely get pruned. Most silos start there: a role belongs to one person not because the team chose them, but because they happened to be the one who picked it up.
Three rules separate designed roles from drifted ones:
Custom to the team, not a template. Spotify Squads, Atlassian Goalies, the latest FAANG framework: every successful process is the team’s own. Importing someone else’s wholesale gets the form without the function. Templates are inputs to design, not the design itself.
Each role owns an outcome, not a task list. A role that lists what to do produces compliance. A role that names the outcome the IC owns produces ownership. The difference shows up over a quarter: owners go deep, propose improvements, push back on bad designs, and stay engaged. Task-fillers don’t. The team’s reputation across the org follows the depth: whatever the team owns gets serious treatment, and the team gets credit for it.
Cadence justifies itself by output. A weekly meeting that exists because “that is our cadence” is a role optimized for nothing in particular. Each recurring role should serve a specific output. An SRE-to-INFRA weekly runs weekly because cross-team dependency surprises happen on a weekly horizon, and the meeting is less evil than the alternative of implementing in silos and surprising each other with operational load. Roles without a justification should be ad-hoc, set up when a purpose appears and dissolved when it goes away.
The manager’s role
The manager designs the interface and picks the people to staff it. Which roles exist, what each one produces, the cadences, the handoffs — those are decisions, not emergent properties. The manager hires into the roles, understands what each engineer does well and badly, and places them where the role’s outcome and the engineer’s strengths meet. When two roles overlap or interfere, redrawing the boundary is the manager’s call.
The manager also decides last. ICs propose. The manager arbitrates from the only seat in the room that sees all roles at once. A team that runs every decision past its manager has a manager doing the team’s work. The reverse failure is a team that never escalates anything, where the manager has quietly stopped owning the scope.
Priorities are the other lever. Most engineers have a tendency to rewrite things they find ugly.
The manager carries the business context that engineers do not always see: what the company is trying to do this quarter, what each system costs to run, what the customer actually pays for. That context turns “rebuild this because it’s ugly” into “fix the slow part first because it doubles conversion.” Low-hanging fruit and process optimization beat rebuilding from scratch nearly every time.
Take a talented IC. Do they ship more inside the process you built than they would alongside the same teammates with no designed roles at all? Grove’s frame from the breakfast service makes this the central test: a manager’s output is the output of the team under their influence. A process that fits the work makes a strong IC compound: their output flows into a role where someone else is waiting for it, and that person’s output flows somewhere in turn. Without designed roles, the same IC works hard and the team still drifts, because the work has nowhere to go between people. That delta, between what the IC ships with the process and what they ship without it, is the manager’s actual output.
The delta has a second face that velocity charts miss. A role with a named outcome and a clear handoff lets the IC running it see who is waiting on their work and what gets built on top of it. That visibility is what makes the team feel like a team, and what makes engineers want to push the work forward instead of clearing tickets. A process that ships work but leaves engineers feeling interchangeable is missing the half of the manager’s output that the engineers themselves feel.
Write the interface down
That kind of visibility does not happen by default. The interface only exists for the rest of the team if it is written down. Every role gets a short entry: the owner, the outcome it produces, the cadence it runs on, the SLA it holds itself to, who pages who when something slips. Team Topologies publishes a Team API template for the team-to-team version, and the same shape works scoped down to the role level. The doc lives somewhere everyone reads, whether a wiki page, a pinned Slack thread, or the README of a process repo. Without a written record the interface lives in one person’s head, and the team is one departure away from rediscovering whose role each thing was. The doc is also where the team negotiates changes: an outcome shifts, a cadence moves, an owner rotates, and the change is visible to everyone affected before it happens. The same doc carries into quarterly reviews. A role’s outcome is what its owner committed to producing, and the review can work from a shared reference instead of from whatever incidents are easiest to recall. Engineers know in advance what the bar is.
Parts II, III, and IV as worked examples
This series puts role design to work. Part II covers the morning declaration and 3pm sync as a productivity cadence: two roles that turn morning intent into the day’s output. Part III covers the responder rotation as the role that protects the others, especially for SRE, DevOps, and platform teams whose work is otherwise pinged into noise. Part IV covers pointing tickets after they close, as the measurement discipline that tells the team where the design is actually working and where it is not.
All three are worked examples of the same discipline. Name the role, name the outcome, design the cadence to fit, measure what comes out, and prune the roles that don’t justify themselves. None of them is a template to copy. The discipline transfers; the specifics depend on your team.
When this doesn’t apply
Process design overhead exceeds benefit in four cases.
Genuinely small teams (three or fewer) where the “process” is mostly synchronous conversation. Designing roles for three people is over-engineering when the three of them can talk in real time about anything that matters.
Pre-PMF or product-discovery teams, where the activity boundaries themselves are unstable. When the team does not yet know what it should be producing, designing roles around outcomes locks in the wrong shape, and the cost of redesigning weekly outpaces the cost of running ad-hoc. Stay loose until the work has a recognizable rhythm, then design.
Pure-research environments where output is uncertain by definition. Process design assumes a known output to optimize for; research breaks that assumption. The right structure for research is closer to “give people room to wander and meet to share findings.”
Crisis modes. Incidents, deploy days, market events. The ad-hoc response is the right move, and process discipline is the wrong tool until the crisis is over. Resume role discipline after.
The bigger picture
A team designed as a process is one whose members can answer “what role do I fill, what outcome do I own, what flows in and out.” That answer is the difference between rituals running on inertia and rituals serving output. From the outside the rituals look the same; the team’s quarter does not.
The teams that improve over a year tend to be the teams where someone designed the process: pruned the roles that did not justify themselves, gave each surviving role an owner, made the cadence honest. Teams that don’t improve usually didn’t have that work happening.