How does work REALLY get done?

In this article, I’m going to explore some things that can happen when typical (20th century, bureaucratic) structures in organisations meet complexity, and offer some hints to embrace what’s likely already to be emerging beneath.

Here’s a question. How does work get done in your team? I imagine that the first answer to that question could be quite a simple one, like “We follow a process” or “A Customer calls because they’re in pain, we help them and then close an associated ticket”.

But let’s delve a little deeper. Does that account for the work that really gets done? And if not, have you got a good sense of what that flow of work might be? In my experience, the reality is muddy and the more complex the environment, the deeper the mud.  Within the process or organisation design, there are myriad (micro) interactions between each stage and together they mount up to inefficiency, confusion and ultimately poor stakeholder experience.

I’m going to stick with a customer services example to investigate this, though this is applicable to any other process. Let’s start with a headline process:

Here, a request comes in, and resolution is attempted. Depending on the outcome, the case is closed or escalated to a first (and second) escalation team before it can be closed. A standard 1st, 2nd and 3rd line pattern for support.

I’ve intentionally drawn this process ‘upwards’ as this helps to visually demonstrate the increasing cost as escalations happen (a higher cost of people in later teams, directly and through opportunity-cost).

If we plot this interaction across a typical org chart, we’re likely to see something like this:

The Customer request is received into 1st Line, they escalate to 2nd Line and then the Server team before the case is passed back to the 1st Line team to close.

But we know that requests or incidents aren’t always standard, and the more technically advanced a platform, the more unusual or niche the calls might be. There’s a big difference between “please give me access to…” and something more like “Why does my code run slowly on your platform but not others?”.

Here’s how one of those might play out:

Customer calls, normal escalation to 2nd line and then Networks. Networks think it’s a Dev issue, Developers don’t quite understand (or don’t have enough data) so do what they can anyway. The Customer isn’t happy and escalates to CEO, who puts pressure on the CTO who speaks to the Development manager. The Development manager implicates the Server Manager who can’t act because there’s not enough money, so the CTO gets involved again and approves some more budget through the CEO before going back to the Server team to upgrade whatever it was and finally the Customer gets a result. Phew! And they can be much, much worse than that.

Here are two common reasons that cause this:

1.      We (don’t) put the Customer at the heart of everything we do.

That phrase should mean something, but I’m afraid experientially it doesn’t always mean what we think. The Service Desk team likely do exist to service ‘the Customer’ and are very much interested in welfare, satisfaction and responsiveness. What about the other teams?

Let’s use a simple flow where we need a Service Desk Team, Server Team and Development Team involved to fix an issue, like this:

However, in many cases, the targets and motivations of the escalation teams are set differently. The server team could be measured on platform availability and the development team on valuable feature releases. Inevitably, this can break flow between the teams: The server team can ill afford to be distracted from their task, and nor can the development team. So, going back to our org chart earlier, teams in this situation rely on cajoling or escalation to get work prioritised.

When people say: “We put the Customer at the heart of everything we do”, we shouldn’t expect a silo-led answer that: “We love you so much, we’ve created a dedicated team that fights for you!”

2.      We design systems simplistically and optimistically

A tendency to simplify complexity and be optimistic about our capabilities (and luck) are common human biases. These help us to make sense of the world, but often lead to processes and hierarchies being created in a reductionist way: if all the individual steps of the process are great, the outcome must be great.  That’s true if we’re making a cake – great ingredients + great (measurable, repeatable) process = great cake every time.   But regretfully in complex systems, where chaos and chance impact results, we can fall short. The best inputs still fail.

Further, we can assume that off-the-peg processes will cope with our context. There’s a good deal to be said for best practices, but much like reaching for a Biro when you write or a Hoover when you clean, they’re not the only answers out there.

From my work in cloud computing, with new technologies (or existing technologies being used in new ways) it is very common to find ‘bugs’ that weren’t ever tested for by the vendor. These might be memory and capacity limits, ‘hidden’ counters or other undocumented ramifications at scale. When one of these issues occurs, no individual, vendor or team can find the answer alone, and a process or organisation design that defaults to silos and clean ownership/handover (not collaboration) rapidly breaks down.

The emergence of networks

In the circumstances where these silo practices remain, people often begin to (and sometimes literally!) create their own paths. People directly involved in ‘doing’ see local inefficiencies and faults in processes, and when able to do so, take shortcuts, or leverage relationships so that they can get a job done. If you’re a service desk engineer receiving another call from an unhappy customer, you will want to help them however you can. That’s got to be better than apologising or delaying again for another team who haven’t even opened the ticket yet.

Flickr / Funfilledgeorgie

Returning to the ‘spider’ of escalations earlier, over time we will begin to see emergent and unofficial practices cropping up.  For example, someone in 2nd line has ‘seen this before’, happens to have a good relationship with an engineer in the server team and IMs them or asks them to help during lunch (in green below).

None of the escalation, none of the drama and the Customer gets a solution; the engineer in 2nd line has used their networks to find an answer. But there’s no knowledge or recognition either, and that means no opportunity to learn, capitalise on or repeat the solution. Ironically, there could be poor consequences for the individual who didn’t follow process when their ability to develop relationships and find a solution really is gold dust.

Accepting that learning from the solutions our teams identify is a good thing, the Travelling Salesman problem could be a good place to start thinking differently.

If you’re not familiar, the Travelling Salesman problem (or Shortest Path Problem) is an optimisation problem: “Given a list of cities and the distances between each pair of cities, what is the shortest possible route that visits each city and returns to the origin city?” (Wikipedia)

Computationally, this is difficult problem to solve and solutions to the puzzle have applications in many areas from city planning, through logistics to chip design and astronomy. (Search for Travelling Sales Problem to learn more about this. NB it gets mathematically complex!).

As complex and testing as this is, nature already has mechanisms to solve the problem. Swarm intelligence in ants and bees for example, or the fractal nature of systems like synapses and blood vessels within our own bodies. In the case of our 60,000-mile-long circulatory system, which accounts for less than 5% of our body mass, the design efficiency is such that no individual cell in our body is more than 5 cells away from a blood vessel!

There are differences of course, but if our bodies or a swarm can create this kind of efficiency through development and not with a blueprint for the final system, why do we think that a blueprint in advance will be the right solution in our complex environment? It feels counter intuitive that a standard, hierarchical organisation design will be appropriate for all types of business, or for the life of a single business. Inevitably that’s going to mean people ‘traversing’ that design to achieve something it wasn’t built for. I think we’ve got some experimenting to do.

Imagine instead an organisation where the teams freely expand and contract based on need, and I think we’re getting somewhere. An organisation based on its networks, not its organisation charts:

Teams flex to prioritise a customer-support response and then freely move to a development response to answer a need for a new requirement.

Here are some steps and questions you’ll need to answer to start embracing a network-led organisation:

–         Start with clarity around purpose and make sure that purpose is relentlessly shared and contextualised for everyone in the organisation.

–         Organise around your purpose. If you do want to put the customer at the heart of everything, make that very clear and empower teams to progress that goal.

–         Put your Customer within your org chart, not outside it (see Steve Deming)

–         Align measures to support your purpose, demoting silo/local measures to avoid conflict.

–         Keep the progress towards purpose transparent, with data and customer feedback visible.

–         Give people space to experiment and find the best paths to make progress.

–         Map and visualise actual steps taken for typical interactions, learn and iterate.