This article is written by Gordon Guthrie. Gordon is a Research Fellow under the First Ministers Digital Fellowship Programme in the Scottish government. He is researching how the state and the political class create digital systems and the services built on them. His research programme publishes on Digital Policy.

  • The problem: The tempo of legislation and the tempo of service delivery in the digital age are out of sync.
  • Why it matters: Government can't iterate as fast as it ought to, and it’s stopping us from delivering government services as quickly, cheaply and effectively as possible.
  • The solution: By studying the institutions and processes of government and parliament closely and restructuring legislation, policy and people and processes, we can deliver better, faster and cheaper with deeper democratic oversight.

This is a tale of two iterative processes.

Primary legislation is passed and tweaked with secondary powers, then amended and reformed and consolidated.

Software design and delivery rolls out in its own loop: build, test, refine, release, measure. Round and round.

It sounds like a marriage made in heaven – until the smashing of crockery starts.

The legislative side of the house has four speeds: in Scotland, the people decide their government every five years in an election. The parliament decides 22 times a year when it passes a bill, 18-24 months in the making. Ministers decide 400 times a year when the lay orders – checked lightly by parliament. Civil servants make innumerable general regulations and decisions, day in and day out.

💬 Let the author know what you think by leaving a comment below

On the other side of the house is a range of technical trades, service designers, organisational designers, techies and testers and they are all trying to drive their iterative cycles as fast as they can.

If these two engines are poorly yoked together, chaos ensues.

How can we connect these engines?

Designing a gearbox to smoothly connect these two engines will be a revolution – and a proper revolution is French and needs a good French slogan: Explicité, Constitutionalité and Simplicité.

Explicité (translation: ‘specific’ or ‘explicit’) is the demand that everyone recognises they are in the business of creating digital systems – our processes have to be explicit. There is no policy or political exception – no throwing things over the wall for the techies – all the pre-coding steps influence, shape and inform the systems. Profoundly.

Constitutionalité (translation: ‘constitutionality’) is the belief that technical delivery must mould to the constitution and not the other way around. There is no road to high-quality state systems without oversight and the separation of powers. Technocrats cannot and should not be given a free hand.

Simplicité (translation: ‘simplicity’) is the realisation that the entanglements that currently tie these two engines together are cumulative. Every entanglement that connects a bill to a delivery programme that is cut, every gap in oversight that is fixed for a single department or service is a valuable improvement. Each thread that binds these engines is weak and simple, it’s the mass of them, the knot, that is both strong and complex. Our challenge is to systematically find and cut them thread by thread.

Three primary problems

There are three main classes of problems:

· speedbumps

· runaway decisions that escape parliamentary oversight

· organisational problems arising from mis-structuring

A speedbump is when a decision is made too high up the decision tree – and hence too slowly. An example would be the old power of attorney law in the UK. To grant someone power of attorney over your affairs the act said you and they had to sign a piece of paper in the presence of two witnesses. Kinda hard to digitise.

The urge to speed up processes has led to the use of shortcuts – skeleton bills and delegated powers which let important decisions slip out from underneath parliamentary oversight and the separation of powers.

Government departments need to be two-faced – one towards the parliamentary process and one towards the operational and delivery function. Too often one side is favoured over the other and things are unbalanced.

So, how do we solve it?

How do we solve this complex problem? First up, chop it up.

Firstly, I am crowd-sourcing a Frankenstein Bill published on GitHub. Sometimes legislation clearly impacts computer systems and services, sometimes obliquely. The Frankenstein Bill, sewn together from different clauses from different acts passed by different parliaments in different languages, aims to be a pattern book, a teaching aid. It will be a resource created by the technical trades to help their upstream colleagues (whether policy people, ministers, special advisers or think tankers and pundits) understand the impact of their actions.

Secondly, I am setting up workshops with technical specialists to write pattern books of their trade. These are the decisions we take. This is the iterative velocity of each of them. Here are the dependencies on decisions taken by our colleagues in other technical streams. And then critically I will add the constitutional options to put them under appropriate oversight.

With these two pattern book, we can start developing a Legislative and Constitutional Architecture.

The Organisational Architecture and Target Operating Model will tell us how our organisation is structured. The Service Catalogue will tell us what it will do. The Business Process Architecture will outline how we will deliver the services. The Technical Architecture will map copper, tin and software to the business processes. Each of these views cross-references and will let us understand how we operate.

The Legislative and Constitutional Architecture is a roadmap in time. In the first year we will pass an act which will make these decisions. In the third year we will have a second act which will decide these things (based on our learning). Underneath these will be this sequence of secondary legislation. Underneath this is a host of regulations delivered in a sequence – some citizen-facing “this is the application process for this…”, and some internal-facing “…a programme board and a data office will be set up by Q4”.

And underlying it will be a sequence of business cases; outline, interim, final state. Plus training plans, and deployment and roll-out plans.

It will be a living document, being published this year, and republished next year and the year after. After all, the purpose of using an iterative approach is to identify defects in our planning or understanding and to correct them as quickly and cheaply as possible.

And critically for each technical task covered in the Legislative and Constitutional Architecture there will be a statement of oversight – an audit function here, a programme board there, a senior responsible officer over there.

So far in my research I have only interviewed people in Scotland, England and France and I have some interviews pencilled in for Norwegians and Canadians.

I am delighted to be working with Apolitical to tap the experience of colleagues in countries across the world.

This is a continuous improvement process and every issue that it tackles has already been solved by a bill team, a policy team or a delivery team, somewhere, often many times – perhaps by you and your team.

Apolitical and I have organised two seminars on Monday 23 October to discuss this topic in more details:

Please mark yourself International/Apolitical when you register.

After those talks you will be able to apply to participate in some of the technical workshops for the various trades in government: techies, service designers, organisation designers, content designers, UX designers, data specialists, testing, usability boffins and all the rest.

My communications with the wider world are via Digital Policy. Do subscribe, get notifications and join the conversation.

Done reading? Make sure to tell the author what you think by leaving a comment below ⬇️

(Image credit: Unsplash)

Make sure to share your own thoughts with the author by leaving a comment below