As we move from analog to digital systems of organization, many things change. For example, we can take more risks, because in digital, a backup is free—so we can roll back to a previous version. We don’t have to throw out the print job, we can just refresh the browser.
There’s another fundamental difference we should think more about: Marginal costs. A marginal cost is the cost of increasing something by one.
Imagine an employee who handles inquiries from citizens and residents as part of a government service desk. This employee earns $65,000 a year (roughly middle range) and can handle 100 inquiries a week.
If we want to increase the volume of inquiries supported, we can add a second employee. That means an incremental cost of $65,000 a year. You add capacity in $65,000 chunks (although in reality, you overload the first worker for a while.) The marginal cost of an additional inquiry is flat, and then suddenly it’s $65,000 when you need to add an employee (not to mention their training, overhead, and so on.)
In a physical world, it’s acceptable—perhaps even desirable—for those two humans to differ. To specialize. They might even offer better service because they can specialize in different departments and tasks. Maybe one deals with healthcare questions and another with tax questions. You get economies of skill, where each specializes, and you route inquiries to them accordingly.
Digital systems don’t scale that way. They add capacity incrementally. That’s because while the physical world is expensive, adding digital capacity is virtually free. A digital copy is identical, so doubling the capacity of a digital process doesn’t double its cost.
In a digital world where copies are free, the economics of duplication are fundamentally different. There are huge benefits to everyone using the same system rather than each department being different. Economies of scale matter much more.
It makes far more sense to consolidate on the same building blocks for a service, and to specialize or customize only the department-specific stuff.
- Standardize things like storage, computing, notifications, forms, translation, testing, user interface patterns, stylesheets, frameworks, messaging, and so on. Get them certified once, then make them easy to stick together like lego blocks.
- Customize things like domain expertise, escalation, documentation, recourse, and content. Focus on tailoring the transaction to the user based on what you know about them.
Re-use isn’t just economically sensible. It’s liberating—people know that if they use an approved component, they’ll benefit from all the testing and certification it had to go through. In an era of increased scrutiny and demanding compliance and governance, this removes a huge burden to rapid deployment.
Re-use also means that every time someone improves a building block (say, adding another language to translation, or updating a framework for iOS 16) every digital system that uses that building block gets an upgrade. By comparison, training an employee improves things for just the clients of that employee, not the system as a whole.
The job of a digital service is to be continuously slicing off the bottom of the service stack, finding common elements across departments and regions and replacing them with reliable, standardized components.
This doesn’t mean replacing humans. There’s plenty of work to do, and the more we rely on algorithmic decision-making the more that clients need a path to recourse, support, and the ability to escalate to an actual human. But digital systems can handle the majority of interactions, leaving more time to focus on the marginalized and exceptional cases.
That’s the rationale of digital services that build components such as notification, forms, and design templates: Re-use makes sense, and departments need to relinquish their fiefdoms so the public service can scale to huge ambitions with tiny budgets.