Essay · 18 August 2026 · 6 min

The design conditions under which technology strengthens human capability

Adoption is not a training problem that appears at the end of a project. It is a design decision made at the beginning — or not made at all.

By Engracia Sleeswijk — AI & Digital Transformation Strategist

Most transformation programmes are designed as if capability arrives on its own. The system is specified, procured, configured and delivered, and somewhere near the end a line appears in the plan called training. By then the important decisions have already been made: who is allowed to change what, where the knowledge lives, and whether the organization can operate the system without the people who built it.

That is why I keep returning to one question in every engagement, whether it concerns a government programme, a curriculum or a small company: under what design conditions does technology strengthen human capability rather than replace it?

Capability is an architectural property

Capability is usually discussed as a human resources topic. In practice it is an architectural one. An interface that hides its logic produces users who cannot reason about outcomes. A process that routes every exception to a specialist produces an organization that never learns to handle exceptions. Architecture decides how much thinking is available to the person doing the work.

The inverse is equally true. Systems that expose their rules, that make state visible, that allow safe reversal of a decision, tend to produce people who understand their own domain better after a year of use than before it. Nothing in the technology changed; the design conditions did.

Four conditions worth designing for

First, ownership: someone inside the organization must be able to change the system without permission from its builder. Second, legibility: the rules a system applies must be readable by the people held responsible for them. Third, reversibility: capability grows where mistakes are survivable, and stalls where they are not. Fourth, sequence: capability is built before dependency is created, not after.

None of this is expensive. It is mostly a matter of deciding it early, while the architecture is still soft.

Why this is one specialism, not several

Working across government, education and entrepreneurship looks like three fields. It is one. A ministry, a school and a founder with two laptops all fail in the same way — infrastructure without adoption, AI without capability, transformation without ownership — and they succeed under the same conditions. The scale changes. The design question does not.