What's your org optimising for?

What's your org optimising for?
optimising an org structure - anne-marie charrett
💡
This is a work in progress. The thoughts are a bit rough and not fully formed. I'm sharing because I'm keen to hear other perspectives to help my concepts take shape. Comments welcome. 

I've got a hypothesis around organisational structures. It's half-baked and not ready for release. I talked about this to a couple of people, who politely nodded at my rant. I don't know if the hypothesis has legs. I thought a community exploration could be helpful. And so I threw this question out on Twitter:

Melvin Conway famously said: "Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation's communication structure."

The corollary could be, "have your org structure reflect the system you want to design". Team topologies by Mathew Skeleton and Manuel Pais is built on this hypothesis, though more at teams within a product department. I haven't seen anything or org structures; if you know of content, please let me know!

I've observed different specialities optimise for what's important to them. For example;

  • Engineering tends to optimise for scalability and reliability
  • Product tends to optimise for discovery and business value  
  • Delivery tends to optimise for consistency and alignment
  • Designers tend to optimise for customer and business needs

Given all this, when a company designs its org structure, it first needs to think about what it's optimising for and then build an org structure with that in mind.

In stream-aligned teams, where multiple disciplines work together on vertical slices to deliver an outcome, collaboration and communication are critical to product success. A delivery lead helps us achieve this through developing shared understanding and ways of working that allow time for sufficient absorption of different perspectives. As we are optimising for delivery in stream-aligned teams, it makes sense for a VP of Delivery to oversee the work.

Not all teams require multiple disciplines, though. Enablement teams, for example, tend to have one or two specialities. While collaboration and communication are still critical, developing a shared understanding and mental models is more straightforward, as the perspectives tend to be more aligned. Many of these teams need a deep understanding of one speciality. Think platform teams or a complicated subsystem team. Here, there's a need to optimise scalability and reliability, so it makes sense for a VP of Engineering to oversee the work.  

Here's a sketch

There's so much to explore in this space; I've only started to scratch the surface. Comment and discuss below!