Wicked problem isn’t Bostonian for ‘not finding parking;’ it’s a phrase coined in 1973 by professors Horst W.J. Ritter and Melvin M. Webber.
They were looking into issues around policy and the design of urban spaces and coined this phrase to describe the types of problems that plague humanity—problems so persistent and difficult that they are wicked in nature.
These issues, such as poverty and crime, are always tough to solve; their nature changes, the context is totally different in one example to the next, and the best a planner or designer can hope for is to minimize or tame these issues, rather than fix them for good. It’s also worth noting that attempts to minimize do not take away from the fact that wicked problems are often fraught with inadvertent consequences.
Many of the challenges organizations undergoing digital transformation are facing could well be categorized as wicked problems. While they’re not dealing with the classic list of problems that face humanity (although governments, charities, and not-for-profits are certainly combining digital issues with human challenges), the digital world has created its own unique set of wicked problems: issues that plague teams no matter the size of the budget.
Whether a small tactical app improvement or wholesale service overhaul, it’s become clear that many organizations are unwittingly hosting conditions that are hostile to success.
What are digital-specific Wicked Problems?
There are four key wicked problems, and while each is a problem on its own, when all four come together, it’s a recipe for catastrophe.
Legacy technology
Legacy technology—whatever’s left in the system from the 90’s or even before—is plaguing businesses that don’t consider themselves startups. These large infrastructure systems from the late 90’s and early 00’s (often out of warranty, no longer supported by the vendors) are monolithic, often written in inflexible languages, and are nearly impossible to untangle from the core functions of the business. Replacing them is a nightmare, and creating new services that have to talk to them isn’t much better.
“Whether a small tactical app improvement or wholesale service overhaul, it’s become clear that many organizations are unwittingly hosting conditions that are hostile to success.”
As Dave Hrycyszyn often says, “Your future is held back by the limitations of your past”. We can’t blame Microsoft, IBM, and Oracle for the fact that we’re still using databases they released in 1993 that aren’t compatible with the demands of now-ubiquitous one-page apps, mobile devices, and cloud technologies. They weren’t fortune tellers!
What is less accepted as legacy tech are the things we’ve bought and built more recently. It’s tough to accept that products we’ve built as part of our new progressive digital culture may be problematic legacy tech for someone else down the line.
One example of how this happens is when we take on projects that don’t deal with the original legacy challenge (an old database, for example), and instead find interesting hacks and workarounds to append new functionality. The non-ideal architecture will need to be carefully documented for future maintenance, and while the hack may suffice for the current release environment, who knows how much more hacking will be needed to fit the next major platform update?
Essentially, we are constantly making new legacy tech challenges while attempting to somehow avoid the catastrophic scenarios of straight-up switching old things off. For every new super fast Agile project, there are bound to be gaps and things missing that will cause someone else a headache further down the line.
Poor digital literacy in business leadership
This one may be controversial, but bear with me—I’m not coming in to blame anyone for anything.
Many established (read “old as time”) businesses are lead by executives whose expertise isn’t digital—which doesn’t change the fact that C-suites and leadership forums are plagued with the language of ‘Disrupt everything’, ‘Go Agile’, ‘Transform or die’, ‘ Be digital first’ etc. etc.
However, the rhetoric being what it is, C-suites are struggling to be sufficiently informed enough to make good decisions. Decisions about budget, timelines, and other things that demand in-depth knowledge of practice are being made by people who aren’t qualified to make those calls.
It’s important to consider how sensitive and perilous business leadership can be. When you have to make decisions about things that aren’t your expertise, your only hope is to have the right inputs and advisors.
When timelines and budgets are unrealistic, when promises are unfounded, when no one can explain endless overruns and missed targets, it often goes back to the leadership missing critical insight with which to make better decisions.
Financial practices
One of the most important things to strive for as a designer is developing a commercial conscience. We need to understand how budgets work, as this will ultimately be the variable on which all decisions are based.
The issue is that the most popular financial practices of recent times, such as best value procurement and zero budgeting, have a disproportionately negative effect on how businesses can execute digital projects. It isn’t the case that good financial practice is at odds with a successful digital culture; it’s that many organizations are looking at digital transformation, but keeping HR, legal, and accounting the same as they’ve always been.
You can’t half-transform. Zero budgeting can mean senior and middle managers are not able to invest long-term, so they do a lot of small tactical projects, ultimately creating waste. And it’s not just in accessing budget where financial practices are having a negative impact: many businesses see IT as a cost. With that kind of attitude towards digital advancement, there’s always going to be a struggle against accounting methods that rely on analog definitions of assets.
Lean and Agile practice
Now this may also be contentious, but it’s important to be honest with ourselves about the limitations any process has. The Lean movement can save time from bloating project timelines and inefficient delivery (probably down to some of the issues addressed above), while Agile development provides a way of pushing ahead fast with a solid set of ceremonies and behaviors that make it easier for us to avoid the bloat.
Both methods ensure that you just don’t have the time to get too far from your goals.
An unintended outcome of this, though, is that all of the focus on start now, launch early, launch often has made people forget about what you might need to do BEFORE you start.
Admittedly, the pain of putting together detailed requirements documents isn’t trivial; still, though, the deep-dive into discussions about processes and system requirements are critical—and definitely worth the time.
Somewhere along the line, we seemed to have forgotten that failing to prepare is preparing to fail.
“There are four key wicked problems, and while each is a problem on its own, when all four come together, it’s a recipe for catastrophe.”
So what can be done?
The nature of wicked problems is that they are continuously evolving and resisting complete resolution, but that doesn’t mean we accept them and sit back.
Like many things, the first step is to see them for what they are. Once you know what you’re dealing with, its then about making a series of affirmations that will guide you as you start to experiment with proper fixes.
Affirmation #1: Idealizing for the end user is only valuable if you can adapt their needs to your production constraints.
It doesn’t matter how grand your ambition is; in fact, the grander the ambition, the more important it is that you think carefully about taking the right first steps and solving the right problems.
Affirmation #2: As a UX professional, it is no longer an option to not be able to talk about code. Start speaking dev talk. Now. It will pay off to learn how to approach and understand these kinds of major tech challenges.
This is not to say all designers should code, but understanding the building process for their designs is a must. Build relationships with the development team and learn how to speak a common language. Take a product manager’s point of view and think about their whole approach, not just the bit for which you’re accountable.
Affirmation #3: There is no blame game available to you. “They” is replaced by “We”. There is no right or wrong, only this way or that way—based on the best understanding WE can achieve.
“They didn’t actually build my design”, “That’s not what we asked for”, “It’s not my fault they didn’t do a good job”. You know designers who say this—or maybe you’re the designer who’s said this.
In a world where constraints evolve, releases are constant and priorities also change regularly, you can’t be precious about your plan or design. Wicked problems may persist, but their nature and associated symptoms change often. We are all invested in doing the best work we can, and the teams that get the most traction on addressing wicked problems are the ones who are most cohesive.
How we create culture
It’s important that as an industry, we think responsibly about how we create better digital transformation cultures. Not just to better serve the all-important end-user, but to also hold our own heads up and say we did the best we could with the tools and information we had.
Lola Oyelayo, a Digital Product Strategist is giving a presentation on solving “Wicked Problems” at Talk UX in Boston on October 18th, 2018. But even if you can’t make the trip to hear her in person, you can still benefit from a primer on the underlying concepts.
Interested in learning more?
Lola specializes in helping businesses and teams navigate the complex world of digital product development. At the moment, she is focused on the emergent practices of design and research around decentralized services.
