A Tight-Loose Collective Operating Model for Local Government

I’ve been really enjoying the energy around the various discussions that have been happening lately around the need for a structural modernisation of the LG sector, and the growing feeling that doing so will need us to think increasingly collectively. Indeed, last week I argued in Computer Weekly that we can actually deliver localism much better in the long run by ruthlessly standardising and sharing stuff at the back end, freeing us up to focus precious bandwidth and resources on local innovation at the front end, where it matters to citizens. I also mentioned in that piece that I’ve thought for a decade that some of the reason we haven’t really done this is that understandably, ‘digital’ has come over time to mostly mean user-centric service design/development (over which councils have control) rather than sharing back-end infrastructure and standards (over which they don’t, despite valiant attempts: I think this is a shame because it has slowed the sector’s ability to modernise. However it’s one thing having opinions and writing stuff of course, and another to actually try and Draw the Thing, so I thought I’d better have a go here (a picture tells a thousand words, etc).

First, a bit of context: the picture is informed by two linked ideas which are super-relevant for helping the LG sector to decide where to innovate and where to standardise: ‘tight-loose’ and ‘cathedral and bazaar’. Karl Weick’s tight-loose ideas argued that some types of organisation were suited to ‘tight coupling’ (my way or the highway), some suited to ‘loose coupling’ (free up people to innovate) and some to a mix of the two. Eric Raymond, writing about the open source community, contrasted more traditional, top-down, rigid ‘cathedral’ structures (think traditional, waterfall software development) with ‘bazaars’: local fora where locally appropriate/relevant solutions are continually negotiated (many might think of traditional local government here). Drawing on these ideas, the puzzle the picture tries to address is: how do we collectively adopt a mixed, ‘tight-loose’ model that combines the benefits of a common plan (cathedral) with the agility and localism of the bazaar?

The picture above offers a high-level idea of how a tight-loose collective operating model for the sector might work. Starting first at the bottom (blue layer), the ‘tightest’ part is for standard tin and wires (laptops, infrastructure hosting contracts, etc). There is nothing even sector-specific about these, and so there can be little excuse for spending public money on anything but commodity, vanilla-flavour, since doing so adds no value to citizens at all (think building your own Word, Google, etc: now why would you do that?). Low value-add (in terms of councils fiddling with their own).

Second, and moving up the stack, we can see a cluster of three other ‘tight’ things. The first is a set of DHLUC-mandated common standards, maybe curated by some ‘Local GDS’ (perhaps a muscled-up and well-funded DHLUC policy/digital planning team). This is definitely the ‘cathedral’ part of the mixed model — a beefed up, extended, and probably mandated version of some of the existing standards in the sector: common operating models, service patterns, technical architecture, etc. Low value-add (see above).

Third is much of the existing line-of-business commercial software. Since, again, actual citizens rarely see and do not care about this, providing it works, there is no excuse to pay suppliers to salami-slice-customise this stuff at all: and, given evident levels of dissatisfaction with the state of the market in this space, no reason why collective bargaining power shouldn’t be rigorously applied by DHLUC to standardise and commoditise it. Low value-add.

Fourth, and also in the ‘tight’ part of the model, is a ‘digital layer’ offering accessibility to citizens, as well as plug-in interoperability to digital/emerging tech, both current and future (IoT, machine learning, sentiment analysis, socials, analytics, digital twin, etc). Once again, although citizens do interact with this layer, I suggest that they don’t really care too much about whether it’s formed from standard, shared templates or not, providing it’s good/works. Again, Low value-add (it’s surprising just how much of the sectoral stack is low value-add when you split it out, isn’t it? Just wheel reinvention, unless run tightly). These two, commercially-supplied, layers are shown in grey.

Moving to the ‘loose’ part of the model, we at last have the high value-add: fifth and sixth are constantly-interacting innovation/design/development/ configuration layers, comprising a DHLUC ‘hub’ (‘Local GDS’) enabling/supporting ‘spoke’ digital teams in councils. The hub curates/enforces mandated standards, as well as developing and sharing new products and services on top of these: this is why both are shown in the same colour (yellow). Finally — and perhaps most importantly — digital teams at the ‘front line’ configure and deploy, and sometimes design, products and services developed in the hub into the local context (which are immediately shared with the hub for reuse). For this hub-and-spoke dynamic to be successful there has to be constant and proactive interaction between the two layers: sharing and testing of ideas, publishing backlogs, evolving standards, etc. The considerable savings (over time, hundreds of millions) from ruthlessly standardising/consolidating/commoditising the low value-add layers cross-sector should be pumped into funding these high-value layers, where they can make an immediate difference at the front line.

This is all very well, I hear you say, but why might this model be any more suitable than any other way of modernising the sector? In order to ‘check my working’ therefore, I threw all six layers onto a Wardley Map, shown below. The map can be used to test whether any operating model is throwing time and money at the ‘right’ stuff — ‘right’ being a function a) of how visible it is to customers (do they care? Y axis) and b) whether the stuff is freely available as a product or commodity (in which case, we have no business custom-building it: x axis). You can see that the map appears ‘balanced’, which means that it exhibits a slope from top-left down to bottom-right:

Our top-right to bottom-left slope shows that collectively our tight-loose operating model is spending bandwidth and money where it matters: starting with the top two layers, we are innovating (‘Genesis’) and bespoking (‘Custom’: both x axis) stuff that customers see and care about (y axis), where no readily-available product/service already exists (x axis). Turning to the grey digital and LOB layers, we are not reinventing the wheel building stuff that customers care less about (y axis) and for which COTS stuff is freely available (x axis). Importantly the map also shows DHLUC what its role over time should be in this area: to use collective bargaining power to shift both grey COTS layers further to the right of the map from ‘product’ into ‘commodity’ (x axis) - standardising, commoditising, and saving resource to spend instead on value-add activities, and further improving interoperability. Finally, customers care even less about enabling common standards and mandated infrastructure (y axis) which in our model are shown as common and highly evolved (commodity: x axis). As a final thought, it is pretty sobering to reflect that a Wardley map of the present collective operating model for the sector might run from bottom-left to top-right (!!) which prompts reflections on how well we are spending our time and money, and our collective priorities, at a time when things have never been worse for our customers.

Of course, the particular tight-loose operating model shown above is not a technical architecture: others with years of working with these technologies are far better-placed than I to look at that, and will doubtless suggest omissions, naivetes and impracticalities at the sharp (delivery) end of all this. That said, if one is convinced that modernising the local government sector for our internet-enabled, digital era is by nature a collective, not atomistic endeavour, then I believe that the collective operating model we need is undoubtedly some version of the ‘tight-loose’ structure above. Rather, the key question for me at least is whether the sector can work urgently, and collaboratively, enough with DHLUC to overcome the collective action problem and fix UK local government before it is too late?