Convergence & Divergence

Share
Reading time ~9 minutes

image demonstrating convergence and divergence using people and tools

It’s been a while since I’ve had time to write but I’m enjoying a brief respite between product releases to collect everything I’ve learned in the last 9 months. I have a few rather significant new ideas I’ve been using that I want to share. This is the first. It’s long, in raw-unedited form and likely makes a few mental leaps so please take your time, digest, think about how all this can apply to your environments and ask clarifying questions. I’d like to get this in a more digestible form someday…

Before I start, a huge thank you to Matthew Dodkins who discovered a brief comment Joh & I made whilst presenting at Agile On The Beach in Cornwall last year was something far more significant than we’d realised…

Complex organisational structures cannot be static, in order to remain healthy they must ebb and flow, centralizing & decentralizing around roles, reporting lines, business needs, good practices and knowledge.

Having brought this observation to a more conscious point, I and my fellow managers at my current employer have put this into active use…

Most experienced facilitators are used to talking about a diverge->converge process as used in moving from brainstorming to actions.

  • Diverge = generate ideas
  • Converge = choose the most promising

What I’m talking about here has very little to do with facilitation and is a reversed view (converge, then diverge) however it’s more accurate to view this as a natural continuous tidal cycle.

A loop showing convergence and divergence

Theory: The Converge-Diverge Cycle

The Converge-Diverge Cycle applies to organizational structure, behavior, process and even technology.

Although at any single point in time an organizational structure may appear static, many organizations develop natural rhythms of restructuring over time. At General Electric that cycle was roughly every 2-3 years at a wholesale organizational level. At Red Gate it’s closer to 6 monthly but cycles incrementally through divisions and operational functions.

At worst, poorly managed organizational tides are pretty toxic but at best they help re-balance interactions, interpersonal relationships, behaviours and practices across diverging groups.

Here’s the cool bit…

Which direction are you heading?

You’re always in either a convergent or divergent cycle. If you know which way you’re heading you can make an explicit decision to let the tide continue in its current direction or to turn it back. The longer a tide moves in a divergent direction, the longer and more painful the resulting convergence may be. The longer things remain converged, the more constrained your learning, innovation and evolution.

(unnecessary or diminished-value convergence can also occur – think “spork“)

Simply being aware that convergent or divergent cycles exist makes it possible to step back, observe, interpret the current direction of travel and make a conscious choice.

Your Convergence may be my Divergence

In organisational structures, convergence can shift from one position to another, causing divergence in its wake.  (I’m getting a bit philosophical so I’ll back this up with some real examples shortly).  Think about the age-old “Us vs Them mentality. Most often seen between the “business” and “development” or in bad cases between “development” and “testing” or between you and your supplier or customer.

Whilst it’s important to take individual responsibility for increasing the bandwidth of communication from email to phone to face-to-face, it’s really hard to do – particularly in a conflict situation.  The more physically and organisationally separated groups or individuals are, the stronger the “Us vs Them” pull may be. Beyond relying on individuals to play nicely, how about changing the structure and dynamic of the groups to foster closer collaborative working.

Equilibrium

So now it gets tricky…

Each “Us” or “Them” has a set of existential goals and motivations. These aren’t necessarily combative but often they aren’t aligned to each other. We know this lack of alignment can cause problems but what happens when we realign?

The best example of this that I frequently see is organisational structures that provide a centralised (converged) service. The centralised service convergence drives common “best practices”, efficiency and greater synchronization across the group that are all trying to provide a similar service to multiple “customers”.

This convergence is often at the cost of quality of service, responsiveness, tailoring and specialisation to the needs of a given customer.

The “Us & Them” conversation is between the service and each of their customers.

From this shared starting point, if we reverse this, diverge and decentralise the group with the service team distributed to directly serve each customer we find that responsiveness improves, tailoring increases and localised “best practices” emerge but it will have its own costs and compromises.

Standardization

I spent some years running an organizational standardization programme and have been involved in many others. I’ve seen the pain and cost of these first-hand.  Often the primary benefits are in management reporting and process certification, not improvement. I’m a strong believer in no best practices. Following a “best practice” implies there is nothing better. This mindset will stifle continuous improvement. There are however best known practices for your current context, situation and experience.

Process or tool standardization is not a sensible goal in itself. What is this trying to achieve and is it really the end point or simply a pivoting point between converging and diverging?

Reconsider where you’re standardising today. If these stayed locked-down for a decade and only evolved in a single direction, would this be bad for your teams and your business? If so, what’s your divergence strategy?

Who’s “Us” and who’s “Them”

Initially the ties of a previously converged team remain strong. You benefit from the strength of prior working relationships and team bonds to maintain synchronization.

This only lasts so long. After a surprisingly short period of time – particularly if groups are under pressure – (less than 6 months in my experience), the “Us” vs “Them” returns however this time it’s between groups with diverging and potentially competing approaches.  The former ties have weakened and new ones are formed. And this increases over time.

There is no long-term equilibrium. There is always an “Us” and a “Them” somewhere.

Great, we’re doomed to hate each other eventually and our evolution is over – so what do I do?

Deliberate Convergence & Divergence

There’s many existing strategies for forging and retaining ties between groups and a bunch of organisational team-building resources available with a bit of searching. Most of these need time set aside and essentially keep some bonds alive but rarely provide opportunities for continuous evolutionary improvement.

Here’s the cycle that usually happens

  1. We’re heading in the wrong direction.
  2. Someone realises there’s a problem that requires convergence in a different direction.
  3. An organizational change programme is initiated
  4. Time and money are invested in effecting a large organizational change
  5. Productivity and Morale take a beating.
  6. The changes bake in
  7. Rinse & repeat

