Clocks, clouds, and the nature of digital problems

In a mentoring session last week, I shared an idea that seemed to click - the difference between technical and adaptive problems.

This framing is taken from Ronald Heifetz’s work on adaptive leadership, and it explains a lot about why some digital challenges respond well to expertise and others don’t.

• 'Technical' problems (note: these are not technological problems) are well-defined: the issue is clear, the solution exists, and someone with the right skills can fix it (e.g. "our CRM doesn’t integrate with the website"). They’re (generally) easier to identify and lend themselves to 'obvious' solutions.
• Adaptive problems are messy: they involve people, habits, and culture. The problem itself is often fuzzy, and progress depends on learning and alignment rather than implementation (e.g. "we don’t use our CRM because no one trusts the data or sees the value"). These are harder to identify, often denied, and need exploration, engagement, and experimentation.

Consider these examples:

• Patients not taking their prescribed medication (technical) vs patients not believing treatment will help them (adaptive)
• A CRM that can't generate the reports we need (technical) vs a team that doesn't trust the data being entered (adaptive)
• The website is slow (technical) vs stakeholders can't agree on what success looks like (adaptive)
• The integration failed (technical) vs teams work in silos and won't share information (adaptive)

A couple of years ago, I wrote about the difference between fast change and slow change in digital projects - the visible stuff (new websites, system implementations, rebrands) versus the intangible work around culture, mindsets, and behaviors.

Looking back, I realise I was circling around the same idea from a different angle. Technical and adaptive problems are just another way of making that same distinction - fast change is often concerned with solving technical problems with clear solutions, while slow change addresses adaptive problems involving people, habits, and culture.

The workshop question that I mentioned in that article, ("if you had a new website tomorrow, what would you have to do to stop your current website issues reappearing?"), nearly always surfaces adaptive problems like collaboration between teams, feedback loops, leadership buy-in, shared priorities. All the stuff that no new website will ever solve alone.

The technical/adaptive framing helps me be more precise about why slow change matters and what we're actually trying to address. It's not just that culture takes time - it's that we're dealing with fundamentally different types of problems that require fundamentally different approaches.

The real danger is misdiagnosis i.e. treating an adaptive challenge as if it requires a technical solution. That’s when we buy new tools or reorganise teams to solve it yet the same issues resurface.

It’s a pattern that echoes philosopher Karl Popper’s metaphor of clocks and clouds. You can’t fix a cloud by tightening its bolts and you can’t solve adaptive problems with technical fixes.

If you're not sure what you're dealing with, ask yourself questions like:

1. Is the problem clearly defined or do people describe it differently?
2. Could an expert reasonably 'solve' it or does it rely on people changing how they think or work?
3. Have we seen the same issue return after a technical fix?
4. Does progress depend on trust, buy-in, or shared understanding?

Most digital work sits somewhere between clocks and clouds, but noticing which parts are which will change how you approach the work. It might shift the question from 'what tool do we need?' to 'what needs to change in how we work?'.

As designer Christopher Butler recently wrote, tools now make it easier than ever to "produce something that feels designed" without any real design actually happening. The same is now true of so much digital work - execution has become easier, but the adaptive aspects of this work - understanding, clarifying, framing, building trust, reaching agreement - haven’t become any simpler and still takes time.