Aligning Teams with Business Capabilities to Improve Flow… Why You Shouldn’t

Nick Tune
Nick Tune
Dec 27, 2017 · 6 min read

You’ve probably heard the advice to align your development teams with business capabilities — cross-functional, autonomous, product-focused teams aligned with business capabilities.

What if this is wrong?

You’ve also probably heard the advice to focus on flow — increase throughput of work by limiting the dependencies between your teams so value is delivered continuously.

What if this is wrong as well?

One of the most difficult issues facing every product organization at scale is just how to split up your product across your many product teams

— Marty Cagan (@cagan)

Nobody Knows What Business Capabilities Are

Then I asked them, who thinks they know what a business capability is and who has tried capability mapping… one hand hesitantly went up and wobbled in the air for a few seconds.

Can you see the problem: How can we align teams with business capabilities when nobody knows what they are? And if nobody knows what they are, what are they aligning their teams with?

Flow is a Tradeoff not Magic

There’s another problem with the way people talk about flow. It’s often described like hidden treasure. We are searching for the magical perfect flow.

Sorry, kids, it doesn’t exist.

Flow is more akin to traffic lights — reducing flow in one direction to improve flow in another. It’s a combinatorial optimisation problem with many trade-offs and no single perfect solution.

Should we Abandon Business Capabilities and Flow?

So what am I trying to say?

I’m trying to say that the way people throw around business capabilities and flow is too naive and ambiguous. Sociotechnical Organisation Design has many variable and many modelling constructs. Business capabilities and flow are an over-simplification.

In this post, I’ll give you a quick introduction into the nuances of designing organisations. I want to encourage you to think more carefully about what’s right for your organisation, and I want to give you useful tools for doing so.

Sociotechnical Organisation Design Patterns

Each sociotechnical organisation design pattern optimises for one or more flow routes at the expense of others.

For example, the Customer Segment Pattern optimises the flow of work so we can make faster end-to-end changes for a specific type of customer. However, the trade-off is that when we want to make a change that affects multiple customers, the trade-off will be slower.

So as a business or department, we identify our business goals— e.g. satisfying priority customers — then use the relevant Sociotechnical Organisation Design Pattern as our starting point.

Note: You can mix and match patterns in an organisation. In fact you should — different parts of the business will have different goals and priorities

Strategic Sociotechnical Organisation Design Patterns

Customer Segments

For each customer segment, there are one or more teams dedicated to providing the best possible experience for that type of customer.

As discussed, flow is relatively high when making changes for one customer segment, but low when a change cuts across them.

Markets / Verticals

Flow will be optimised for changes within a vertical but compromised when work crosses a boundary.

Regions

Products

Devices / Experiences

Flow is optimised for each device, but when a new feature is required by multiple devices it can be slower and more costly to roll out.

Cost Savings

In some scenarios, redesigning the organisation is necessary to reduce costs. For example, when multiple teams each build an operate their own CMS or infrastructure, it can be cost effective to create a new component or platform team(s).

Costs will be lower, but flow will also be reduced due to the shared dependency. Teams must wait for their requests to be processed.

Team Boundaries / Sociotechnical Building Blocks

User Journeys & User Journey Steps

Business Capabilities and Sub-capabilities

When we align teams with capabilities, it’s faster to make changes to the capability. This often means we can make changes to a full slice of the application — from frontend UI to database, without requiring dependencies on another team.

Conversely, when there are changes to the user journey, multiple business capability teams may need to coordinate.

Bounded Contexts

Unlike business capabilities which are a structural view, bounded contexts are more dynamic reflecting structure, relationships, and dependencies in a domain.

By identifying related concepts as bounded contexts, you are more likely to own things that change together, thereby increasing flow within each context. Of course, flow between contexts with then be slower and more costly.

Autonomous Contexts

Tactical Sociotechnical Organisation Design Patterns

Understanding the relationship between teams helps us to design team coordination and identify hard technical boundaries.

There are hundreds of tactical sociotechnical organisation design patterns including the enterprise discovery context, the autonomous bubble, the octopus, and the dog food context. There are patterns to optimise discovery flow, digital transform, and more.

Note: To learn more about these patterns, check out the slides for my recent talk Coevolving Organisational and Technical Boundaries

Choosing the Right Patterns for You

Our goal is to give all organisations the knowledge to design their organisations for their unique needs.

If you’d like to share a pattern, a case study, or an interview, or you’d like to join the team we’d love to hear from you. Please do not hesitate, email me.

Strategy, Architecture, Continuous Delivery, and DDD

Nick Tune’s thoughts and experiences on Strategy, Architecture, and Domain-Driven Design.