Boogeyman Problems
Sometimes the scariest challenges are the most important.
I started my tech career in the early 2000’s, and there was a period of several years (from ~2008 onward) where I can imagine a lot of conversations at companies that went like this:
Person A: “Hey, have you looked at Google Analytics recently?”
Person B: “No, why?”
A: “The website is starting to see some traffic from phones.”
B: “Huh. Interesting.”
A: “Yeah.”
Time goes by
A: “Hey, have you looked at Google Analytics recently?”
B: “No?”
A: “Our mobile web traffic grew 150% last year. One out of every five people who visit the site are visiting on a phone.”
B: “Woah.”
A: “Our website only really works on a desktop computer.”
B: “Yeah, but that’s always been true. And it’d be a ton of work to make things work on a phone and we’re all pretty busy.”
A: “Yeah.”
More time goes by
A: “Uh, based on the charts in Google Analytics last month, more people visited our website on a mobile phone than on a desktop computer.”
B: “But our site only works on a desktop computer.”
A: “Yeah.”
B: “Oh crap.”
Everyone saw the rise of the mobile web, and some companies did something about it and some didn’t. It’s important to remember that “sites should work on phones” was not a foregone conclusion at that point by any means. Concepts like Responsive Design and Mobile First were bleeding edge at the time and required major changes to design philosophies, engineering capabilities and workflows that spanned years.
Mobile web was a Boogeyman Problem.
There’s a special class of problems that I call “Boogeyman Problems”.
Boogeyman Problems are features or enhancements to products or infrastructure that fit two criteria:
- There’s overwhelmingly clear evidence/validation on their long-term importance and impact to the team/organization/industry.
- Their cost of implementation is massive. I’ll qualify “massive” as daunting refactors to critical paths, very unclear boundaries around scope, and reassignments of team priorities over months or years.
They’re named “Boogeyman Problems” because, frankly, they’re really scary.
Another common characteristic of Boogeyman Problems is they are paradoxically easy to ignore. Some of that is prudent pragmatism: until the work is defined enough to be actionable it doesn’t make sense to stop working on everything else. And there are always existing fires to fight and products to support.
The danger is when Boogeyman Problems are ignored for years. It is easy for momentary “prudent pragmatism” to become “imprudent avoidance,” especially when you are so busy with your day to day responsibilities that it’s easy to let things that aren’t immediately in front of your face slip. I’ll go out on a short limb and claim that most leaders are spread thin, so the opportunity cost for planning around a massively important yet poorly defined problem is very high when you’re putting out day-to-day fires.
But this is not a good excuse.
At any scope of responsibility you cannot continue to avoid your most important problems because you are too busy. The hardest and most important strategic responsibility of leaders is to set priority, and that priority must dictate your busyness. In fact, if you never make progress on the Boogeyman Problems facing your team/organization then I’d argue that you’re not making actual progress at all.
I don’t have a pithy solution here other than vigilance. Cut scope enough to generate actionable milestones. Schedule periodic calendar invites with a few relevant stakeholders to ensure the problem isn’t being ignored. Host Questionstorms. Continue to compile evidence from the business that validate the existence of the Boogeyman Problem and use that validation to justify staffing. And most importantly: don’t give up. Start somewhere, even if it’s uncomfortable. Slow progress on a hard problem is still progress, and infinitely better than ignoring something because you don’t know where to start.
You must fight the normalization of deviance of “we’re going to think about that problem later”, especially if that was the same answer one/two/many years ago. Your success depends on it.