The Scaling of SAFe Roles and Collective Ownership
There has been an ever-increasing demand for clarity in how the various layers of SAFe interact with each other effectively. And as you may have heard before, a picture is worth a thousand words.
I have started using two frameworks with my clients to help them understand the idea of collective ownership and to simplify the definitions of SAFe work items. They’ve been consistently useful, so I want to share them here.
SAFe Simplified
The first is a table. The advice I give my clients when using it: associate any item in a row with all the other items in that row. When you think of one, think of them all. It gets a little more complicated when you introduce Solution Epics and Program Epics, but this works well for the basics.
| The Work | Where | Who Owns It | Who Builds It | How Long |
|---|---|---|---|---|
| Epics | Portfolio | Epic Owner | Many ARTs or Value Streams | 2+ PIs |
| Capabilities | Large Solution | Solution Manager | 1 Solution Train (1 Value Stream) | 1 PI |
| Features | Program | Product Manager | 1 ART (Agile Release Train) | 1 PI |
| User Stories | Team | Product Owner | 1 Team | 1 Sprint |
Read this table and a pattern emerges immediately. Each layer of SAFe has a corresponding work item, a home, an owner, a builder, and a timeframe. When those six things are aligned, the layer works. When any one of them is missing or misassigned, you typically find the confusion that brings me into an engagement.
The Collective Ownership Target
The second framework is where the real clarity lives. Clients have universally said it has made things clearer for them than anything else.
Picture a target, four concentric circles representing the four layers of SAFe, from the innermost Team layer out to the Portfolio layer. At each layer, there is a trio of roles that collectively own the success of that layer. The Scrum Master, Product Owner, and team at the center. The Release Train Engineer, Product Manager, and System Architect at the ART layer. The Solution Train Engineer, Solution Manager, and Solution Architect at the Large Solution layer. Portfolio Management, Epic Owners, and the Enterprise Architect at the outermost ring.
The target also has three wedges cutting across all the circles, representing the functional areas of responsibility that span every layer:
- How? Technical Excellence and Authority, carried by the architect and engineering roles at each level.
- Who? When? Process Improvement and Execution Authority, carried by the Scrum Master, RTE, and STE roles.
- What? Why? Strategy, Vision, and Content Authority, carried by the Product Owner, Product Manager, Solution Manager, and Epic Owner roles.
Each role sits at the intersection of a layer and a wedge. When you understand both dimensions of a role, the layer it operates at and the type of authority it holds, the picture of what that person is actually responsible for becomes much sharper.
The reason this matters: most SAFe role confusion I encounter is not about the definition of the role. It’s about which layer a person is operating at, and whether the authority they’re exercising matches the layer they’re in. A Product Owner trying to exercise content authority at the program level is creating confusion. A Product Manager trying to do execution management at the team level is creating friction. The target makes it visible.
I hope these frameworks are as useful to you as they have been to my clients. What do you think?