Business outcome alignment

One of the largest challenges preventing organisations from competing effectively in the market is their structure. When you are optimised for technology or role, then you are not optimised for customer value. But how do you actually get there? What does good look like for your organisation if you went back to the drawing board? I’m going to share a process I’ve developed for redesigning a system for outcome alignment.

Note that this is not going to be a full article on digital transformation or strategic redesign. I am simply going to focus on the guiding principles and a specific approach to assist in exploring an outcome aligned design.

7 Outcome alignment principles

Principles are always a more flexible method of explaining and using a paradigm. Where frameworks lock you into a defined process, principles allow for evolution. Here are the top items that we’ll use to guide our journey.

1. Minimise dependencies

You may have noticed, but I consider dependencies to be one of the biggest issues facing any organisation today. Any design we end up with must seek to eliminate, and not just manage, dependencies.

2. Align to value, not to technology or role

We exist to service customers, not to be great at Python or testing. Our team design should reflect this.

3. Think about size

‘Two-Pizza Teams’ are what’s fashionable, but we’ve known that 5-9 is about right for teams since the 50s.

4. Design for flexibility and resilience

When we are dependent on an individual or team, we have introduced fragility to the system. The final design should allow for resilience through flexibility.

5. Make it scalable

If it doesn’t scale to meet our future needs then we’re on the wrong track. If we need to re-org every time we grow then we don’t have the right solution. The design should grow as we do.

6. Have a clearly defined purpose

According to Dan Pink, one of the most important ways to build intrinsic motivation is to provide an environment where there is a clear and inspirational purpose. Knowing that you help improve your customer’s lives through your product is powerful.

7. Be guided by metrics

Define how you’ll measure that you’re moving the right way up front. Get it baselined and then use those numbers to let you know that you’re on the right path.

The hypothetical start state

I’m going to use an example to walk you through this process. It will be simplified but will enable us to see how it works.

Assume an IT organisation of 5 teams. The organisation started with their Head of IT proposing a functional alignment. This resulted in 5 teams, one for each function of business analysis, development, test, infrastructure and ops, and a project management group. Each of these functions is lead by a technical manager who also owns line management.

There are business people in another area outside IT that make demands on the teams. They have a different reporting structure. The business SMEs take requests from customers and funnel them into IT through the projects team. Project managers then chop that work up, pass the pieces to each function in exchange for a completion estimate. They then build a GANTT chart and centrally control the work across the functions. When all of the work is complete, they reassemble the pieces and pass it back to the SMEs.

If you’re read any of my previous articles, hopefully you can see the issues here.

1. This is optimised for function and not customer value
2. There are significant dependencies as work is handed between functions
3. Centralised management aims to maximise utilisation, dramatically increasing lead times
4. It isn’t scalable as it promotes going tall on the hierarchy, which makes the cost of growing the organisation continually more expensive (No article on this yet)

Redesigning for outcome alignment

1. Break it down

We’re going to redesign this situation to follow our principles. It’s going to be bold and dramatic. But we are not going to do it all at once. Don’t read this next section as tacit permission to go and enact complete change, because you will fail. Seriously.

First things first, let’s take stock. We’ll disassemble everything and start fresh, so we have:

• 3 x SMEs
• 4 x Ops
• 5 x QA
• 5 x Dev
• 3 x BA
• 3 x PMO

Our PMO people will create an enabling team in the form of a Lean PMO. This is because in a decentralised system, we do not need a dedicated management function for each team. That leaves us with 20 people, so we know we’re aiming for roughly 3 or 4 teams aligned to customer value when we’re done. Thinking on our feet, 4 might be tricky as we might not be able to supply enough expertise across all functions in the beginning. As we go, we’ll continue to build cross-functionality so it’ll be less of a problem. This is where we have functions within a team becoming proficient in all roles to reduce fragility. They won’t be experts but should have enough to get by if we need to.

The entire IT organisation will have a vision that has been subdivided from the organisational vision. This will be the vertical slice that IT is aiming to complete. For the next step, this will be our outcome.

For now, we have a team of the entire IT organisation, and we’re going to ask one question.

2. The principal question

Can a team of 7 +/- 2 fully execute on this outcome?

We’re asking if a team of 7 +/-2 can deliver on the complete IT vision. If it can, then we either have too many people in this IT organisation or the vision isn’t challenging enough.

Assuming that we answer no, then we need to look for seams. A seam is a connective line that will allow us to divide the outcome into 2 or more sub-outcomes.

3. Split on a seam

Some common seams that align us for customer value are:

• Geography
• Customer segment
• Product or product line

Poor seams that promote silos and local optima are:

• Function
• Role
• Technology

TVIN

When sub-dividing outcomes, it’s important to make sure that the pieces are compliant with TVIN. They should be:

Testable – Do we clearly understand how to test if this outcome has been achieved?

Valuable – Is there obvious value in completing only this outcome?

Independent – Are we able to fully execute on this outcome without requiring effort from others or completion of work outside this outcome?

Negotiable – Can we negotiate on the scope of this outcome in order to maximise value?

4. Continue the cascade

Continue asking the principal question and breaking down by seams until you have atomised the IT vision. You should now have a hierarchy of outcomes that represent good outcome team candidates. There’s a final check to apply here, and that’s whether these outcomes now make sense as a nucleus for product teams. I did quite a bit of research looking for a great definition of a product team, but couldn’t find one that really resonated with me. So until I can get around to writing one of my own, here’s one that isn’t too bad.

For larger contexts, you may find that it makes more sense to group some of the outcomes together in order to promote common alignment to an overarching outcome. It’s perfectly acceptable to have outcome hierarchies, but we should strive for a hierarchy that is as flat as possible in order to promote autonomy and reduce decision latency.

5. Team design

Outcome owner

Before anything else, we need an outcome owner. In traditional Agile, these might be called a product owner. Personally, I don’t mind what role they currently have. This person will have ultimate delegated authority for this outcome. There is excellent guidance on choosing a good owner in Agile IT Organization Design. Here’s a guide to product ownership.

Team

We now come to capabilities. On one hand of the equation is a list of outcomes. On the other, we have people with valuable skills that help us execute on those outcomes. At this stage, we want to bring them together. The goal is to arrive at a design where we have appropriately allocated everyone to relevant teams where their skills can be used in service of an outcome.

I would strongly suggest getting physical with this. Print out cards with both the outcomes and people you have available. Get a load of people in a room together and get discussing what this system would like if it was really performing. Especially the outcome owners.

It’s easy to lose sight of the fact that we’re moving actual people here. Although we are designing a new system, remember that that we’re not going to just go out and do everything all at once. If you’re going to involve people in this who are presented by those cards, then make sure to lay the ground appropriately beforehand. This is a design for a north star that we’d like to evolve towards. Make sure people understand why we’re doing it and what everyone can expect from the journey.

We have the 3 outcomes divided by seam and the Lean PMO being comprised of the project managers. We decided to leave a BA with outcome 3 as they had a slightly more complex starting environment and the BA would be able to help out. The remaining BAs expressed interest in becoming coaches so they’ve joined the Lean PMO.

7. Establish functional bands

Those eagle eyed amonst you will notice that we have some missing people in the above chart. Where are all of the functional leads?

Now that we’ve rotated the organisational lens 90 degrees to focus on value, we’ve lost a guiding hand on the technology or function rudder. To compensate for this and bring back the healthy tension between value and excellence, we need to create a secondary alignment. We do this by establishing chapters, communities of practice or a centre of excellence. I don’t care what term is used as long as we end up with a secondary functional alignment.

These entities are lead by the previous function leads, who will promote technical excellence across all outcomes. They are not line managers. There is little point going through all of this work to focus our alignment on customer value only to flip back to functional alignment at the final hurdle.

I’ve chosen to include the outcome 3 BA in a CoP with the Lean PMO but didn’t wan’t to lose the clarity over the horizontal functions.

6. Guiding metrics

Your metrics will be your own here, and I would encourage you to let the outcome owner define what’s going to be right for their outcome. But there may be some higher-order items that are critical to the vision being successful. We need to define two sets of metrics. Those that will be markers for success in our transformation. And those that will be defined and owned by each outcome.

That being said, that’s not particularly helpful so here are some ideas to get you started:

1. Lead time – How long does it take a customer to get the value after they request it
2. Flow efficiency – How much calendar time in that lead time is spent doing value-added work versus waiting or non-value work such as meetings
3. Failure demand – How much processing time is spent on value-adding work versus fixing things that have gone wrong

7. Checking our outcome alignment

We’ve been at this for a while now. We think we’ve got it but still need to check. We’ve applied TVIN and a product team checklist, all looks good. Let’s take a final look using our principles.

• Minimise dependencies – We’re aligned both in purpose and hierarchy to outcomes, so all good here
• Align to value, not to technology or role – Outcomes not function, check
• Think about size – No team greater than 9
• Design for flexibility and resilience – Promoting cross-functionality within the teams means we can start to dissolve the fragility that we once had
• Make it scalable – We could theoretically scale this to infinity by dividing outcomes along valuable seams (When would your current model start to struggle?)
• Have a clearly defined purpose – Every single team has a clear purpose aligned to a customer outcome
• Be guided by metrics – We’ve got a list of global metrics for the transformation as well as each team owning their own

I’d say we’ve been successful.

Getting started with outcome alignment

As I’ve said throughout this, don’t immediately go out and try to do this all at once. If you do, then you will experience transformation failure. When you undergo change, you experience a dip in performance while the system adapts and accelerates. If you bite off too much change, then you cannot recover from the asteroid crater you’ve just punched in your business.

Look to identify a good candidate team to start with, ideally using dependency mapping. Help them to establish good Agile and Lean practices until they can run on their own. When they encounter tension with the rest of the business, look for where that tension is to start including another area. If another team seems excited to be involved, then start to include them. Above all else, start small and prove the value before moving on.

Conclusion

Designing a team is hard, designing a team of teams is even harder. This is always going to be complex. By working through it piece by piece and being led by high-quality metrics and principles, you can improve your chances of a successful outcome alignment.

As part of my role with DevOpsGroup, I design and run workshops to help organisations move through this process.

This turned out to be wildly different and far more involved than I had originally planned, and I had to leave plenty of subjects to the side. It takes a good amount of time to plan and write these. If this has helped you, then please feel free to share in your own communities. Thanks for reading.