Don’t let your operating model lead you off a cliff
As an enthusiast of socio-technical systems, I like to observe how changes impact people, their behavior, the organization's culture, and…
As an enthusiast of socio-technical systems, I like to observe how changes impact people, their behavior, the organization's culture, and any changes to ways of working and collaboration.
For those of you with experience in large, complex organizations, you may recognize the ‘target operating model’ (or worse TOM) approach, often triggered by a new executive arriving in the organization.
Seldom is the model / approach self-implemented, as people are often too busy to stop what they are doing to improve (the irony). The new executive wants to replicate outcomes from their prior firm and is using the same approach. In complex / uncertain work like product development, content plays a key role. You cannot apply such things universally.
Target Operating Model 1.0
The older approach has focused on the swing of the pendulum between vertical and horizontal and often meeting in the middle to form a matrix structure — often the best and worst of both.
This can result in people either having multiple managers with thick and dotted lines showing up on organization charts or the reverse where the same manager becomes responsible overnight for both a region and department.
For global organizations / departments, that don’t have usually have a regional customer / consumer, I was often confused the most by this move.
Usually the rationale is to support regulatory and supervisory needs when there isn’t necessarily a clear regional business to support.
Target Operating Model 2.0
The latest approach is delayering, removing layers of middle management (often referred to as “the Frozen Middle”)— to help empower you and move you closer to the CEO (even though you may only ever see the CEO on the intranet). This flattened organization comes from the playbook of Silicon Valley unicorns or the FAANG’s of the world. How flattened your organization will be remains to be seen but something between 5-7 layers could be used.
If you are lucky, there’s even a peer organization in your industry who has already done something like what you are being sold on so that you can aspire to be just like them, but better (even though they made the same changes 5+ years ago and you have a lot of catching up to do). The phrase ‘same-same, but different’ comes to mind.
Reducing middle management, what could go wrong
Delayering has merit, but can cause more problems than it solves without carefully understanding how things work. I can see the developers shouting with glee, less managers means more freedom to be autonomous (just like Spotify!).
The delayering that there’s less people to do work that you previously didn’t have to do yourself. The bureaucracy did that for you — who will do the budgeting now — it that could be you — so be careful what you wish for!
The answer seems to be to empower the organizations to take more accountability and in doing so, empower them to have some level of autonomy (more on that in a future blog).
This TOM 2.0, is driven by a new senior executive joining the organization and wanting to have similar outcomes / behavior to their prior firm. Afterall, that is why they were hired in the first place: digitalization / agility etc. If your strategy needs help, I recommend the strategy mad libs site (Thanks to Simon Wardley!).
Scepticism aside, these are good practices, they just aren’t enough! The same organization and people are there pre and post the new executive joining.
To see real change in an organization, change the people or change the people.
I’ve only seen people change when they really want to (it makes them look good to be early adopters) or when it’s too late and everyone else is doing it (often referred to as the late majority / laggards) Even with a fresh coat of paint, the late adopters have been around too long and can be immune to such changes. They may adopt the new terms in name only, behind closed doors / amongst allies they carry on as before.
A common anti-pattern is adopting agile practices from scrum and selectively picking the ceremonies / events, as they thought some of them were a waste of time without ever having done them properly with support from a practitioner or having gotten rid of other meetings / processes.
This is further exacerbated when you scale practices / ways of working at the team / team of levels level without bringing leadership along for the journey. This gets even more amusing when the wider organization is still running program committees, governance forums etc.
These early adopters are running around claiming agility and no longer accept requirements, have ‘big-room planning’ events and the teams make their own priorities. If there’s ever an opportunity to horrify a group of risk averse people, it is saying such hyperbolic statements without any wider context.
This type of scepticism only really values social proof as the only way to convince them. These same people won't value what an industry is or has done, what the scientific research suggests of other organizations / scientific research / a health body of knowledge.
Mid-transformation — the haves and the have nots
Until the entire organization is fully working in this new way, many people are left having to attend new and old type meetings in parallel. They are told they will spend less time attending meetings, they will be more empowered yet they cannot see it.
This is a dangerous time and everyone is on egg shells and can revert to a state of scepticism at any point in time. This is where having seasons practitioners and a network of weak ties or champions (see: Damon Centola — Change: How to make big things happen) to keep things from erupting.
Those supporting the new organizational ethos quickly point these people out at pariahs rather than a genuine source of criticisms to listen and address.
The cynics, sceptics can be some of the most powerful allies in the company if you take the time to listen to their genuine concerns and actually act upon them, including them on the journey.
The alternative is to be greeted by a slick new intranet article / email blast describing the transformational change with an engaging video from the enigmatic new executive. Often joined by the leadership team as a way of showing solidarity.
This can help with a show of solidarity if sincere — it can however backfire and reduce to an awkward set of executives who haven’t spent much time in front of a camera reading off a teleprompter in visual discomfort (watching these people squirm on camera reminds me of a hostage situation reading out a set of demands — the hostages being the leadership team and the kidnapper being the new executive).
This is the opposite of ‘doing twice the work in half the time’. The chosen departments working in the new ways, are now the ‘cool kids’.
They tell everyone else they need to change and adapt, or they are slowing them down. The chosen departments are now ‘so freaking agile’.
Rather than get road rage at the slow drivers as you're stuck in traffic, why not get out of your car and help!
If you look at Better Value Sooner Safer Happier, Open Space Agility , Lean Change Management, it seems that you cannot and should not force change on others.
Give people a reason to change, the safety to learn and experiment (and fail in the experiments), show them through coaching and support, rather than telling them and enacting the operating model / agile police.
Forcing change only helps create negative feedback loops, giving the new ways a bad name and putting the wider approach at risk.
When the have nots, become the haves
Even once a department is selected for ‘transformation’, I hear them cry: ‘show me an end-to-end example of this working’ — quite often, just as the changes are kicking off and not yet taken affect. These sceptics remain validated, no one else is at the final destination, no evidence is available to prove that it works.
I love the book Better Value Sooner Safer Happier and the phrase ‘invite over inflict’ comes to mind. Pushing people through a transformation meat grinder to produce a ‘fully agile’ group of people, just doesn’t happen in 3–6 months.
The reality is, the end is just the beginning.
Continuous learning & improvement is the aspiration. If you get through to people, getting them to see the value in the on-going learning and change is how the improvements continue rather than stagnate.
Giving people training for new roles and ways of working, changing the composition of their teams and wider organization, and performing new ceremonies doesn’t inherently make anyone materially different over night.
That is like putting a team of McDonalds employees in chef whites, giving them great ingredients, cooking equipment, and expecting a Michelan start meal.
Blaming vs fixing impediments
Even with the best coaches, tools and practitioners in the world, your existing systems, process, and people need to change and adapt.
This takes years, a continued investment in your people, with continued discipline and self-reflection to identify and profoundly change the systematic issues that are really slowing you from ‘moving fast’.
Blaming your SDLC process for your inability to automate your entire build and deployment pipeline isn’t exactly a fruitful endeavour.
The ability to deploy on demand comes from learning new practices, establishing trust, building quality and focusing on reliability. A simplified process with less guard rails will only amplify your own inadequacies.
Work with the people who own the process, understand the drivers behind the need for certain controls and produce ways of automating the controls rather than bypassing.
Prove that things can be done, automation of a control is usually better than manual execution, collection of evidence. Once you automate, then you can challenge the control but don’t start by throwing it out the window.
Feedback loops
I’d love to know from your experience what patterns and anti-patterns you've seen along the way.
What have I missed that should be highlighted?
What could I have described better?