Author: mdegeorge Page 2 of 21

It’s time to change the way we think about escalations in preparation for the organisations of the future.

The word “escalation” has an ominous tone. In corporate cultures skewed by managerialism – that is, most organisations – escalations get a reputation as being a risk to your career.

An escalation is often seen as a failure to collaborate, when in reality it’s a mismatch between the level of the organisation where particular decision rights currently sit versus the availability of information required to make those decisions.

As with performance management, the discipline of general management has focused the management of escalations on the people aspects of the process. People are very important, I grant. But when any process too heavily focuses on the people aspects the unintended consequence is that people are identified as the problem, and only people-focused solutions are found.

Performance Management, while ultimately concerned with the performance of the whole organisation, makes us think of yearly performance management processes focused on individuals.  Progress to change to this slow, hard, work that’s against most corporate cultures.  Changeling our approach to escalations will be the same.

Neither escalations nor performance management have much to do with individual behaviours. Performance management is simply about measuring and optimising performance. This might involve people’s behaviours but is actually a bundle of people, process, information, and technology (where those words are defined so broadly as to mean they encompass every possible thing).

The correct way of thinking about an escalation is to think of it as moving a decision-making process or instance of a decision to the appropriate level of the organisation. If something is escalated it couldn’t be resolved where is it was.

Escalation is simply the opposite of delegation. Our organisations are comfortable with the idea of increasing spans of control, and reducing layers of management. This means there are positive delegation flows occurring in all high performaninng organisations.

It makes sense that continuous optimisation of an organisation undergoing change also includes cases where decision processes or instances of decisions need to be escalated.

Automation trends therefore offer a challenge to the general management discipline. Automation means that delegation and escalation are often to or from “robots” rather than people.  This is having a profound effect on management.

In an organisation governed, managed, and executed by people an escalation is a handy escape value. Those executing the work get to shift a decision to the right level of the organisation.

But because managerialism has been people focused it’s become confused about delegation and escalation. If a person has been delegated to and doesn’t make the right decisions it’s considered a failing. Similarly, if a person escalates when they were not supposed to, or doesn’t escalate when they are supposed to this is also considered a failing.

Organisations that a governed by people, managed by people, but in part executed by machines bring the ambiguity about escalation and delegation to a sharp point. If a machine isn’t performing delegated tasks it’s the fault of the delegator. Similarly, if a machine isn’t escalating at the right time it’s the fault of whoever it’s supposed to be escalating to.

Australian regulator ACCC recently came to the reasonable conclusion that when an automated decision process makes multiple incorrect (and in this case illegal) decisions, or omits steps it was legally obligated to perform, the organisation is break the law multiple times. This is as opposed to breaking the law once via the single programming error that caused the multiple illegal actions.

See Tweet: https://twitter.com/matthewdegeorge/status/931256101818966016

“You cannot avoid liability by saying ‘my robot did it’” #ai https://t.co/2y9Ki4v8c2

— Matthew De George (@matthewdegeorge) November 16, 2017

This is profound. It means our understanding of delegations  and escalations needs to change. It’s also why an organisation that is governed by people, managed by robots, and executed by people might actually be a more likely future form than organisations where only the execution is robotic.

As per the battle between general management and architecture, it’s getting close to the cross over point:

Aegon: Make Management Your Business Partner for Successful EA Implementation

The recent “Is Government IT Getting Worse?” provided just enough of an overview of the state of digital government to get me fired up.  

I don’t understand why we keep reviewing these things called “IT Projects”. For as long as I can remember we have been saying “it’s not an IT project, it’s a business project”. I got sick of hearing it not because it wasn’t true but because it was trite.

But we are still assessing “IT projects” and trying to improve the IT parts of change efforts in isolation. 

The inevitable result of this is either over engineered “requirements” focused effort or the popular half-solution to half-the-problem that is “agile”. 

While it wasn’t always the case, over the last 10 years or so every IT department I have worked with has had a more ounerous and often self-imposed discipline around managing change projects than other “departments”.  

You read that right – IT departments are trying desperately to improve their project based discipline and have pushed ahead of most other departmental or cross department program management office (PMO) initiatives. 

I see it everywhere. But because IT departments are taking the time to package change as projects they are subsequently driven into a position where they have to justify spend more elaborately. Also, where they have to justify spend more elaborately this makes IT change more project based.  

On the demand side, PMO initiatives have been dumbed down so much that without the discipline imposed by IT they would have almost no impact.  

Perhaps the worst combination is “the business” trying to take control of IT with the IT department letting them (i.e. “Agile”).  

Of course, there are improvements and a backlash against this approach. Much of the “digital” discussion is trying to solve this too – in ways I don’t always agree with. But while I often don’t agree with Paul Shetler when he talks about fixing procurement as an enabler of better digital outcomes he is spot on.

But in terms of having to justify the activities, IT departments always get a raw deal. It’s very difficult to justify IT activities in the same way you justify activities that have more concrete outcomes. “IT Projects” when defined as such cannot claim or commit to many sorts of benefits because they are by definition just the “IT” parts of the initiative.  

So when you assess “IT Projects” you are assessing an increasingly arbitrary sub-set of the value chain towards outcomes.  

You have to assess value creative, and change initiatives as a whole – not just the IT bits. 

Whatever effort you assess as “IT projects”, you can guarantee there is double that being spent on “IT” in other budgets. Also, you can guarantee some of the service outcomes being attributed to IT spend are from initiatives that never had any IT spend allocated to them in the first place. Or that had insufficient IT spend allocated to them. 

Rather than yet again assessing the “IT Projects” why not assess change initiatives in general? Why not look at:

• Change initiatives such as new policy deployment, data capture and form changes, new business-lead deployments of technology and see how they were managed
• Where change initiatives didn’t have IT budget the ownous must be on the initiative to justify why. Surely, every change initiative has IT impacts – at the very least on capacity of standardised IT services
• Where change initiatives did have IT budget how do they compare in performance to “IT Projects”? (Oops, now I’m doing it)
• What was the contribution of these change initiatives and how did they impact service?

We live in a world that is capability-based. The functional organisation is completely dead. The idea of an “IT Project” is completely dead. 

By continuing to look at inherently disconnected initiatives like this we are causing more problems than we are solving. 

It also means we have to be careful about delivery approaches. When an “IT Project” is spending 60% of its budget on design thinking workshops to try to change the way service is delivered that is in some ways admirable. But it’s not “IT spend” in the sense that it is guaranteed to improve outcomes that would be attributed to IT. In fact, it might arbitrarily reduce the investment in certain types of quality. Less time coding is less quality – regardless of how much of an improvement there is in what is being coded against what would have been coded.  

There is a massive trend as organisations shift and The Death of the Functional Organisation occurs.  There are three effects of this on every profession / silo / function.  

They all:

1. Normalise to soft platitudes at the top end.  Each function says it “… wont succeed without executive support”, “… is all about collaboration and leadership”, etc

2. Focus on getting others to recognise the value of their datasets.  “… integrate our data into operations”

3. Try to build a comprehensive theory of the firm where there profession is the key.  Eg. “Organisations are really all about change”

The latest example is the “tax” function of all things:

https://www.strategy-business.com/article/The-Marriage-of-Tax-and-Strategy

As usual there are some great points in this article – but they are part of a trend towards capability-based governance rather than about the importance of the tax function specifically.