Sunday, November 18, 2012

Why the Public Sector Needs to Get Stupider

...or "From Intellect to Intelligence".

There are a handful of people whom I've never met in person, but talked to a lot over the years online, and who have influenced my thinking more than I could suspect in that time. Richard Veryard is one of those people. Even back when my blog "Into the Machine" was called "Blunkett is an Arse", Richard prompted me to think heavily about the role of power in society - everything from CCTV through to newspaper headlines and reasons for going to war.

Richard introduced me to Stafford Beer's concept of POSIWID (The Purpose Of the System Is What It Does) which trips off the tongue more easily and addictedly than you'd expect. Recently, he's focused his efforts on Enterprise Architecture ("#entarch") and Organisational Intelligence ("OI"), and I'm very much enjoying shamefully yanking ideas out of his OI Primer e-book.

I don't plug things very often on my blogs (and it's horrifically short notice) but I really do want to mention his 2 courses this week: on Business Architecture and Organisational Intelligence. I think there are still spaces left. And obviously as I've never actually met Richard, I'm not guaranteeing anything. But if you're interested in this post, or this blog, check em out. There's also an Org Intelligence group on LinkedIn for good discussion.

But it's more than just a shameless plug - and more than just a way of paying him back for the insight over the years. Fundamentally, his driving factor (IMHO) is around something which is not just lacking in many groups, but dangerously lacking across society. In fact, my whole last post on the PCC elections, nuclear subs and mythological engineering was about this lack.

In short, we lack systemic intelligence.

What does that really mean though? And more importantly, so what? Many smart people instinctively know that our most common modes of organisation lack an inherent "togetherness". I'm not saying anything new here.

But what we can learn from Richard - and from looking around us, and from taking a moment to think clearly - is how to move from just knowing there is a lack of systems-thinking, to doing something about it. To rejoining the things which are fragmented.

Departments are Inherently Silo Factories

In the public sector, the defragmenting process is bubbling under like the power behind the throne. It's why the Patchwork project makes sense to people. It's why everyone goes on and on about breaking down data silos. It's why joined-up government arose - but ultimately, its fall also highlights not how difficult it is, but how badly prepared we are for it.

Our pin-factory-style, categorical hierarchy mentality likes to divide work up into efficient processes. Many people claim this to be an "efficient" way to focus on a particular labour task - which it can be, to an extent. But this also leads directly to those data silos we mentioned earlier - because it's not the data which is inherently silo'd, but the labour itself. Once a person or a group becomes responsible for an organisational function, both the data and the importance that result from it become an asset - and assets are there to be protected, especially under competitive pressures.

The same effect is at play whether it's one person keeping their spreadsheet private, a department keeping its data in obscure formats, or a company slurping personal data on millions of customers. Data goes hand-in-hand with function, and divided data leads to divided functions.

The Road to Recovery is Balance

The first challenge in reconnecting these functions (and therefore departments, and data) within a system is to get out of the existing model. It's important to remember that an fragmented viewpoint is mutually exclusive to systems thinking. Systems thinking is not about the best way to get two existing units (departments, groups, people) to talk to each other, nor about opening everything up to the glorious light of transparency.

Systems thinking is about how the units depend on each other and what it makes sense for them to share in order to do their (otherwise standalone) job. Object-oriented coders Get This.

In other words, the underlying mental model for a more systemic form of organisation needs to shift to one of multiple contexts - firstly, the overall purpose of the entire organisation, and secondly, how the needs (data, assets, etc) of each unit within that organisation break up and overlap.

That is, there needs to be:
  1. Balance between the output of each unit within the organisation, and the organisation as a whole - no one unit should be seen as "more" important, in the same way that the brain is not "more important" than the stomach. The priority is that the organismisation acts as a whole.
  2. Balance between the "internal" and "external" roles of each unit, so that effort is not wasted on either information over- or under-provision. Each unit should have access to the information it needs to do its job. And yes, this changes over time. Get used to it.

Forwards, stupid workers! 

"Architecting" this is not just a role for a head honcho or a business consultant. Ignore what well-paid people tell you. It's not even a bottom-up process.

The needs of units and the whole organisation change over time - technology relating to certain tasks changes, staff change, external factors mean new pressure, political goals shift. As a result, this process has to be infused into the whole of the organisation. It is a culture and a strategy on one level, but on another level it is also an individual choice

The divided labour approach to work - ie. what you have in your head the moment you get to your desk in the morning - intrinsically ties together function with knowledge. "What do you need to be told in order to do you job?" - or from a more negative, jobsworthy viewpoint, "I can't do that because nobody has told me why or how."

Divided labour resists flexibility. And this is why joining everything together takes more than someone banging a gong or drafting a "data sharing" proposal - the rules themselves need to be flexible for flexible working to work.

But so often, the body of working knowledge we hold - and the reasons why we hold it and where we should apply it - are valued. They form a set of ideas centred on our job function that I call "Intellect" - in other words, a specialised definition that takes the immediate environment, and hardens it - formalises it. This means we can know if what we're doing is "right" or "wrong". And we can't be judged for not doing stuff that lies outside of that context. Nobody ever got fired for buying IBM.

Losing this "Intellect", this hard-wired context, is key to making our organisations smarter.

We need to become stupider.

Bad day at the office
Photo: San Diego Shooter

The Dashboard Wisdom of Stupidity

Being stupid is not a weakness. I heartily wish that I had been more stupid in school, and wasn't so afraid to ask questions when I didn't fully understand something. Because when all the parameters around you are shifting, guess what? Nobody really understands anything. And even more so, nobody can predict what is happening to the people they're connected to.

