Why micro teams and rotation reshape culture, not just throughput, in modern SRE.
Most SRE leaders design teams around the systems they own. We designed ours around movement.
We introduced micro teams expecting a throughput story: smaller groups, tighter scope, faster work. Some of that arrived. What we had not budgeted for was how much it changed the way people worked with each other.
We are a 34-person group running four enterprise platforms across two continents, and at that size the thing you fight is fragmentation. People settle into corners: a database specialist who has only ever touched one product, a platform engineer who hasn’t talked to the other side of the stack in months. Knowledge turns territorial, and the team becomes a set of people who happen to share a Jira board. Micro teams broke that through proximity, not policy.
What a Micro Team Actually Is
A micro tea›m is a small cell pulled together for a fixed window around one outcome. Not a permanent team, and not quite a project team either. The distinction matters: it owns a mission, gets a quarter, and has real latitude over how.
- Size: one to three engineers, scoped to a single Epic. Past three, coordination starts eating the work you came to do.
- Duration: a quarter. Long enough to ship something real, short enough that habits don’t have time to set.
- Composition: mixed on purpose: a senior, a mid-level engineer, and someone rotating in from another product area.
- Charter: one outcome the cell owns. A direction to move in, not a backlog to burn down.
Put three people in a cell for a quarter and they absorb each other: instincts, shortcuts, the way someone else reasons through a problem you thought you understood. That trust is not in any onboarding document; it comes from sweating through something hard together.
One of our engineers said it better than any survey: “Micro teaming has been great — you get to know your coworkers as well as have extra advice right then and there.” You will not find that on a delivery dashboard, and it tells you more about a team’s health than most things that do.
Why We Keep Rotating People
A team that is clicking develops its own gravity: a rhythm, a shorthand, a set of things people no longer say out loud. The obvious move is to seal it off and let it keep humming. We tried that. It did not hold.
The question I get most from other leaders is why we don’t just leave our strongest teams alone. The honest answer is that the thing which made them strong is the first to rot once they stop being challenged. Sealed off long enough, hard-won practices become habits, then rituals nobody remembers the reason for. The edge dulls, and no one notices until it is gone.
Rotation is how we push back: every quarter the squads re-form around the next set of Epics, so fresh context keeps arriving to poke at a team’s assumptions before they set into blind spots. The engineer who spent a quarter deep in platform work brings infrastructure instinct to the next squad; someone coming off partner work brings a customer’s eye to a team that had been staring inward. A few guardrails, all learned the expensive way:
- Keep a thread of continuity. When a squad re-forms, carry at least one person and the written context across; recompose the team, not its memory.
- Start with volunteers. Practices spread when people trust them and watch them work, not when they are handed down from above. We ran rotation with the teams that wanted it and let the ones who had done it sell the next group.
- Treat the handoff as a real event. A graduation, a written context transfer, a week of overlap. A sloppy handoff costs about six weeks of confusion.
The People Who Carry the Culture
Rotation did something we had not planned for. As people moved between cells, the culture moved with them, and mostly through a handful of specific individuals.
Every team has a couple of people who set the bar simply by how they work. No title, no speeches; everyone else calibrates to them. Antonio Gramsci, writing from a fascist prison, had a name for this kind of person: the organic intellectual, whose authority grows up from inside a community instead of being handed down from above. Put one of them beside a new hire in a micro team and the newcomer picks up more than technique — they pick up the local definition of “good.” Move that person to another cell and the definition travels with them.
So we stopped treating culture as something in the air and started treating it as something we could route. It is not uncommon for the strongest carriers to sit well away from where the org chart puts the influence; we learned to find them and lean on them on purpose. We began weighting promotion partly on how much someone raised the people around them, not only on what they shipped alone. The engineer who quietly lifted three teammates counted for more with us than any lone star.
What the Numbers Showed
Two years in, the numbers have held. Our internal quarterly survey (n=38, self-reported) puts communication satisfaction at 4.3 out of 5 and stress at 3.2 — manageable, not heroic. For contrast, LeadDev’s Engineering Leadership Report 2025 found 79% of engineering leaders and developers reporting some level of burnout, and only 21% counting as “healthy.” Ninety percent of our engineers can now cover more than one product.
The figure I care about most is actually not in the survey. It is the day you notice people have stopped saying “I work on Product X” and started saying “I work on reliability.” That sounds like a slogan. It is the clearest sign I know that a culture has genuinely moved, and micro teams and rotation are what moved it, rather than leaving it a line in a strategy deck.
Autonomy, With Intent
All of this runs on autonomy. Cells choose their own cadences, methods, and tools. But autonomy on its own produces drift, so we anchor it with something close to mission command: we are explicit about the outcome and deliberately vague about the route. The destination is not up for debate. The route almost always is.
Every quarter we make ourselves sit with a few deliberately uncomfortable questions. Does the shape of our teams still fit the business? Are we guarding systems, or freeing up people? Is rotation producing clarity, or just churn? The point is not to relitigate last quarter’s delivery; other meetings do that. It is to ask whether the organization is still built the right way. Some quarters we decide the shape still fits and leave it alone; some quarters it doesn’t and we redraw. Holding the review honestly has mattered more than any verdict it produces.
I have come to think the org chart is the wrong picture for this. A chart is a snapshot; what we run is closer to a small jazz combo that has learned to improvise. The arrangement on paper barely survives a live room, and the parts worth hearing come from how the players listen and adjust in the moment. You cannot put that in a policy document. The most a leader can do is build the conditions for it, keep the structure honest, and otherwise stay out of the way.
from DevOps.com https://ift.tt/4TEimfb
Comments
Post a Comment