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

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

During a recent talk at Lean Kanban France, I asked the audience how many of them thought we should align teams with business capabilities. Quite a few hands went up.

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

People often talk about aligning teams to improve flow. Yet, business capabilities are a structural decomposition of an organisation. They don’t tell us about the relationships between capabilities and how work flows through them.

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?

I’m not saying business capabilities are bad, and I’m not saying we shouldn’t try to optimise flow. In fact, I think we should care about business capabilities and we definitely should be trying to optimise 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

Sociotechnical organisation design patterns are patterns for shaping team boundaries, software architecture, and the dependencies between team.

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

Finding team boundaries should be driven by business and product strategy, so it’s important to start with strategic organisation design patterns. Strategic patterns are high-level boundaries that usually encapsulate more than one team.

Customer Segments

When the product strategy is to optimise the value created for specific customer segments (e.g. B2B, B2C, Prime customers), or to provide each customer segment a largely unique experience, the high level organisation design can be aligned with 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

When the product strategy is centred around verticals, the high level design of the organisation can be aligned with those verticals (e.g. finance, healthcare).

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

Regions

Sometimes product strategy is differentiation by region. Different countries or continents demand their own personalised products owned by specific groups of team. Flow will, therefore, be high within a region but lower across regions.

Products

Product strategy may dictate that the company creates a range of independent products. Therefore, the organisation can be designed so that each product has its own dedicated teams maximising the flow of an individual product, but increasing the costs of adding features that are required by multiple products.

Devices / Experiences

Ever used a feature on one device that wasn’t available for the same app on another device? This is because product strategy is often about optimising the experience of each version of an application for the device it runs.

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

If the cost of maintaining products is too high, the strategy will be to reduce costs.

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

After strategic boundaries have been identified there are still many granular design choices to be made. Where you put team boundaries has a huge impact on flow and productivity.

User Journeys & User Journey Steps

You may to decide to align some of your teams with individual user journeys or parts of a journey. Flow will be higher when making changes to just to the UI, but slower when a change involves backend work.

Business Capabilities and Sub-capabilities

After practicing capability mapping, we might see that our business capabilities fit neatly into our strategic organisation design. If they do we can align teams with them, or when they are too big we can break them down into 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

Bounded contexts are a domain modelling. Domain-Driven Design practitioners look for bounded contexts by using language to identify which concepts and phrases are related together in the domain and software, and putting boundaries around them.

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

The goal of autonomous contexts is to maximise flow — to find things which change together in software, group them as a code repository or software system, and ensure they are owned by a single autonomous team

Tactical Sociotechnical Organisation Design Patterns

Effective organisation design is not just about finding boundaries. It also involves understanding and optimising the relationship between teams as well.

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

I hope this post has helped you to realise that business capabilities and flow are useful heuristics but massive over-simplifications of the intricate world of continuous sociotechnical organisation design.

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.