There is a particular kind of executive confidence that appears in technology organisations. It usually sounds like this: “I don’t need to understand the tech. I manage outcomes.” It is normally followed by a transformation programme, several reorganisations, collapsing morale, and a very expensive consultancy engagement that promises clarity and delivers polished slideware.
Let’s be direct. Managing technologists without understanding technology is not a neutral handicap; it is an active risk multiplier. The more complex the environment, the more damaging the ignorance becomes.
So here is the guide you asked for.
1. Start by Accepting You Are Blind
If you do not understand software architecture, distributed systems, infrastructure, security models, delivery pipelines, data structures, and operational constraints, then you are blind to the shape of the terrain. You cannot properly see tradeoffs, shortcuts, fragility, or when someone is bluffing. Technology is not like sales or marketing where outcomes are often decoupled from deep domain mechanics. In technology, the mechanics are the outcome. Architecture decisions made in a whiteboard session today will determine scalability, cost, resilience, and regulatory exposure five years from now.
If you do not understand that dynamic, you are not steering the organisation. You are sitting in the passenger seat while pretending to hold a wheel.
2. Stop Pretending Delivery Is Just Project Management
Non technical leaders often default to process pageantry because it is visible and legible. They add more standups, more dashboards, more governance forums, and more colour coded status reports in the belief that visibility equals control. None of these artefacts fix poor architecture, reduce technical debt, compensate for a misaligned data model, or create good engineers.
When you cannot evaluate technical quality directly, you over index on visible artefacts. Documentation begins to look like competence and velocity charts start to look like value, while entropy compounds quietly underneath the surface. The system appears orderly right up until it fails.
3. You Will Optimise for the Wrong Things
If you do not understand technology, you will optimise for what you can easily measure. Feature count, story points, headcount, burn rate, vendor promises, and analyst positioning become proxies for progress because they are tangible and easy to present upward.
Technologists, however, optimise for variables that are less visible but far more consequential: latency, throughput, failure domains, blast radius, observability, coupling, and long term maintainability. These variables are not intuitive if you have never built and operated systems, so you unintentionally pressure teams to move in directions that make the system worse while appearing more productive. You celebrate feature velocity while quietly accumulating architectural collapse.
4. You Will Reward Confidence Over Competence
In technical environments, there are engineers who explain complexity cautiously and engineers who promise simplification confidently. If you cannot evaluate the substance behind those positions, you will reward the confidence because it is easier to understand and more comforting to hear. The loud architect who claims “this is easy” will often outrank the quiet engineer who warns that the proposal will create long term fragility.
Over time, bad decisions institutionalise themselves. Real builders leave because their judgement is repeatedly overruled by narrative. Political performers remain because they are aligned with what leadership can recognise. The technical centre of gravity shifts from engineering to performance and display, and once that shift occurs it is extremely difficult to reverse.
5. You Will Build a Human ETL Layer
When leaders cannot understand technology directly, they often attempt to compensate by inserting translation layers. Middle management swells because it feels safer to add interpreters than to build fluency. Technologists are carved into smaller and smaller execution pools, each overseen by coordinators, delivery leads, programme managers, and transformation managers whose primary function is to convert engineering reality into executive friendly language and then back again.
You effectively create a human ETL pipeline. Engineers produce signal. Middle management extracts it, transforms it into multiple narratives, and loads it into reporting decks, governance packs, quarterly reviews, risk registers, and strategy updates. The same underlying data has to be repackaged repeatedly, often at the last minute, into slightly different formats for different audiences who are all looking at the same system from different distances.
A status update becomes a slide. The slide becomes a summary. The summary becomes a dashboard. The dashboard becomes a talking point. Each layer slightly reshapes the original meaning until what returns to the engineers barely resembles what they said.
The result is leadership overhead that can approach one hundred percent of an engineer’s day. There are just enough managers to guarantee standstill, but also just enough structure to produce a compelling and credible explanation for why five minute tasks take months. Every delay has a dependency chain. Every missed delivery has a mitigation narrative. Every slip can be justified by reference to alignment, coordination, or transformation complexity.
The slides sit side by side and appear dense with activity. They say a lot, but they are often internally incoherent. If you push for more detail and start asking simple, concrete questions about how the pieces actually connect, you quickly break through the dry walling in what is effectively a house of cards. The structural weakness becomes visible the moment someone insists on tracing a single initiative from idea to code to production without translation.
Meanwhile, each pool of middle managers attempts to assimilate technologists into increasingly elaborate planning cycles that look sophisticated but are predominantly meaningless in terms of actual system improvement. Roadmaps multiply, initiative names proliferate, and transformation themes evolve quarterly. Engineers spend more time feeding the machinery than building the product.
It is movement without progress, coordination without coherence, and planning without proximity to the underlying system.
6. You Will Reach for Redis
At some point, a performance issue will surface. A page is slow. An API spikes under load. A batch job overruns. Without deep technical understanding, the reflex will be to reach for something additive that sounds modern and powerful. Very often, that something is Redis.
A cache feels like a silver bullet. It is easy to describe, easy to procure, and easy to present as decisive action. Add Redis, cache the responses, and declare the problem solved.
Never do this blindly.
In environments that are already poorly maintained, layered with undocumented hacks and historical shortcuts, adding another cache rarely simplifies anything. It compounds opacity. Someone else almost certainly “solved” a similar problem years ago with an ad hoc cache, a materialised view, a hidden flag, or a brittle optimisation buried deep in the stack. Adding another caching layer on top of that mess does not create clarity; it creates non deterministic behaviour.
Now you have stale data in two places. Now you have cache invalidation logic that nobody fully understands. Now you have outages that are less frequent but far more mysterious. Symptoms disappear under light load and reappear under pressure. Incidents become ghost hunts through layers of state that were never designed to coexist.
In fragile systems, additive architecture is usually the wrong move. Performance issues are often symptoms of poor data models, missing indexes, chatty services, or architectural coupling that should have been addressed at the root. Caching over the top of structural problems is like soundproofing a cracked engine. It may quiet the noise for a while, but the fracture is still there.
I am speaking to you from a future world where mankind was destroyed by Redis caches. It did not happen because Redis is bad technology. It happened because leaders kept layering fixes onto systems they did not understand, mistaking addition for improvement and opacity for sophistication.
7. The HR Performance Management Trap
The most damaging version of non technical leadership emerges when ignorance is combined with rigid HR performance systems. Intellectual property creation and deep engineering work are treated as a sequence of discrete tasks that will conveniently complete at the end of a performance window, as though innovation obeys a payroll calendar. Complex, compounding work is compressed into quarterly objectives with the implicit assumption that architecture matures on schedule and technical debt dissolves when the review cycle closes.
At the same time, teams are asked to pivot every few weeks to “do the right thing.” Strategy shifts, priorities are redefined, and long term coherence is sacrificed to short term narrative alignment. Engineers are told to think strategically and act long term while being redirected repeatedly in response to executive mood or market noise.
The final irony arrives at performance review time. Engineers are asked to produce detailed lists of everything they have been working on because leadership is “not close to the details” and needs to “fight your case.” The people evaluating the work do not understand it deeply, have not remained close enough to observe its nuance, have redirected it multiple times, and now require the engineer to reconstruct a defensible narrative so it can be translated into HR language.
This is not management; it is bureaucratic choreography layered on top of creative work. The predictable outcome is that engineers optimise for what fits the performance template rather than what improves the system. They spend more time packaging work for narrative consumption and less time building coherent architecture. Artefact production replaces intellectual capital creation, and the organisation quietly bleeds capability while believing it has strengthened accountability.
8. Consultants Will Smell You
When leadership cannot interrogate architecture, vendors and consultancies quickly shape the worldview of the organisation. They sell platforms instead of solving problems, roadmaps instead of capability, and integration diagrams that look impressive in a board pack but age badly in production. Large multi year programmes are approved on the basis of presentation craft because decision makers cannot distinguish elegance from illusion.
Once the contract is signed, leverage disappears and complexity increases. The organisation becomes dependent on external interpreters of its own system because it never developed the internal literacy to challenge them.
9. Culture Will Decay
Technologists do not expect their leaders to be the best engineers in the room, but they do expect them to understand what good looks like. When leaders cannot distinguish good from bad engineering, performance management becomes arbitrary. Excellence is not consistently recognised, mediocrity is not corrected, and incentives drift toward visibility rather than substance.
High performers disengage first because they feel unseen and unprotected. Others follow more slowly. What remains is process compliance without technical ambition, where energy is directed toward surviving the system rather than improving it.
10. So What Should You Do?
You have three realistic options.
The first is to learn. You do not need to become a principal engineer, but you do need genuine fluency. That means understanding system design, distributed failure, data models, security primitives, and cloud economics beyond marketing diagrams. It means reading postmortems, studying real outages, reviewing architectural decision records, and sitting in on incident calls to observe how reality behaves under pressure. Fluency transforms the questions you ask, and in technology leadership the quality of your questions is your leverage.
The second option is to install real technical authority. If you cannot or will not build fluency yourself, then place someone with deep operational experience in a position of genuine power. Not a ceremonial CTO, not a slide producing chief architect, and not a politically safe technologist, but someone who has built and operated systems at scale. Give them authority to veto nonsense, protect them from organisational posturing, and actually listen when they speak.
The third option is the most uncomfortable but often the most responsible: do not take the role. If you fundamentally do not respect the craft of engineering or have no intention of understanding it, then leading technologists is not a neutral career move. Technology organisations are compounding systems where small misunderstandings become large liabilities. Leadership ignorance does not remain static; it accumulates.
The honest answer to the question “How do you manage technologists if you do not understand technology?” is simple.
You do not.
Conclusion: Don’t
There is a persistent myth that leadership is domain agnostic, that management skill transfers cleanly across any discipline, and that intelligence combined with frameworks equals competence. This belief collapses under scrutiny. You would not manage surgeons without understanding anatomy, pilots without understanding aviation risk, or nuclear engineers without understanding reactor physics.
Software now runs banks, hospitals, logistics networks, defence systems, and the infrastructure of daily life. Yet organisations routinely install leaders who proudly declare that they are “not technical” as though it were a virtue.
If you do not understand technology and do not intend to learn, the most responsible leadership decision you can make is not to lead technologists.
In conclusion, don’t.