The questions that deserve a real answer.

AI tools can accelerate parts of the work, but they do not grant decision rights or change funding and release controls. You will speed up development and overwhelm every other upstream and downstream process.

Many organizations claim they have empowered teams. But can a team kill a feature? Can they change the requirements while they are building? Are they releasing and getting real customer feedback and not just internal demos? If the honest answers are no, don't worry, you're not alone. Most companies actually follow a Water-Scrum-Fall approach today. The challenge is that it doesn't work great today and will work even worse as AI accelerates development.

There are early adopters in every organization so start with the willing. Choose a medium-stakes value stream, rather than the whole department. Enabling Teams close the skill gaps as the work exposes them. There is a catch-22 worth naming here: teams cannot show they can be trusted with decisions until they have been given some.

SAFe plans around dependencies between teams. ZeroBlockers works to remove the ones that keep coming back. The difference matters a lot for what leaders need to do. In ZeroBlockers teams need independent ownership, decision authority and self-service capabilities, whereas in SAFe these challenges are managed with a standing coordination layer (the full SAFe comparison). And unlike the Spotify model, ZeroBlockers specifies the team composition, leadership relationship and connected implementation steps. Finally, in Cagan’s product-team model, the Product Manager is in the delivery team whereas in ZeroBlockers they sit on the Product Team, setting direction across Stream Teams. The roles are remarkably similar even though the place they sit is different.

It is really hard to do this, otherwise everyone would already be doing it. Examine what the previous effort changed. Did funding still require a fixed feature list? Did finished work wait for external approval? Could customer evidence change the plan? These implementations are commonly called Water-Scrum-Fall. It looks like the teams are empowered but they really aren't and therefore the benefits are not achieved. Start with a bounded pilot and change the conditions around it, rather than repeating ceremonies and expecting a different result.

There are two ways of ensuring quality: checking at the end or continuously checking. But checking at the end is much slower and more expensive. Build quality into the work through peer review, automated tests, small changes, monitoring and rollback. Risk-based release guardrails distinguish routine changes from those requiring specialist judgment. And it works in practice, Hunter Industries reported an 18-month period with no new bug reports while practicing mob programming and continuous improvement. Read Chris Lucian’s account.

Teaming is the default way of working in ZeroBlockers. The whole Stream Team works on the same item across research, design, and development with very low work in progress. So developers sit in on customer interviews, and designers are there while a developer prompts the agents. Specialists contribute their craft while everyone shares the context, decisions and feedback. Working together means higher quality decisions made much faster.

Individual utilization is not the same as team effectiveness. ZeroBlockers uses teaming by default because it lets teams finish one item together rather than maximize how many items are started separately. Shared context reduces handovers, exposes assumptions and brings review into the work. Once you factor in the rework normally required with separate working, teaming works out as the same amount of effort (assuming the team size is less than five). And it has the added benefit that the team learns and raises the quality bar continuously.

No. Specialists still bring their own craft, so a developer might sit in on customer interviews without running them, and a designer can follow the build without writing the code. What the whole team shares is the problem and the decisions. That keeps the context in the team and leads to better decisions, because ownership isn't passed from one function to the next.

Some duplication is likely, and a little of it is often a fair price for teams that don't have to wait on each other. Give each Stream Team a clear customer journey to own and be explicit about which capabilities are shared. When several teams keep needing the same thing, and the waiting costs more than building it once would, that's the time to turn it into an Internal Product Team with its own roadmap. It's best to avoid building a platform up front just to remove every trace of duplication, because centralizing functionality can lead to bottlenecks and reduced agility.

There is an up-front cost, and it can be significant. In Working Backwards, Colin Bryar and Bill Carr describe Amazon teams spending up to nine months removing dependencies before they delivered new features. With AI it would be a lot quicker today. The alternative is paying for coordination every time something changes. You don't have to do it all at once, though. Agree the scope and the investment up front, and then check whether waiting and rework are falling before you go further.

You'll still collaborate, but the conversations will be about different things. With stable interfaces, teams can use each other's capabilities without lining up every release. So they talk about the API structure and functionality because someone still needs to own those interfaces, check compatibility and talk through changes as needs evolve. If you find the same teams having to change their code together again and again, that's usually a sign the boundary is in the wrong place, or that the shared piece needs a product owner of its own.

Plenty of established code bases are tangled, so you're in good company, and you don't need to untangle everything before you start. Pick one customer journey and look at which changes currently need coordinated edits, shared environments or joint releases. Domain mapping helps you find a boundary that is realistic, and from there you can improve the interfaces, tests and deployment a step at a time. It also helps to know that sharing a repository doesn't stop a team from owning its part of it. Agree how much you're willing to invest, and check that waiting is going down before you extend the approach.

No. Capabilities that many teams reuse can be offered by Internal Product Teams, and Enabling Teams can build skills across several teams at once. The useful question to ask about any connection between teams is whether it helps a team act, or whether it keeps making the team wait.

Stream Teams don't work unsupervised. They report to Product Teams, and before they build something they share what they intend to build, the opportunity they think it addresses and what they learned from testing prototypes. We can trust teams to build the right thing, and we still have a responsibility to check that they are. That conversation is where the check happens.

You're right that most business metrics are too far removed from what a single Stream Team can influence. Revenue moves for many different parallel and competing reasons to hold one team accountable for it. That's why Product Teams act as a translation layer between the business metrics leadership cares about and the product metrics a Stream Team can move. Once a team is autonomous, it's reasonable to hold it accountable for those product metrics, because it controls the decisions that affect them.

Auditors need evidence that changes are controlled, and an approval committee is one way to provide it. Traffic-light release governance is another. Instead of approving individual changes, you pre-approve patterns. Each class of change has published checks, anything that matches the pattern ships with those checks built in, and changes that need real judgment still escalate. Compliance tests run on every change, so the audit trail builds up in the pipeline as the work happens. DORA's research supports this. It found no evidence that formal external review is associated with lower change fail rates, and it recommends peer review captured in the development platform as a way to meet segregation of duties. Read DORA’s research on change approval.

No. Leaders keep responsibility for direction, scope, funding and the agreed boundaries, and regular reviews make the results visible to them. Two things change. The evidence leaders use to govern moves from plans and status reports toward results, and teams can make more decisions without escalating.

A team that owns a customer journey rarely runs short of useful work, because there is usually a next problem worth solving. What persistent funding does is make capacity and operating cost visible in one place. Leaders still decide which customer journeys deserve investment, and they review cost, outcome trends and health measures to check that decision over time. If results stall, look at the problem, the team's capability and its scope before you change the allocation. A failed idea is a normal part of learning, so it shouldn't be a reason to disband the team. Equally, a stable team can still have its funding reduced when the evidence points that way.

You don't need to. There's no requirement for a one-to-one mapping between the Value Streams you identify and your Stream Teams, and one Stream Team can own several Value Streams. Your product strategy decides how many Stream Teams you need and how big they are, so you can start small and add teams where the investment makes sense.

You can still capitalize software spend with persistent teams. They keep records that separate the activities and costs your accounting policy cares about, and funding a value stream doesn't change which software costs can be capitalized. The best route is to agree the treatment and the supporting evidence with your finance team and auditors under the accounting framework you already use. It's also worth avoiding a fixed capitalization percentage based on a team's role or budget, because the right figure depends on the work the team does. The operating model gives teams more freedom over the solutions they choose, with clear accountability for the investment, and your accounting requirements stay the same.

No. Persistent means the team stays together when a piece of work finishes, so you keep the knowledge it has built up. Its scope and investment are still reviewed regularly, and leaders can change the allocation, or close the team, when the strategic need or the evidence changes.

It can feel that way at first, and in practice the role moves up. Product managers join the Product Team, the group that sets vision, strategy and objectives across several Stream Teams. Day to day, the job shifts from briefing a team on a plan to certifying the reasoning behind the team's own plan, which is harder and more senior work. Not every PM will want to make that move, particularly those who enjoyed running the backlog, so it's worth investing in the ones who do.

