Bringing an Axe to a Knife Fight
There’s a lot of tweets and maybe even more LinkedIn posts that feature wise quotes from famous historical figures. Sometimes taken out of context, often misattributed, and usually mangled. I’m oddly fascinated by the phenomenon.
For example, here’s one I saw the other day. “Give me six hours to chop down a tree and I will spend the first four sharpening the axe” – Abraham Lincoln. I have a bit of an axe to grind with this particular quote. It’s been attributed to Lincoln, in what’s known as “an appeal to authority” to give it more weight; because he never wrote it. And I don’t know if you’ve ever tried to sharpen an axe, but the only way you’d spend four hours doing that is if you started with a hammer. Finally, chopping down a tree with a super sharp axe would usually take minutes; two hours is really slow. To a lumberjack, none of it makes sense.
But I’m still going to use this quote because while it may not apply to Lincoln or chopping down trees, it’s really useful in DX. Because if you take a blunt axe approach, you won’t get very far.
Tripping over shoelaces
If you’re up against a deadline and want to get to results as fast as possible, stopping to think things through is counterintuitive. But I can throw another bucket full of analogies, metaphors, and similes at you. The runner who trips over their untied shoelaces. Or then starts running, but where to? It’s easy to get lost if you don’t know where the finish line is. I must have used dozens of variants of these over my career. But then Lincoln summed it up nicely; sharpen that axe first.
It’s easy to mistake this for inertia. Over the years, I’ve had to do a lot of cultural translation. I remember being on a call about a blocking issue with a team in Jordan and a team in Norway. The Norwegians were cool as cucumbers, while the Jordanians were stressing out, “don’t they understand how urgent this is!” I had to explain that if you’d put the Scandinavians on a volcano, and point out that it’s erupting, you’d get the same response: “Yes. That’s a problem.” That’s not a lack of sense of urgency, they just don’t see the point in panicking. Analyze the problem, find a solution, execute. It’s faster than running around screaming.
Likewise, on occasion, I have been accused of “sitting around planning” instead of taking off immediately. There can be a lot of pressure to jump right in and get going. But you have to strike a balance between the opposite ends of “just do it, we’ll figure it out as we go along” and “let’s form committees and think this over theoretically for a while.” If we’d follow Abe Lincoln’s timelines, we’d spend twice as much time thinking things through as actually executing. For digital experience projects, that would be excessive, and an inexcusable waste of time. But that doesn’t mean you should skip it.
Of course, over my career, plenty of my projects have missed deadlines or ran much slower than they should have. It’s usually not because people were sitting around doing nothing. Most of the time, it’s one of these reasons:
Not knowing what the exact goal is
Ignoring dependencies outside of the project scope
Over-optimistically planning backward from the deadline
Every time any of these happened I felt it nagging in the back of my head, and I could see the red flags in the corners of my eyes. If you’re managing digital experience, you’re expected to be decisive. That means taking some risks – but they have to be calculated risks. You don’t run a marathon at night and then put on sunglasses because it looks cool. And then run into a tree you didn’t know was in the way.
A Guide to Speed For Digital Leaders | By Adriaan Bloem
In this guide, Adriaan has packed decades of hard-earned experience in how to wrangle DX in a large organization — and make it move fast.
Not knowing the goal
Of course you should know what you’re trying to achieve; that seems to state the obvious. In reality, though, you may have to take a few steps back to figure out where you’re really going. I’ve seen major projects where everyone started running, only to start slowing to a crawl later on… yes, you’re building a service or an app, and you have a good idea of what it’s supposed to do. But why? To be honest, this remains the number one drag on projects.
The “five whys” method (popular, for instance, in Six Sigma) is generally used to diagnose root causes of problems. But it’s also incredibly useful to figure out the purpose. If you don’t ask the questions at the beginning, you may find yourself in the woods at the end. It should be a short exercise – don’t use it as an excuse to delay. But even if what you’re working on is just a cog, you should really understand how it fits into the larger machine.
Since you can only influence what’s under your control, it’s easy to ignore what’s outside of project scope. You can’t change it anyway. However tempting, you should always account for risks and possible mitigation.
I once worked at a company where a wireless spot beam to another location was installed in autumn. A few months later, it started inexplicably dropping intermittently; and by spring, we lost it completely. As it turned out, there was a tree in the line of sight, and it had grown back its leaves, blocking the connection. The vendor refused to take responsibility – “nobody told us we’d have to take seasons into account!” We quickly replaced it with an underground leased line, but yes, sometimes you have to account for spring – even though you can’t change the weather.
Of course, that’s just an example – practically speaking, replace “seasons” with, for instance, market conditions, other departments, external partners, and so on. Don’t overdo it; you don’t have to predict the weather. Just look out of the window to see what it is you think is coming.
The immutable deadline is a big one. In this case, everybody is well aware that trouble is brewing – but you have no choice but to try and make it. It might be a contractual obligation with an external partner; it could just be the seasons – or Black Friday, Christmas, Diwali. At any rate, things just need to launch before that, and there’s very little you can do about it. So you start from the finish line and walk back to make things fit. It may work, but often – despite sleepless nights and round-the-clock effort – it won’t.
There are two things you can do with this, and they’re both about risk mitigation:
Highlight the impossible rather than silently try to achieve it. If anything, it can rally the teams around climbing Mount Everest; instead of sinking into the abyss along the way. And everyone will go in eyes wide open.
Realistically plan the project forward. Then reverse plan it against a deadline. You’ll have to drop safety and margins along the way, but you’ll know exactly where the danger lies.
Meanwhile, watch out for what’s probably the highest risk of all here; losing track of all the seemingly non-urgent things you’ll get to eventually, once you’ve made the next big deadline. Or, to confuse Greek classics with Scrum: it’s when your epics turn into ten-year journeys.
Read more from Adriaan Bloem
This guest blog post is the third of a series of five articles, written for Magnolia by Adriaan Bloem:
Oh, and a sweet surprise for you: Adriaan is not only writing blog articles for you, he also wrote a book: