From structure to culture

In our previous blog post, Component teams break Flow, we showed how a structure based on component teams leads to siloed disciplines and sub-optimal flow.

In this blog post we’d like to expand the discussion by adding on the impact this structure has on the organisational culture.

Silos and business objectives

Since our component teams work on parts of features, asynchronously, our delivery is not going to be as predictable as we’d like, and consequently we’re weak against cost of delay too.

This makes the Product Manager’s life particularly hard. And without appreciating that the problem is inherently linked to our structure, the Product Managers might conclude that Developers don’t care about customers and “have it easy”, while Product Owners are wasted in the minutiae of tactical work.

What senior managers worry about, ultimately, is that if we don’t get faster at delivering our competitors will catch-up with us. If we phrase the issue in terms of “speed of delivery” and “customer focus”, our senior managers will conclude that the solution is to promote a culture of customer centricity in all areas of the business and increase the speed of delivery.

In our example organisation, we had three delivery teams — Search, Purchase and Tracking — and three customer segments — Books, Consumer electronics and Personalised T-shirts. What happens when (for example) a Technical Lead tells a Developer in Search that her performance (and bonus) will be linked to the profits in one or more customer segments?

As far as a Developer in Search is concerned, there is one Search functionality and it serves all customers: what happens if we do very well in one customer segment and not so well in another? How will we quantify the impact that Search has had on these results? It works in the other direction too: we might have unprecedented success with one or more customer segments and that might have nothing to do with the Search functionality itself.

Then how do we drive and manage performance?

What’s important to highlight is that in the current set-up a Developer might feel that she doesn’t have much influence on the overall strategy and business objectives and so it’s unfair to measure her against these. She would rather be measured on how good the Search code is. Just like a Designer would rather be measured on how good the customer journey UX is.

And what about the objectives for the Product Owners? The focus of their work is to get stuff over the line with the delivery teams: they don’t really get to choose what gets done and why — that responsibility is given to the Product Managers. So the objectives for the Product Owners are going to smell like Delivery Management objectives. Have you ever been in a conversation with a Product Owner saying that the business goal is to deliver feature X ?

Product Managers: the isolated heroes

The Product Managers are going to have their objectives aligned to the success of the revenue lines. However they are going to feel that they don’t get enough support from the wider organisation: Engineering doesn’t deliver, and Marketing and Sales are asking the Product Managers for delivery dates, for roadmap updates and for new features.

At some point these Product Managers will fail some of their objectives and they’ll get frustrated and leave because no-one likes to play to lose. The irony is that if we measure Product Managers on outcomes and Developers (and Product Owners) on outputs then the Developers will get a pat on the shoulder for delivering a feature on time, even when that feature is not paying for itself and customers aren’t adopting it.

“Then we should make achieving the business outcomes everybody’s objective” — I hear you say. But doing that isn’t as simple as it sounds in a system in which Developers, Designers, Product Owners etc. pick up work from backlogs that speak the language of outputs (components), not the language of business outcomes.

How can we promote a culture of customer centricity when in fact only the Product Manager role is positioned to be customer-centric?

Agile Coaching to the rescue?

At this point senior leaders might decide that the organisation needs help and hire an Agile Coach with a mission to help the organisation become better at delivering, better at collaborating, better at focusing on customer value.

A good Agile Coach will know that experimentation, collaboration and psychological safety are essential ingredients of a change journey.

Question: how much appetite does the organisation have for experimentation right now? Remember: Product and Engineering are under the spotlight and in a cold war against each other therefore psychological safety isn’t there and must be rebuilt.

Second issue for the Coach: the engagement has most likely been articulated around speed of delivery with focus on Product and Engineering. But the Coach knows that the ultimate goal is end-to-end flow and business agility therefore all the other business functions must be included in this change journey. Coaching Product and Engineering alone means building an “agile bubble” which is isolated from the business side of the organisation and will burst sooner or later.

How likely are the other business functions to engage? If the Coach’s sponsor is in either Product or Engineering, getting engagement from other business functions will not be straightforward: after all they haven’t asked for a Coach, they don’t think they need one and “if the problem is in Product and Engineering then the Coach should focus on helping those folks”.

Structure drives culture

Let’s remind ourselves: how did we get here? We got here by setting up a structure where delivery teams are component teams: we have allocated teams to sub-systems of our platform and created an organisation where the work (i.e. the value) is organised around the people (i.e. the team structure).

This has led to siloed teams, poor collaboration and mispositioned Product roles. As we have discussed getting help from an Agile Coach at this point might not help unless the Agile Coach does a good job of opening our eyes on the structural issues which are causing everything else.

To find the new structure, we should first identify what valuable work needs to be done and then organise our teams in a way that guarantees the best flow and fastest feedback in delivering that work.

Luckily, the solution is disarmingly simple, though it requires some bold choices around what professional profiles we hire for our organisation and how we grow and maintain the right culture. We will discuss this in a follow-up blog post, The road to customer centricity, which concludes this mini-series. As always, thank you for making it this far and let us know what you think!