top of page

Musings on Digital Org Design

In one of my previous blog articles, Musings on Conway's Law, I started to explore the possible relationship between org structures and the systems that they create. I looked at two interesting studies that tried to dig deeper into the concept to see if there was any hard data to support Conway's claim. From what I can see I think we can say that there are related factors that have been shown to correlate, statistically speaking, but I don't think we have been given a real handle on the underlying causation factors. Suffice it to say that, for now, I believe there is a real link between the two and that understanding the nature of the link is a critical for our collective future.

So, before I go any farther I feel I should put my cards on the table. What I’m really trying to explore here is what I see as one of the biggest challenges to modern organisations - a deep structural challenge.

I am pretty convinced that hierarchical org structures, which have held sway for well over 100 years of the Industrial Age, are no longer fit for purpose in our new software powered world.

As I see it hierarchical org structures have a finite limit when it comes to the speed with which they can dynamically change to meet the needs of those they have been created to serve. And I think that, with the global proliferation of software we have reached that limit. Consumers, citizens, people, call us what you will, as a result of software, now have higher expectations than ever before in terms of their potential quality of life. Whether that be something as trivial as the latest digital gadget for tracking your exercise routine or major services such as health care, education and government in general. We know more is possible and we all want it. Now.

Do we know what's broken and can we fix it?

I believe that it's to do with "coupling structures". The internal coupling structures in traditional hierarchical organisational models are no longer fit for purpose. They just can't respond quickly enough. And that's often despite the fact that we have deployed the latest software solutions to assist these organisations in their attempts to meet the demand of their customers.

A massive pressure is growing that is breaking traditional organisations . And, even more importantly, breaking the people that work in them. Blame for this situation is landing randomly and subjectively. It's "old people", "millennials", "negativity", "outsourcing", "management", "the rich", "unions", "immigration", etc. All the usual suspects - someone who is not us - the "other".

Except that I don't believe it is any of them really. It's a systems issue. One that, if we can fix it, may help us avoid some of the inevitable pain that we are going to face as the system changes, as it must, to meet the needs of society in general.

One thing is for sure. There is no going back.

So, for the past few years I've been studying "org design" and "operating models". I've explored the latest thinking of the more traditional practitioners in the HR world (for example Nicolay Worren's Organisation (Re)Design blog and books , as well as looking at the fascinating world of "new" operating models. Frederick Laloux's excellent book, "Reinventing Organisations", presents an excellent overview of organisations who do things differently. While I have found much of interest I haven't yet found a blueprint for a "Digital Age Operating Model" (a DAOM?) that makes sense to me. So, in this, and a series of related blog posts, I am going to explore concepts, structures and models that I think may be relevant to a "DAOM" blueprint.

So let's go back to Conway's Law

In the search for a DAOM I think Conway's law is a good place to start. The question is, can I use the findings of studies relating Conway's "Law" to provide any data that would give us some ideas of where we need to be.

In my previous article I looked at 2 studies that tried to assess the impact of different org structures on the quality of systems created by them. These were -

The first paper is a really interesting look at the impact of different org designs on the software products created by the organisations in question. What's not covered in any great detail is the actual org structures apart from a general assumptions derived from general principles about private sector and open source organisations.

The second paper is much more interesting from my perspective in that it provides an in-depth assessment of the impact of a set of org and org structure related factors that were statistically significantly correlated to software quality. Also interesting is fact that the study was carried out in an organisation that has arguably taken the hierarchical org structure as far it can go - Microsoft (an argument for another day maybe).

Org Structure Design Factors - A Deep Dive

In this case study the Microsoft team identified 8 org structure parameters which they showed to be a accurate predictors (relatively speaking), of software quality. They were:

  1. Number of Engineers (NOE)

  2. Number of Ex-Engineers (NOEE)

  3. Edit Frequency (EF)

  4. Depth of Master Ownership (DMO)

  5. Percentage of Org contributing to development (PO)

  6. Level of Organisational Code Ownership (OCO)

  7. Overall Organisation Ownership (OOW)

  8. Organisation Intersection Factor (OIF)

In the Microsoft paper they use the individual code module (AKA a single .dll file), as the core scope and context. I think this is critical.

In this context the key measure was the number of bugs, post release, that were recorded against each code module (DLL file).

We know very little else about the function of that module (does that matter?).

But a software code module, in a system as complex as Windows Vista has to be an interesting organisational product, particularly in the context of what I am trying to understand.

I will try and dig into this topic in more detail in the my post on this topic.

Featured Posts
Recent Posts
Search By Tags
No tags yet.
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square
bottom of page