Currently the plan to make government more efficient seems to be simply “deploying AI at scale” with little visible consideration for the environment AI is being deployed into.
Since all government departments have implemented those models the internal worlds are eerily similar across all departments. We can use that similarity to give a sense of the environment and the broad strokes of a problem that I’ll call the efficiency gap.
The ITSM model (which I’ve described previously as the IT paradigm) assumes software is bought rather than built. This means that in the government programmers are extremely rare.
The inability to to create software creates a capability gap (lack of custom/mission-specific software) and an integration gap (an inability to integrate the commercial software you buy to get value out of it; Shopify’s development and use of Slack bots is an example).
The inability to capture/automate government process in software or have automated workflows that span the governments commercial systems creates the efficiency gap; too much manual work, and huge amounts of time spent copying data between spreadsheets and internal systems.
The result is that government processes scale by adding people (examples: the immigration backlog, passports) instead of consuming more CPU cycles.
On it’s face it looks like filling in the capability and integration gaps with some generated applications and APIs, will close the efficiency gap. AI is great at that! Let’s get started!
Love the enthusiasm, but this has been done before.
Digital Transformation: A cautionary tale
The Canadian Digital Service faced exactly those gaps when it launched in 2017. Founded to fix a digital landscape with few digital services of generally poor quality, we jumped into action building the missing apps.
Looking back, we fell for survivorship bias: Once a few of our apps joined the silent graveyard, the actual problem came into view. What needed fixing was the policy and process that was making digital service delivery nearly impossible. A startup would have pivoted, but CDS was never really able… the problems they discovered were firmly in the mandate of other departments.
The effort to “deploy AI at scale” is going to hit the same problems.
The top-down problem
While consequences like “inefficiency” are visible from the 30,000 foot view of the executive, the causes are not.
The implication is executives looking down at an efficiency problem and ordering folks to “deploy AI at scale”, might be “directionally correct” but falls into the same survivorship bias problem of attacking the consequence and not the cause.
Top-down change efforts are extremely susceptible to being fooled by survivorship bias.
An honest exploration of that question is going to lead to places that aren’t even technology, let alone AI: HR, culture (itself an effect and not a cause), policy, process, procurement.
Digital AI transformation
While I love the “damn the torpedoes, full speed ahead” energy that AI psychosis seems to give, I don’t see why the government should expect to have more success with something as complex, expensive and notoriously insecure as AI, when it struggled to deploy far simpler technologies.
Since intelligence is not the main bottleneck in many areas, and certainly not in government, I think there are far simpler and more impactful (in terms of efficiency) interventions to be made, like proper organizational design (1, 2), requiring departments to create technical career paths (a uni-lingual technical path from IT-01 to IT-05; read more here) and taking a scalpel (not a chainsaw) to the policy suite and governance structures (read more here).
If some of that more meaningful work gets done as part of an AI transformation push, I’m ok with some wasted tokens along the way.
The Canadian Government, despite some earnest attempts at Digital Transformation, feels stuck in a rut.
It’s my feeling that the root cause of that rut is there has been a paradigm shift that slid past unnoticed and the Government of Canada is now stuck because of it.
The two paradigms
There seems to be two basic paradigms for how organizations relate to technology each with a distinct org chart that implements that paradigm. While these are a bit of a caricature, they illustrate the idea.
The IT paradigm
The IT paradigm is focused on Information Technology Service Management (ITSM). It relies on cheap labor, expensive software, and manual workflows. In this model, IT revolves around a “help-desk” function where work is managed through tickets and “clicking next” on installation wizards.
Software in this paradigm is procured rather than built (the common mantra is “buy before build“), making cost control an organizational preoccupation, and adding a procurement process to every initiative.
This paints a picture of a technology organization whose constituent parts (beyond a procurement group) are (roughly) a desktop team, a server team (to install the purchased software), the network team (so the desktops can talk to the servers), and a help-desk team to tie it all together.
This approach makes the work of “IT” largely about the simpler acts of administering that procured software and supporting departmental users, and the design of the org chart reflects that conceptualization.
The hands-on-keyboard technical work (white) is done by large numbers of people at the lowest rungs of the IT pay-scale (IT-01/02); they’re answering phone calls, manually adding new firewall rules, assigning software licenses, clicking new users into existence and closing help-desk tickets.
Implementing the IT paradigm: Technical work (white) is done at lowest rungs of the IT pay scale. IT-03 and above are all supervisory positions reducing technical work to a stepping stone.
With IT-01 and IT-02 positions given to people directly after graduation from school, and a rapid transition to management, the org chart demonstrates a view of technical work as a stepping stone to management rather than a career.
The technical depth of such an organization is essentially the time it takes to move from IT-01 to IT-03.
The engineering paradigm
Engineering organizations are almost the opposite: It uses expensive labour and free software to automate work. In this paradigm engineers create custom software using open-source tools so that entire workflows are not just automated, but automatic. In this model a single Full Time Employees (FTE) can automate away multiple FTEs worth of work.
IT-01s and 02s aren’t doing manual grunt work in this model; they write code and are surrounded by enough seniors to get the mentoring needed to become senior themselves.
Implementing the Engineering paradigm: Technical work (white) is a career path going all the way up to IT-05. The organization tilts towards senior to ensure quality and good mentoring for juniors.
Shopifys ChatOps, is a great example of this paradigm; They’ve replaced many things that previously required help-desk tickets with a Slackbot in a designated channel.
While the IT paradigm scales by “throwing bodies at the problem“, the Engineering paradigm makes workflows disappear into applications and automation so that spikes in demand simply consume more CPU cycles.
The shift: Microsoft refocuses from IT to engineering
With those paradigms established, it’s possible to understand the shift:
In early 2000s, Microsoft sold a vision of the IT paradigm: all your organization needs is shrink-wrapped, one-size-fits-all software. They encouraged organizations to think of IT departments as a commoditized labor force whose only job was buying licenses and clicking on installation wizards.
But by the mid 2000s, the economic reality of tech shifted: For Microsoft renting access to software, infrastructure as “services” was far more lucrative than selling perpetual licenses.
This changed the labor equation entirely. Microsoft no longer wanted to be in the race-to-the-bottom market of cheap help-desk labor; they were now courting highly skilled engineers— captured in the (in)famous “developers, developers, developers” chant — to get them building high value systems on top of Azure’s cloud infrastructure: They were now pitching the Engineering paradigm.
The Corporate IT organizations who been built up around the IT paradigm, didn’t have “developers, developers, developers” and were unable to make the transition.
In an ironic twist, when Azure was bundled into existing enterprise licensing agreements, control of these new Engineering paradigm cloud services defaulted to the old IT paradigm groups that Microsoft had just pivoted away from.
Why we’re stuck: Cloud capture
This is the basic shape of the government’s IT problem; the tools needed for digital transformation are captured; locked away in a group that, by construction is not equipped to make effective use of them. The result: We’re stuck.
With industry on right side of this shift that means the industry “best practices” flowing downstream to the Government are all coming from the engineering paradigm (Zero Trust, devops, microservices, container orchestration, and Data Mesh, MLops, agentic AI). These practices are unimplementable by IT paradigm organizations (inside and outside government), leading to calls for everything from from re-invention to dissolution.
TBS themselves doesn’t seem to understand this dynamic. TBS has been steadily adding “best practices” into their policy (all from the engineering paradigm), and then seem mystified when it doesn’t work; in 2017 they flatly ordered departments to run applications in containers and build microservices as part of a big modernization push. Nothing happened.
Even when IT paradigm organizations can be forced to participate in these engineering paradigm best practices, things don’t turn out right; Corporate IT builds an “enterprise non-cloud” that systematically cancels out the clouds core value proposition, does a “lift and shift” of their workloads (which TBS then has to tell people not to do) and then dutifully creates a DevOps team (a well-known anti-pattern) which then goes on a procurement spree (Jfrog! Trivy! Cloudbees!) instead of using the cloud services they already have access to, while teams spin endlessly in the oval of enterprise sadness.
When teams elsewhere in the organization try to directly access the cloud tools Corporate IT controls, they can’t, or are only given a gimped version of them.
What now?
The argument here is essentially that the inability to recognize the paradigm you’re in makes you a prisoner of it. Being able to clearly think and talk about these paradigms is a big part of being able to solve the problem.
In general, the Government of Canada needs to realize the IT paradigm can’t get them where they need to go; We need to end the IT paradigm monopoly and invest in some engineering capacity.
Every one of these product teams represents something being pulled out of the IT paradigm and placed into the Engineering paradigm.
Another interesting possibility is to resolve the “cloud capture” problem the way Google has; by placing an engineering team in charge of cloud. Google has pioneered this as a concept they call SRE, and actually says the quiet part out loud:
SRE is fundamentally doing work that has historically been done by an operations team, but using engineers with software expertise, and banking on the fact that these engineers are inherently both predisposed to, and have the ability to, design and implement automation with software to replace human labor.
Both of these approaches would require some senior engineering talent to succeed, which loops us right back to the utility of being able to see and explain these paradigms; hiring senior technical positions is almost impossible because Human Resources staff across departments are enforcing bilingualism requirements on IT-03 and IT-04 positions based on the assumptions of the IT paradigm: only junior staff do technical work, and IT-03 and up is management.
Once again, the inability to recognize the paradigm makes you a prisoner.