Here’s the “deliberate” equivalent

  1. As part of a regular review, current direction is assessed.
  2. We determine if we’re converging or diverging on the right things, what’s working well & what’s not.
  3. We make an explicit decision whether to change direction.
  4. We give things a “prod” in the direction we want to go.
  5. We do this regularly enough to stay fresh but slowly enough to be stable.

Here’s a couple of real examples from where I am right now…

In Practice: Organizational Convergence & Divergence

We have a number of teams who are responsible for providing centralised services. HR, Publishing, IS, DevOps, Finance. These groups are co-located teams and interact with their internal customers.

Team 1: HR

Our HR team assessed how they were working and made an explicit decision to diverge.

Each division now has an HR specialist who sits co-located with their customer.

The HR team still get together regularly but they’re now a diverged group.

They’ve structured things so they won’t diverge any further but also know that all decisions are reversible. We may re-centralise them in a year or two’s time in order to put a load of energy into a large centralised change.

Team 2: Dev Ops

Our DevOps team were a centralised group for over a year. They worked closely with IS but provide a service to sales, development and finance (among others).

Because of the nature of projects and changes on the cards we had 2 choices.

  1. Disband DevOps, put skilled DevOps staff in each delivery team and diverge the service
  2. Converge DevOps, Business Intelligence and IS even further to run under a single pillar of the organization.

We chose further convergence. The team have radically altered their processes and have focused on the top priority company-wide priorities. Some other teams will miss out on their requests but in the larger scheme, this was seen as the most effective structure for our current needs.

Team 3: Sales

Our product organization was divided into a number of divisions. Each division had its own sales force co-located with the development teams. This was working great for development but it gives a really bad customer experience when a customer owns products from multiple divisions. We’ve converged the sales team and brought their processes and practices together to give a better customer experience. We’ve sacrificed the closeness of development and had to drop some division-specific process tailoring but we’re having better conversations with our customers.

In all 3 of these cases, I fully expect these changes to cycle in a different direction at some point in the next 2-5 years. As do the teams – it’s simply how we evolve.

Because we know things will change again, we’re less entrenched with the status-quo.

As an aside, we don’t hot-desk here but because our organisation is so fluid, most staff have moved desks 3 or 4 times in the last 18 months. We treat this as normal. We still have our own space, desks, walls & possessions but we stay mobile enough to move ourselves in under an hour’s effort.

This week we’ve asked all our development staff to propose where they each feel they can best contribute for the next 6 months and based on those preferences I’m expecting to see over 20% of our teams move again.

In Practice: Process & Tool Convergence & Divergence

I mentioned earlier that standardization is a directional way-point, not a goal.

I spent nearly 2 years “standardizing” Scrum, Lean & Agile with one employer. At the time it was the right thing to do. Most parts of the software group had never had any form of large-scale convergence. As a result the effort & pain were significant however we took teams who had been working in their own evolutionary islands for 10-20 years and brought increased commonality to them. We reached very close to standardisation but deliberately designed our ISO processes to support limited positive divergence.

At my next employer, my first action as head of project management was to explicitly state that we would not be standardising our project practices. All teams had standardized on Scrum 3 years earlier and had been slowly diverging. Having observed the teams and contexts it was clear we had scope to diverge further whilst still remaining healthy. In fact, it gives us the ability for concurrent parallel learning and improvement. We learn more and we learn faster.

2 years later we’re at the point where I want to introduce some convergence. Rather than a complete standardisation we’ll be developing a playbook of “known good practices”. It won’t be exhaustive, it’ll start with the top 25 things we think are a no-brainer and we’ll work from there. Some of these things won’t be common across the teams when we start. Eventually they will be…

… and then we’ll decide whether to continue converging or to diverge again.

Great, now what?

Review where you currently stand.

  • Which groups are converging and diverging? – Observe and interpret.
  • How long have they been moving in that direction?
  • Are you willing to continue or is it time to adjust? – Make an explicit decision
  • How large and fast a change is needed? (if any)
  • How will you push in the direction you need? – Deliberate action
  • How long do you expect the next cycle to last? – Tidal change
  • When will you next check?

Whew! That was epic. Thanks for reading to the end. As always, I’d love your feedback.

 

 

 

One thought on “Convergence & Divergence

  1. Thanks for killing the captcha ;-)

    I find this sort of stuff fascinating – since I still find I spend the vast majority of my time dealing with problems caused by silos and overspecialisation. Which for smaller organisations/teams is almost always a bad idea in my experience.

    But you are 100% correct that they’re not all bad – you do lose something when folk with related skills can’t get together to sharpen the saw together.

    A few random thoughts to add to your stew:

    * One of the things that’s been in my thoughts recently is often that the problem isn’t the specialised focus per se – but the fact that the speciality is “wrong”. The communities of practice we group disciplines and departments around are fictions that we’ve created. Sometimes they’re the wrong ones. DevOps is a great example of that. What great DevOps folk do – and how they interact with the company culture – is substantially different from what old-style ops departments did/do. A big part of getting this working well is figuring out what those convergent groups should look like and behave.

    * I think you’ll find some of what Jabe Bloom has been thinking in this area of interest. If you’ve not seen it already his presentation at Lean UX NYC earlier this year kinda-sorta pokes at things in the same area

    – especially on when you diverge/converge.

    * Where do organisations like Spotify sit on your convergence / divergence dimension where specialities are explicitly acknowledged, but implemented as cross-cutting concerns across feature teams… the AOP of organisational structure ;-) I’ve not worked with teams like that myself so don’t have a good feel for how different/similar that kind of structure is to more traditional approaches.

Share your thoughts...