What Is the Business Acumen Gap?
By Gareth Price · Last updated
You are not being fired for your code
In short: The business acumen gap is the distance between what a CTO knows and what they can communicate in the language the business acts on. In Gareth Price’s Applied Alchemy it is the most common reason founding CTOs lose their jobs: not a technical failure but a translation failure, and one that is structural rather than personal.
A Translation Failure, Not a Technical One
Executive adviser Adelina Chalmers named it after years of working with CTOs and their investors: "I realised that there was a business acumen gap between the CTO and the board. This gap became more and more obvious as the company grew."[1]
Chapter 10 traces five ways it shows up:
-
Jargon as a shield. Firmware, microservices and refactoring sprints, presented to a board that hears noise.
-
"Trust me" without a business case. Asking for headcount or time and retreating to authority when pressed.
-
Under-delivery without explanation. Deadlines slip with no warning and no mitigation plan.
-
Losing relevance as the company scales. Board attention moves to sales, and the CTO reads it as marginalisation.
-
The Alpha Geek pattern. Keeping the hardest technical problems for yourself instead of leading.
They are five symptoms of one condition: a technologist in a room that needs a business executive. They also tend to arrive in that order, so the gap is visible long before it is fatal.
Why It Matters
Chalmers’s finding is stark. None of the CTOs she worked with were fired for their technical skills. Seventy percent were fired because they could not communicate with the board and other non-technical leaders, and thirty percent because they were not strategic enough.[2] That is the core argument of the book. What decides whether a startup CTO survives is not their architecture or their code. It is their ability to turn technical reality into business language, and their willingness to act as a business leader.
Example: Nine Board Meetings, Nine Noes
A CTO at a company of about 3,000 people spent nine months asking his board for several million pounds to redesign a product. He had the technical analysis, the risk assessment and the plan. He was refused nine times.[3]
Chalmers saw the problem within three minutes. The slides described firmware, open-source licensing and architectural dependencies. The board was weighing a business risk and had been given no language for it. She helped him reframe the proposal around risk to the business, impact on sales, and impact on customer retention and acquisition. At the next meeting he got every pound he asked for.[3] He had the right answer for nine months. He lacked the translation.
How to Start Closing It This Week
-
Take one proposal you are about to make and answer Chalmers’s three questions: what is the risk if we do not do this, what is the revenue impact if we do, and what does it do to customer retention and acquisition?
-
Ask each executive peer: "What metric are you measuring that engineering can help you improve?"[4]
-
Rewrite your next update in outcomes, not outputs. "We completed 47 story points" becomes "the three features committed for this quarter are at 70%, 50% and 30%."
-
Flag one risk now that you would otherwise mention later. No surprises: a board that knows you surface problems early can absorb bad news.
Business Acumen Gap vs "Soft Skills"
Telling a CTO to "learn business", the book says, is like telling someone to be taller. It names the deficit without the cause. The cause is structural. Jerry Colonna’s coaching firm Reboot points out that the CEO role forces the practice: pitching, board meetings, owning the whole company.[5] The CTO role does not. By Series B the CEO has had hundreds of repetitions and the CTO almost none. And board communication needs a counterparty: an actual board, with actual power, asking actual questions. The CTO who does not seek that practice out will not get it by accident. The gap is about repetition, not talent.
Go deeper: Chapter 10: The Business Acumen Gap, with Chapter 3: The CEO-CTO Relationship and Chapter 9: Measuring What Matters. See also What Are the Four Stages of a Startup CTO? and What Is the Difference Between Rushing and Speed?
Frequently Asked Questions
-
What is the business acumen gap?
The business acumen gap is the distance between a CTO’s technical expertise and their ability to speak the language of the business: risk, revenue, customers and predictability. Applied Alchemy, following executive adviser Adelina Chalmers, treats it as the most common reason founding CTOs lose their jobs. It is structural rather than personal, because the CTO role rarely forces the board practice that the CEO role does.
-
Why do CTOs get fired?
Mostly for communication failures, not technical ones. Adelina Chalmers found that none of the CTOs she worked with were fired for their technical skills: 70% lost their jobs because they could not communicate with the board and other non-technical leaders, and 30% because they were not strategic enough. AKF Partners likewise names business acumen as by far the most common reason technologists raised through the ranks fail.
-
How should a CTO explain a technical project to the board?
Put it through three questions: what is the risk to the business if we do not do this, what is the impact on revenue if we do, and what is the impact on customer retention and acquisition? Speak in outcomes, not outputs, and never let the board hear bad news for the first time in the meeting. A board can absorb a missed deadline; it cannot absorb a surprise.
-
What are the signs a CTO has a business acumen gap?
Five patterns recur: hiding behind jargon, asking the board to trust you without a business case, missing deadlines without warning or a mitigation plan, losing relevance as board attention moves to sales, and the Alpha Geek habit of keeping the hardest technical work for yourself. They tend to arrive in roughly that order, so the gap is visible long before it becomes fatal.
-
Can a technical CTO learn business acumen?
Yes, but through deliberate practice rather than osmosis. The CEO gets hundreds of repetitions pitching investors and running board meetings; the CTO gets almost none unless they go looking. Start by asking each executive peer which metric engineering could help them improve, and by rewriting every engineering update in terms of business outcomes.