Asking questions gives us feedback. One of the fascinating areas I looked into after reading Richard's book was the usefulness of dashboards - which are basically designed to answer that perennial question, "What's going on right now?

Feedback is only useful if it's fast - fast enough to allow us to relate our actions to their consequences.

And immediate feedback is awesome because it gives us an answer before we've even had time to ask the question. A dashboard, an ever-present source of up-to-date information, assumes we are stupid - or, at least, could turn stupid at any moment. "Hey! Driver! Sooner or later, you're going to need this information, you know?"

And when you're sitting there, protecting your body of knowledge and your data in order to protect your job, hanging on to that "Intellect" you've carefully gathered doesn't make you "Intelligent". It makes you "Wrong".

Your Silo is My Silo

The world is changing at a much faster pace than we're ready for. No, scrap that. The world is change, and we don't like change. Everything we do is about controlling change. Our policies are direct descendants of the 17th century,and hence our mental models are struggling to keep up with the change going on - change that we've created, ironically. (Remember, pin factories didn't always exist.)

"Systems" intelligence and "Organisational" intelligence are misnomers, because people are individuals, not organisations - and organisations only really exist on paper and in law courts, and can't make me a cup of tea in the morning.

But individuals exist within organisations, within systems. There is little to differentiate the two except perhaps where we stand. 

Accepting that we are part of a system is essential to realising that this "systemic" intelligence is also a part of us. It is an aggregative effect - a flow of cause and effect from person to person, and unit to unit. It is not a "culture" or a "programme" or any "Thing", because it is always a dynamicism that acts on every level.

Asking questions is key to opening up that flow - the flow of information and understanding between units, between silos, and between contexts. It breaks down the protection of Intellect. It is a form of empathic efficiency. It is flexibility. 

It is necessary.

Want to know more? Richard's courses on Enterprise Architecture and Organisational Intelligence.

Friday, November 16, 2012

PCCs, Nuclear Subs, and Mythological Engineering

With the low turnout in the PCC elections yesterday,  and this interesting piece on the construction problems with the UK's new nuclear subs, I can't help but think of Barthes' "Mythologies" and the state we're in regarding symbolism vs engineering.

i. asking the right questions

Barthes lays out a sketchy-but-useful/interesting framework for signs and symbols, and in an ever more mediated world (first through broadcast media such as TV, and increasingly through short-attention information-overload) this framework seems more relevant.

The 3 main questions that a mythological viewpoint helps get at are:

  1. Is what we're doing actually working?
  2. If not, can we find out why not?
  3. And if not, are we willing to identify where our own beliefs are causing those reasons?
None of these are significantly mythological - we can fail at something because we lack understanding or experience, for instance. Indeed failing is also learning, if the context and expectations are set out properly.

But the PCC and Nuclear Sub cases, when viewed from a symbolic, mythological viewpoint, become a lot more understandable.

ii. nothing to see here

In the case of the PCC elections, it's telling that many people voted not to improve the operation and efficiency of their Police force, but to keep out people who they think would make their Police force worse. Question #1 has moved from "is it working?" to "is it not breaking?". Or, in other words, from "how can we improve things?" to "how can we stop things from getting worse?"

This shift in rationale is essential to understand. It shows that politics, a symbol in itself, has become a stronger signifier for maintaining the status quo than for setting out sustainable solutions that involve cross-society engagement. We can say that Democracy has become about keeping people out rather than integrating people in.

The PCC elections are clearly to be seen in a light of localism and "democratic accountability". The elections are a symbol for democratic principles, but ones which have left behind everyday operations of how policy becomes policing. The "polis", in every sense, has become an abstract notion, and can only surely be less empowered because of that.

Not only was it seen to be more important to make the system "votable" than have a working system, the idea of the vote itself took precedence over the voting process.

iii. an aside: symbolic actions

Barthes contrasts the object as a "symbol" to the object as part of an "action" - eg. a woodcutter chopping down a tree performs an action on the tree, and so there is a real-world interaction and effect with the tree. However, the image of a woodcutter cutting down a tree, or a generic image of a tree in itself, is "symbolic" in that it has no direct, real-world consequences. A logo of a tree may act as a standard, but is an indirect effect, and can certainly be detached from the actions it inspires. (Many people find it easier to be inspired by a logo than to act based on inspiration.)

iv. unclear power

Nuclear power is another symbol, as any fan of Dr Strangelove will understand. The paradox with nuclear power is that it is "inherently" (or "naturally", as Barthes would put it) powerful and therefore dangerous - we accept this without question. By wielding "Nuclear power" as a symbol, we also wield an intrinsic argument for more control and global sanctions - because power is concerned with potential rather than actual abilities.

This paradox leads to the problems seen under the HMS Astute nuclear programme. Building nuclear power as a symbol is very different to building nuclear power as a "thing" in the real world.

The paradox is this: You cannot design a machine (or an organisation, or a person) based on symbolic or economic principles.Sure, they can feed into the process, but engineering needs to maintain an inherent, internal coherence to provide a "thing" which functions as a whole. Allow a fragmented economic-political process to take priority, and you will end up with a fragmented machine.

Ironically, the nuclear machine does not depend on the nuclear symbol in order to work, but the symbol is impacted by the effectiveness of the machine. In undermining the effectiveness of the machine, the symbol also devalues itself. 

v. tappity-tap

Churchill said that "Scientists should be on tap, but not on top". I don't believe it's a case of scientists (and engineers, and anyone that designs any kind of process) being on top of  politicians, or vice versa though. The two "sides" have very different briefs and contexts that need to work with each other. There is a "what" and a "how", and the twain will always meet somewhere.