Author: mdegeorge (Page 1 of 20)
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
— 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:
Another good example of operationalising your brand:
One of the MWT core components: Operationalised Brands.
Of course, it’s critical that your organisation has a unique and differentiating brand / set of principles.
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.
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:
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.
Great article on patterns by Kris Meukens here.
My slightly self-indulgent reply is below. I’ve always been fascinated by how our understanding of IT and organisational design in general seems to follow the same path of Christopher Alexander’s works on the design and architecture of the built environment.
I think it’s interesting to see the parallel and delayed timeline between “patterns” as they evolve in built architecture theory, versus patterns in IT.
I’m not an expert in either but I see the history of patterns in built architecture through the lens of Christopher Alexander:
- Notes on the Synthesis of Form (1964, year 1). Starts to describe what later came to be known as “patterns”.
- Notes on the Synthesis of Form – Preface to the first paperback edition (1973, year 9). Already starting to rebel against those who focused on “design methods” as a meta study and assets “I reject the whole idea of design methods as a subject of study, as I think it is absurd to seperate the study of design from the practice of design”.
- A Pattern Language (1977, year 13). These are fully formed patterns with the notion that they can be combined to create designs. It’s not a simple mix and match – still leaves room for a design process.
- The Nature of Order (2003, year 39). Doesn’t exactly reject patterns but focuses on wholeness, a set of qualities, and a set of structure preserving transformation that help designs unfold.
- The Battle for the Life and Beauty of Earth (2012 – however focuses on 1985, year 21). This focuses on two world views that he saw as in battle – one of which was opposed to his style of building.
Reading “Battle” in particular makes you feel our current understanding of patterns and our obsessions with Agile, Design Thinking, etc mean we are in the equivalent of year 25.
Reading the above article feels like we’re heading towards the equivalent of year 30. I mean this as a compliment.
Good article, including the simple fact:
In the industrial company of the future, there won’t be a separate IT department.
I’m well known for not liking analogies. I find they generally give people comfort that they understand something without actually changing how much something is understood.
So if I’m forced to use an analogy I’ll at least try to use one that hasn’t been used before, and to use it until it breaks by folding backwards on the analogy so it no longer makes sense. My data quality assurance analogy at the moment is:
Imagine you’re asked to prove that you own your house.
This is an analogous to the regulatory trajectory in financial services – where increasingly data provided to regulators must be attested to met certain data quality criteria.
So again, imagine somebody has asked you to prove that you own your house. You can do this by presenting a deed of title. You might also make a humorous distinction between you owning your house versus you owning a mortgage. Because really the bank owns the house, am I right?
But within this distinction you can make a fairly precise statement about how much of your home you own. You might need to rely on estimates regarding what it’s worth, but you can get the percentages of ownership pretty accurate.
But imagine if deeds of title didn’t exist. Imagine mortgages didn’t exist. Imagine plans that show houses appearing on lots with specific boundaries and reference points for context didn’t exist.
Imagine again being asked to prove that you own your house without the benefit of deeds, mortgages, plans, addresses, and other context. It’s still possible to prove ownership. Now you have to lean on concepts like homesteading; and create a narrative chain of ownership based on the initial claiming and working of the land, through successive transfers of ownership to your own claim. You also have to devise your own way of identifying your house – perhaps using a flag with your family crest.
The problem with this approach to proving ownership is that it’s different for each home. Everybody would need to tell the entire story of how this particular home has come to be on this particular block of land, and who participated at every step of construction and transfer of ownership.
The depth and level of corroboration for this story of ownership would mean we’d need to bring in many of the people who are characters in the narrative and confirm their roles and recollections. Some of these people would disagree with particular points in the story enough to open up doubt or all least require further alternative corroboration.
Once some of the people in the narrative die, or even if they just refuse to turn up for each successive re-telling of the ownership narrative, you lose the ability to prove ownership. This type of approach is therefore clumbersum – requiring a complex narrative that is different for each house – and ultimately inconsistent in the level of assurance it can provide.
The level of assurance is itself dependent on the unique and total narrative around ownership. If, for a particular home, part of the ownership story contains the unsolved murder of the owner and subsequent homesteading by a mysterious stranger, then the certainty of ownership is different than for an ownership story that doesn’t contain that feature. So the idea of a proof with 95% certainty cannot be committed to in general.
The alternative – when you don’t need a completely different narrative ownership story per individual home – can’t be designed by any individual home owner. Instead it has to be built up, shared, agreed, and sustained by the community.
The system for proving home ownership that we have now, that allows for proof of ownership, and even allows as to manage precise percentages of ownership, is the analogy I use for data quality. Because information passes through the community like the ownership of a house, there needs to be a framework agreed by the community so data quality can be consistently understood.
When somebody visits your house for dinner, it is enough that you answer the door to prove sufficient ownership of this house to not expect dinner to be interrupted. Sufficient ownership for this purpose isn’t even real ownership – it could just be a rental agreement. Whereas other assertions of ownership require further proof.
If your organisation doesn’t have artefacts that describe the structure and flow of information it’s like not having house plans that show which property we are talking about. Likewise, if the community doesn’t agree to a specific, potentially costly, process of verification of data as it is transported across the organisation, this is like not having title deeds that you can depend on.
Still with me on this analogy? No, me neither – which is why I don’t like analogies.