Why most Tech Strategies fail
Avoid these common mistakes if you want to create leverage in your organization and drive it to success.
The day this article comes out, I'll have an exciting deep dive live session with all the Sudo Make Me a CTO Community members focused on tech strategy.
I've seen CTOs and other engineering leaders struggle with this topic in multiple ways. Some completely ignore it, oblivious to the need for such a tool to effectively steer an engineering organization, while others overdo it and come up with strategies only they can understand.
The session will cover all aspects of building and operating an effective Tech Strategy. Today's article, though, focuses on a specific aspect: the most common failure patterns I've directly observed or learned about from others.
Before we explore the topic, let's first take a few seconds to mention another problem CTOs and engineering leaders often face: IT onboarding and offboarding for employees!
Are you tired of the headaches caused by managing device provisioning and deprovisioning? Not to mention having to do that with a remote team!
The good news is that you can change that with Rayda, today's sponsor.
Rayda helps IT teams simplify the entire process of procuring, configuring, shipping, and retrieving devices for remote teams. Now available in 170 countries. Learn more about Rayda at rayda.co, and help support the newsletter!
Finally, if you want to get access to the recording and material from the live session, check the details at the bottom of the article. We're always happy to welcome new members to the community.
So, why do tech strategies often fail? There are a few common reasons.
They often manifest combined, but we'll explore them individually.
It Is Too Generic
This is probably the pitfall I've encountered most often, including in my own doing. Over time, I've developed a simple yet effective Litmus test for it. Take your tech strategy, read it out loud, and ask yourself the following questions:
Does it sound like it could apply to many other companies in your industry?
Would it apply even for companies outside your industry?
Is it applicable to companies of very different sizes and organisational structures?
If the answer to most questions is yes, then chances are your strategy is falling for the generic trap.
You want to enable decision-making at scale and ensure people in your organisation will move in the right direction. A generic strategy won't give you that, as most actions will be somewhat compatible with it. Your teams and you will live with the illusion of following a clear path, while in reality, you'll be flying blind.
Following common sense and collective wisdom might spare you some obvious mistakes, but they won't necessarily make you successful. In other words, even though this approach might already be a step up for some teams, aiming for average results is unlikely to pay off in the long term, and that's what you get when your strategy is too generic.
This is why I believe most recent declarations of companies becoming AI-first are hyped-up garbage. They all read the same, there is nothing in there that's specific to the company's needs, products, and users, and they have such silver-bullet traits that remind me of Google's SREs’ original motto: hope is not a strategy.
You're Cargo Culting Your Strategy
I remember being introduced to the concept of Cargo Cult as it applies to technology decisions by a couple of competent software architects I collaborated with about a decade ago. Wikipedia defines Cargo cult programming as follows:
Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution.1
While the original definition focuses on the programming practice, it can be extended to broader aspects of decision-making in technology. In fact, when I was first introduced to it, we were discussing the madness of companies embracing complex microservice architectures and patterns just because Amazon and Netflix seemed to do the same.
I recently learned from Baldur Bjarnason that technology is a pop culture2. As such, it is very prone to cargo culting. Some call it hype-driven development, and everybody who has spent at least a few weeks in the industry will have experienced it in one form or another. The pervasiveness of this phenomenon is what makes it insidious: it's difficult to escape it.
That's why I've seen plenty of Cargo Cult in tech strategies: decisions that are pushed without fully understanding them, just based on the premise that if company X, big tech Y, or influential CEO Z said they're doing it, you should definitely do the same.
Cargo culting is often compounded by FOMO and disproportionate hype cycles: Web 2.0, Big Data, Blockchain, Microservices, you name it3.
This doesn't mean you should completely ignore and disregard what's going on in the industry around you. That would be as silly. But you should only bring the elements that you've diligently validated as relevant, applicable, and affordable for the organisation you're leading.
To avoid that, you should start your work by establishing a clear diagnosis.
Missing a Thorough Diagnosis
In his latest book, The Engineering Executive Primer4, Will Larson writes: Don't skip writing the diagnosis, even if it's very tempting to do so. He then explains as follows:
By the time you start writing a strategy, you've often settled on a handful of guiding policies that you want to adopt. Maybe you're convinced that you should cancel your in-flight migration to microservices. A word of caution: don't back into your diagnosis. If you don't start with your diagnosis, you can't evaluate whether a solution is appropriate.[…]
I fully agree with Larson on this one.
Confirmation bias is one of the most common biases in our industry, making it easy for someone to start from the active part of the strategy, the things you and your team are going to do, and only then retrofit the diagnosis to match and support the narrative you wanted to promote. Leaders who operate this way often start with an idea of what they want to do, for whatever reason, and then look for ways to answer the question: How can I justify it in a credible way?
Don't do that, unless you want your strategy to fail spectacularly.
Instead, make sure you do a thorough initial analysis of the current situation, including feedback and perspectives from a varied set of people: managers and senior ICs in your organisation, peers, other departments, etc. Do this as if you were an external journalist writing a piece on the state of technology in your company, accepting whatever the findings will be.
You might discover that the fancy tech you were dying to introduce won't help the company in any meaningful way, and you should treat that as a blessed gift. A gift that will allow you to produce a meaningful strategy for your company, and avoid falling into the solution in search of a problem anti-pattern.
Solution in Search of a Problem
Similar to you are cargo culting your strategy, and often correlated with missing a thorough diagnosis, the solution in search of a problem pitfall closes the trilogy on doing the wrong thing because it sounds right. Or, to use an expression that seems to have permeated every recess of this industry, strategy-related human hallucinations.
Cargo culting involves you copying what other companies are doing without understanding why they're doing it. In this case, instead, you're trying to push a certain solution because of some personal preferences, beliefs, or experience.
This includes doing exactly the same or something very similar to what you've done at your previous company, a mistake executives tend to make more often than they should. This issue is only exacerbated when the new strategy is pushed in the early days of the person in the new role. Don't be the person walking around with a sink in your hands5.
Another common case is when you are so intrigued and passionate about a new technology — a programming language, a framework, an architectural paradigm, or a third-party solution — that you end up shoehorning it into your strategy no matter what it takes. This gets even worse when a conflict of interest is involved: promoting a solution or service that you or someone close to you is directly involved with.
The best way to avoid this is to start with a thorough diagnosis of the current situation, and involve people who will be willing and able to call your bullshit when you'll inevitably suggest your subjective preferences as solutions to company's problems.
It's Missing Clear Tradeoffs
This one is often related to the It is too generic pitfall. A good strategy cannot reduce itself to introducing new practices, approaches, or investments without being explicit about what you'll do less of or outright stop doing. Even within the problems your strategy aims to address, you can't expect to be able to work on all of them at the same time, with the same resources, and with the same intensity.
When you don't include explicit tradeoffs in your strategy, you might be making it a fancy version of New Year's resolutions: a declaration of intent lacking solid foundations to become a reality.
Principles around resource allocation, prioritization across major initiatives, and the areas you'll accept not to improve must find their way into your tech strategy. Some of these details will have to change over time, but that doesn't mean they shouldn't be included. Quite the opposite: including those specific tradeoffs will require you to review and update your strategy on a regular basis, every six months to one year, to ensure they still make sense.
All those explicit tradeoffs will be your most valuable tool to protect what's really important, drive focus across the org, protect initiatives that have a natural tendency to be deprioritised (security, scalability, data privacy, etc), and fend off the occasional attack from a frustrated stakeholder.
Accessing the full recording
In the article, we've covered the most common cases for tech strategies to fail, but a lot more could be said about the topic. As I mentioned in the intro, on the same date in which this article comes out I'll hold a deep dive session with the members of the Sudo Make Me a CTO Community to discuss tech strategy: how to create one, how to avoid these mistakes, and how to use the strategy to drive execution.
After reading the article, you might be interested in watching the recording of the session, or even joining it live to bring your questions and contributions. You can do that by joining our community today, and get access to the following:
Two 1-hour live sessions every month: a deep dive and a Q&A session
Video recordings and transcripts of all previous sessions
A complimentary 45-minute individual coaching session with me
A private Slack community where you can interact and learn from all the community members
Special perks and benefits
The membership comes with a no-questions-asked 30-day money-back guarantee, which means you could join us today, watch the recordings you're interested in, and ask for a refund if you're not satisfied.
To sign up today, follow this link, and I'll personally reach out to you to guide you through the onboarding process.
See you there!
Notice how I managed to avoid mentioning AI here. I'm making progress.
I read this book recently, and it was the highlight of March/April for my reading selection. I've covered it in this article. If you're too lazy to read my review of it, you can go straight to pick up your copy here.
If you don't get the reference, don't bother, but consider yourself lucky.
Just found you today through a Perplixity search - was looking for facts on CTO/CIO's feelings, motivations, behaviors and your Substack came up. Great work - I'll keep reading! Thank you.