A lot of the coordination is handled by how the teams are set up. Each Stream Team owns its own value stream, and the boundaries are drawn so teams overlap as little as possible, which means much of their work doesn't need coordinating in the first place. The Product Team then sets the product vision, the strategy and the objectives each Stream Team works toward. Just as importantly, it shares the reasoning behind them, so teams can find their own route to the goal while pulling in the same direction. Some work will still span several streams, and when it does you can run a project. Either update the objectives of the teams involved so each can deliver its part, or, if the problem isn't well understood yet, combine the teams for the duration of the work. If the same shared need keeps coming up, that's usually a sign it should become an Internal Product Team with its own roadmap. The rest of the work can then go ahead without a standing coordination layer.

You remain accountable for the product’s results and for giving teams the direction, capabilities, and decision boundaries they need. Teams take responsibility for decisions within those boundaries. Agree the outcomes and guardrails up front, share the strategic reasoning, and certify the team’s reasoning so you know it can make sound decisions without seeking approval for every change. Review the evidence together. If results stall, investigate the cause with the team; if a guardrail is breached or a decision exceeds its authority, intervene. Keeping every decision yourself leaves the team responsible for results it cannot influence.

That's common, and building that capability is the place to start. It's often the work that coordination and admin were crowding out of your week. Enabling Teams, capability standards and apprenticeship all help close the gap. Start the team on a bounded scope it can already handle, and widen it as its decisions prove sound.

In our experience it tends to go the other way. A lot of the delay in a decision comes from escalation: waiting for the meeting, preparing the briefing, chasing the follow-up. A team that already has the context can usually decide there and then. Consistency comes from sharing the same strategy, the same operating principles and the same capability standards, and from reviews that look at whether the outcome moved. Some decisions do need a single owner, and when that's the case, name the owner and explain why.

That's a common position to be in, so start where you control the conditions. A pilot on one value stream with one team only needs your decisions to change, so you don't have to wait for the whole organization. Improvements in lead time and outcomes from that pilot tend to persuade peers more than a presentation would. In the meantime, expect to do some translating at the boundary, because the people around you will still ask for status updates in the old format.

Much of the admin and coordination work goes away, which leaves more time for the parts of the job that most need your experience: developing people, raising the standard of the craft and bringing your functional perspective into product strategy. Depending on where you can have the most impact, the role moves into the Product Team or an Enabling Team. The functional manager role explains how the four parts of the job are split.

It should mean fewer meetings overall, because the aim is to cut down on repeated clarification and approval. Share context that teams can reuse, check that they can reason with it, and give them a way to feed back. If a meeting isn't improving those decisions, it's fair to ask whether you need it.

It helps you make better use of them. Enabling Teams are small, senior teams whose job is to raise everyone else's skills, so your strongest specialists work across many teams instead of being spread one per squad. They own the standards and the knowledge base, which lifts the baseline for everyone. A principal engineer who helps forty people improve will usually have a bigger impact than one embedded in a single team.

There is, and it runs alongside the management path. ZeroBlockers has two career tracks. Capability standards describe what each level looks like for each craft, so people can be promoted for the depth of their expertise without having to take on direct reports. The Staff and Principal roles sit on Enabling Teams, where senior specialists can focus on their craft and help raise the standard across the organization.

They deliver through other teams, so their value shows up in how those teams perform. One or two people setting capability standards, spending time with teams each week and writing playbooks can raise the level of ten or more Stream Teams. The alternative is to embed the same seniority in every team, where each person lifts one team and the same questions get answered ten times over. To keep the cost in check, Enabling Teams facilitate and don't take on delivery work, so they don't turn into another queue. Their knowledge base is written for self-service too, so they don't become a help desk. If you notice an Enabling Team doing delivery work, it usually means the change has stalled.

It's usually better to wait. If you build a broad platform before teams have run into their real constraints, there's a risk of creating capabilities that don't remove the blockers they face. Start the pilot, see which needs keep coming up, and let the evidence from those first teams guide what becomes shared.