The Shape That Emerges

The new operating model isn’t something you design. It’s something you let emerge.

Teams that have made the shift will start proposing how they want to operate: which ceremonies still serve them, which don’t, how work flows, what the cadence should be. Your job is to recognize what they’re proposing, support what works, and resist standardizing what doesn’t need standardizing yet.

The shape that tends to appear

A few patterns show up across teams:

Smaller, more fluid working groups. Pairs or trios can do work that used to require a full team. Single developers can credibly handle features that took small groups. Teams stay as the unit of accountability; working groups inside them become more fluid.
Cross-platform work by default. “Android developer” or “Backend developer” begins to blur. A developer with agent help can work productively across stacks they don’t natively know. Specialists still maintain patterns and standards, but more people can pick up more kinds of work. Teams that used to stall waiting for a specialist keep moving.
Developers participating in shaping the work. Developers, who now have time and tools to explore quickly, become natural contributors to “what do we build” conversation. The role boundary between “who decides what to build” and “who builds it” softens. This shift is uncomfortable for organizations with rigid functional silos.
Faster, lighter ceremonies. Long planning meetings get replaced by shorter, more frequent ones. Retros look different — less about velocity, more about which experiments worked. Standups change shape because what I’m working on is no longer a one-day question.
A new bottleneck upstream. Workflows that ran smoothly when execution took weeks don’t run smoothly when execution takes days. Planning, design, and decision-making become the rate-limiting steps.

Stalled → If your engineering teams have shifted but the rest of the organization hasn’t, the bottleneck moves to wherever the slowest decision-maker sits. Engineering capacity goes underused, not because engineers stopped working, but because they’re waiting on inputs that used to arrive faster than they could be consumed. Fixing this is a leadership conversation upstream of engineering.

Pace, parallelism, and the limits of intensity

Agentic work changes the relationship between a developer and the code they ship. Parallel sessions are mentally taxing in ways solo coding wasn’t. The developer is steering multiple tracks, holding multiple contexts, switching between them faster than they would have switched tasks before. Sustainable for a while. Not indefinitely.

The same dynamic applies at team scale. A team running flat out for weeks at a time will produce a lot of work and a lot of fatigue. The fatigue won’t show up immediately. It’ll show up as quality drift, missed details in code review, irritability, attrition risk. The pace that feels sustainable in the first sprint may not survive the eighth.

This is where leadership has to actively intervene. The pressure usually flows in one direction: from above, asking for more, capitalizing on the gains. The discipline is to push back against that pressure — sometimes against your own instinct, sometimes against your peers. Slow weeks aren’t a failure of the operating model. They’re part of how it survives.

Culture → Watch what comes out, not what’s active. A team that’s running many sessions but producing thin work has hit the ceiling without realizing it. Encourage your developers to find their own ceiling and stay below it.

Two rhythms we’ve seen work

Two rhythms come up often enough to be worth describing. Not the only options. Other shapes work for other teams. The point is to give you a starting reference, not box you in.

Weekly sprint cadence. Compressed traditional sprint shape. Monday morning chooses what’s going to ship that week — work already scoped, planned, and made agent-ready. Most execution happens Monday through Wednesday. Midweek triage discards what’s slipping. Thursday is heads-down on the committed list. Friday is demos and brief retro. Suits feature-driven, predictable work.

Continuous flow. Less ceremony, more responsiveness. Prioritized backlog; team pulls as capacity opens. Daily standups walk work right-to-left: what’s stuck in review, what can finish today. WIP limits prevent starting more than the team can finish. Weekly replenishment keeps the top of the backlog clear. Biweekly retros focus on flow. Suits reactive or unpredictable work: platform, infrastructure, support-heavy domains.

The choice depends on the actual shape of the work and the makeup of the team. A team forced into the wrong rhythm will struggle against it.

What both rhythms share, and what any rhythm worth adopting will share, is the discipline of finishing before starting. The most consistent failure mode in agentic work is teams who start more than they finish, which is easy to do when starting is cheap. Whichever rhythm you adopt, complete what’s in flight before you begin new work.

Culture → The rhythm is for the team, not the agent. Don’t try to design ceremonies around how agents should work. Design ceremonies around how the team needs to coordinate. The agents will fit into whatever rhythm the team adopts.

What needs to change upstream

Engineering teams can adjust their internal operating model on their own. They can’t fix what’s slowing them down upstream. The teams getting the most out of agentic work tend to have made changes that extend beyond engineering:

Requirements written for agents to consume. Specific, testable, structured around intent rather than solutions. Vague specs used to be a tax on the developer; now they’re a tax on every agent the developer runs.
Designs that match implementation speed. Designers reviewing built artifacts is faster and more accurate than designers producing pixel-perfect mockups in advance. The shift requires designers to be available throughout the build, not just at handoff.
Decisions made faster, at lower confidence. Product decisions that took two weeks pre-agent now bottleneck a team that can build in two days. The fix isn’t reckless, risky decisions. It’s making smaller, faster, more reversible ones and course-correcting based on real output.

None of these are engineering problems. All of them affect engineering’s ability to deliver.

Stalled → If your engineering teams have made the shift but requirements, designs, and decisions are still arriving on the old timeline, you’ll see the same throughput you had before. The teams will be capable of more; the inputs won’t let them deliver it.

Watching for what teams propose

The most useful signal that the new operating model is working is teams proposing changes you didn’t ask for. They want to try a different cadence. They want to restructure how they take in work. They want to drop a ceremony that no longer serves them. The proposals are often small and specific.

When teams start doing this, your job is not to standardize. Let them try. Watch what works. Some proposals will become patterns other teams adopt voluntarily. A small number will become organization-wide practices, but only after they’ve proven themselves in real use.

The temptation, especially for leaders coming from a more controlled tradition, is to take what works for one team and roll it out to all of them. Resist this. The teams that proposed their own way of working own the way of working. Teams that have it imposed on them don’t.

What should be consistent across teams isn’t the model. It’s the principles underneath: finish before you start, steer agents deliberately, watch the cognitive cost, let teams shape their own work.