There is a peculiar sport played in large organisations. It looks like leadership and sounds like governance, hiding behind frameworks, maturity models, and operating rhythms. But in reality it is something far less noble. It is corporate heckling.

Corporate heckling is what happens when a function narrates from the sidelines with low context and high confidence. It is the art of describing how everyone else should work, without ever carrying the burden of delivering anything meaningful yourself. It is commentary at scale, divorced from the trade offs, constraints, technical debt, regulatory nuance, customer friction, and immovable deadlines that real teams wrestle with every single day, and it achieves nothing.

1. The Sideline Narrator

In every enterprise there are functions that slowly drift from enablement into commentary. They attend steering forums, publish decks, rate “maturity,” explain what good looks like, and diagnose other teams from a safe distance.

The pattern is predictable. They have all the answers. The delivery teams are immature. The architecture is fragmented. The engineers lack discipline. The product managers do not think strategically enough. What is rarely true is that these narrators have taken the time to sit inside those teams and understand why things look the way they do. They have not traced the historical decisions, absorbed the regulatory constraints, sat through production incidents at midnight, or tried to ship a feature under a hard date with incomplete information and an unpredictable dependency. Without context, ideas sound elegant. With context, they often collapse, because heckling is easy and delivery is not.

2. Enterprise Architecture and the Illusion of Superiority

Enterprise architecture is particularly susceptible to this disease.

At its best, architecture creates clarity of domain boundaries, coherent principles, and composable building blocks that make delivery faster and safer. It reduces cognitive load, prevents duplication, and enables teams to move independently without creating chaos. It is an accelerant.

At its worst, it becomes a commentary layer. A slideware practice that declares teams immature while producing nothing that reduces friction. A group that standardises vocabulary but never simplifies reality. A function that critiques design decisions without being present when those decisions were constrained into existence.

If architecture only appears to say no, redraw diagrams, and demand alignment to abstract models, it is heckling. If architects are not embedded in discovery, not present in solution design, and not accountable for operability and performance once the system is live, then they are spectators with strong opinions. Maturity is not declared in a deck. It is built in code, in platforms, in patterns that actually make delivery easier, and it is built by people who carry outcomes rather than narratives.

3. UX/CX Without Skin in the Game

Design is not a handover ceremony. It is not a file labelled “approved” thrown over a wall to developers who are then expected to faithfully reproduce a static imagination inside a living system. If UX is not debating constraints with engineers during build, not tensioning performance against animation, accessibility against layout, or clarity of copy, then it is participating in theatre.

When the shipped experience differs from the prototype, it is rarely because engineers are careless. It is usually because trade offs were made under time, performance, or integration pressure, and if design is not present when those trade offs are made, it forfeits the right to be surprised by the outcome. Teams solve problems every day while constraints shift, dependencies fail, budgets tighten, and deadlines loom. Without skin in the game, without a seat in the room, without a detailed understanding of constraints and trade offs, commentary becomes heckling, and heckling improves nothing.

But there is a more damaging pattern than simply being absent. It is the pattern of swooping in after the fact, armed with a single anecdote, and redirecting an entire engineering team away from work that actually matters.

Picture this. A team is three weeks into resolving a critical payment processing defect affecting tens of thousands of transactions daily. The fix is complex, the root cause is buried deep in an integration layer, and the engineers are making real progress. Then a screenshot lands in a Slack channel. A CX function has spotted that a button label on a low traffic screen reads “Confirm” instead of “Submit.” Someone’s cousin noticed it. A director mentioned it in passing. Suddenly there is a deck, a meeting invite, and an escalation. The heckling function has found its moment. It has something visible, something it can point to, something that proves it is watching.

Within forty eight hours, two senior engineers are pulled off the payment defect to address the button. The fix takes four hours. The showcase takes longer. The payment defect, now understaffed, slips another sprint. The downstream consequences of that delay; the failed reconciliations, the customer complaints, the operational overhead will never be attributed to the button. They will be attributed to the engineering team’s velocity. This highlights the classic managerial anti-pattern: authority without responsibility. The heckler wielded enough influence to redirect the room, but will bear none of the accountability for what slipped as a result.

This is how heckling destroys value invisibly. The lost time on critical issues is an unseen consequence. The heckler never sees it because they were never close enough to understand what was being worked on in the first place.

What makes CX and UX heckling particularly insidious is its almost total absence of data. It does not arrive with conversion metrics, drop off rates, session recordings, accessibility audit scores, or usability test results. It arrives as general anxiety. Vague concerns about the “feel” of the experience. Assertions that something “doesn’t look right” or “isn’t what we agreed.” It is almost always singular and anecdotal. a complaint from one customer, an observation from one stakeholder, a personal preference dressed as a design principle.

And it never acknowledges what went well. The onboarding flow that reduced friction by thirty percent goes unremarked. The form redesign that halved completion time receives no comment. The accessibility improvements that passed external audit attract no praise. Heckling functions are structurally incapable of celebrating progress because celebration does not justify their existence. Their value proposition depends on finding problems, which means problems must always be found, regardless of whether they are the most important ones.

The result is a team that learns to manage the heckler rather than solve the real problems. Engineers start anticipating the screenshot. Product managers start pre emptively polishing low traffic screens to avoid the distraction. The entire team optimises for the optics of the experience rather than the outcomes of the product. Visible cosmetic quality becomes a shield against interference, and invisible systemic quality, the kind that prevents outages, protects data, and scales under load, gets quietly deprioritised because no one is heckling about it.

Real CX and UX influence looks nothing like this. It looks like embedded designers who sit in sprint reviews and absorb constraints as they emerge. It looks like research that quantifies the actual impact of experience decisions on conversion, retention, and support volume. It looks like a function that can say “we know drop off increases by twelve percent at this step because we measured it across eighty thousand sessions, and here is our proposed fix that we have already tested with engineering for feasibility.” That is influence. That is value.

A screenshot of a button and a strong feeling is not design. It is heckling with a Figma licence.

4. Risk That Never Risks Anything

Risk functions often drift into the same trap. It is easy to publish a list of findings, state what is non compliant, and point out gaps. It is much harder to sit in sprint reviews and guide decisions as they form, design controls that preserve velocity, or propose practical alternatives that balance safety with usability. Risk that lives in documents is narrative. Risk that lives in the room is influence.

If a risk function does not join the meetings where critical decisions are made, if it does not shape options before they solidify, it becomes another backlog item fighting for relevance. Another ticket to be negotiated, another control to be interpreted creatively under pressure. Real risk work produces insight that changes behaviour before the problem materialises. It does not simply annotate the aftermath and declare the team immature.

5. Cyber as a Backlog Generator

Cyber and security teams can drift into the same pattern. A penetration test report is not value. A spreadsheet of findings is not protection. A quarterly email with severity ratings is not security. If the same issues reappear release after release, the problem is not developer immaturity. It is systemic enablement.

A cyber team that works with platform teams to harden pipelines, embeds guardrails into CI CD, provides reusable components to prevent entire classes of vulnerability, and supplies consumable building blocks which make the secure path the easiest path is a team creating value. If instead you hand delivery teams a list of findings and walk away, you are not reducing risk, you are generating a backlog item competing for priority against revenue, customer experience, and regulatory change. Give teams tools that solve real problems and they will use them. Give them a list of issues and you will be negotiated.

6. The PMO Spectator Effect

There is a special flavour of corporate heckling reserved for the PMO.

On paper, the Project Management Office exists to create predictability, reduce risk, and improve transparency across portfolios. It promises discipline, visibility, and control. In theory, it should be an accelerant.

In practice, when it drifts into commentary, it becomes a narrator of delivery rather than an enabler of it. A heckling PMO produces immaculate status reports while delivery teams wrestle with messy reality. It tracks milestones but does not remove blockers. It escalates risk but does not help redesign plans. It enforces process compliance but does not materially improve outcomes.

Because PMOs rarely own the product or the technical architecture, they can afford to construct clean narratives about what “should” have happened. They can question estimates without absorbing integration complexity. They can demand alignment without carrying the cost of delay. They can score maturity without understanding constraints. The result is governance theatre.

Product teams, meanwhile, are balancing client needs, technical debt, regulatory nuance, and commercial trade offs. They have already considered most of the counter proposals. They have already debated alternatives. But they have less energy to defend their position because they are also trying to ship. Eventually alignment sessions are scheduled. Decks are exchanged. Language is harmonised. Both sides present. Both sides moderate. Both sides leave with a shared document that looks like consensus but mostly reflects exhaustion.

And nothing changes. The product continues largely as it was. The heckler moves to the next target. The only casualty is the energy quietly consumed by the whole exercise, energy that was never measured, never recovered, and never missed until you wonder why the organisation always feels slightly slower than it should.

A high value PMO would look very different. It would embed in delivery. It would focus on unblocking rather than reporting. It would simplify rather than add ceremony. It would help teams make trade offs instead of policing them. If the PMO’s primary output is narrative about other teams, it is heckling. If its output is accelerated delivery, fewer surprises, and clearer decisions, it is leadership.

7. The Roadmap Session as a Litmus Test

The quarterly roadmap review is one of the most common forums in large organisations. It typically has a clear stated purpose: walk through what is planned, build shared understanding of how it connects to strategy, unpack the business case and dependencies, and align on prioritisation across teams and channels. On paper this is collaborative. In practice it is often where heckling reaches its peak intensity.

The difference between a genuine alignment session and a heckling session is not the agenda. It is who is in the room, what they have done before they arrived, and whether they are there to help or to perform scrutiny.

A partner reads the material, understands the constraints, asks questions that reduce ambiguity, and leaves the team clearer on what to do next. A heckler arrives unprepared, asks questions that signal intelligence rather than generate insight, raises risks without proposing alternatives, and departs leaving the team with more uncertainty than they walked in with.

If you are attending a planning session and your primary preparation was checking your calendar, you are not a partner. You are an audience member with a speaking slot.

Executive input and support, which these sessions explicitly require, only has value when it is anchored in real understanding of what the team is trying to do and why the trade offs have landed where they have. Input from someone who has not engaged with the business case is not support. It is noise dressed as governance.

Before the next roadmap review, ask yourself whether you have done the work that earns you a meaningful seat at that table. If not, the most valuable contribution you can make is to cancel the review.

8. Narrative Is Not Delivery

Every function in an organisation must produce something more than a narrative about another team. Architecture must produce principles and platforms that reduce friction. Risk must produce insight that shapes decisions in real time. UX must produce clarity that survives contact with engineering. Cyber must produce systems that prevent recurrence. If your primary output is a deck explaining why others are not good enough, you are not creating value. You are heckling. Delivery teams do not need more commentary. They need partners who share accountability for outcomes.

9. The Seductive Counter Narrative

There is a more insidious dimension to corporate heckling that deserves its own examination.

Because the heckler carries almost no production responsibility, they have something the product team does not: spare capacity for narrative construction. They can spend days crafting a compelling alternative story. A cleaner model. A simpler approach. A vision unburdened by the complexity of actually having to deliver it. And it is often seductive. It sounds coherent. It has diagrams. It has a name. What it rarely has is memory.

On inspection, product teams have almost always already considered this narrative. They have interrogated it, tested it against their client data, weighed it against constraints the heckler has never encountered, and made a deliberate choice to move in a different direction. They understand their clients better. They have a plan. They simply did not write a deck about the roads they chose not to take.

The asymmetry is damaging. The heckler, unencumbered by delivery, can invest disproportionate energy in articulating their counter narrative. The product team, already running a business and trying to ship value, has far less energy to defend decisions they made correctly but informally. The burden of proof falls on the wrong party.

So organisations do what they always do when two competing narratives collide. They force alignment. They convene workshops. They create working groups. They schedule steering forums. Both sides present. Both sides moderate. Both sides leave with a shared document that looks like consensus but mostly reflects exhaustion. And nothing changes. The product continues largely as it was. The heckler moves to the next target. The only casualty is the energy quietly consumed by the whole exercise, energy that was never measured, never recovered, and never missed until you wonder why the organisation always feels slightly slower than it should.

Counter narratives produced without delivery accountability are not strategy. They are expensive theatre dressed as governance.

10. The Bar Raiser Is Not a Heckler

It is worth being precise about what this essay is not arguing. It is not arguing against challenge. It is not arguing against tension. It is not arguing that product teams should be left alone to make decisions in comfortable isolation. Unchallenged teams drift. Comfortable consensus produces mediocre outcomes. Tension, applied well, is one of the most productive forces in any organisation. The bar raiser is the embodiment of this distinction.

A bar raiser is not a commentator. They are a subject matter expert with a proven track record, someone who has run production workloads at comparable scale, who has felt the weight of the trade offs, who has made the hard calls under pressure and lived with the consequences. They do not arrive with a pre formed narrative. They arrive with hard won pattern recognition and the credibility that comes from having delivered.

Critically, they sit inside the team. They attend the same discovery sessions. They read the same constraints. They understand the client problems before they form an opinion about the solution. Their challenge comes after comprehension, not before it. Their narrative is built collaboratively, through conversation, through disagreement grounded in shared context, through tension that makes the output stronger rather than simply louder.

This is what separates the bar raiser from the heckler. The heckler’s narrative precedes understanding. The bar raiser’s narrative emerges from it. The heckler creates two competing stories and forces an alignment process that exhausts both sides. The bar raiser creates one shared story, harder won, more durable, and owned by the people who have to deliver it.

But calling something a bar raising session does not make it so. The label is not the thing. If you want to know whether your bar raising function is actually raising the bar, ask the teams that attended. Ask them whether it added value. Ask whether any outcomes improved as a result. Ask whether they spent the session restating constraints to ideas that were not sufficiently thought through before the meeting was called. Ask whether they left with genuine assistance or with a list of issues to resolve on their own. The answers will tell you quickly whether you have a bar raiser or an institutionalised heckler with a better job title.

Challenge without context is noise. Challenge with context, delivered from inside the work, is how good teams become great ones.

11. What To Do If You Have Heckling Functions

If you recognise these patterns in your organisation, the instinct may be to restructure, defund, or simply ignore the offending functions. That instinct is understandable but wrong, because it wastes the expertise that almost certainly exists inside those teams.

The people in these functions are not usually incompetent. Many of them are deeply skilled, experienced, and genuinely want to make a difference. The problem is structural. They have been placed at a distance from delivery, given frameworks instead of problems, and measured on outputs that have nothing to do with what actually ships. Over time, commentary becomes the only currency available to them. It is not surprising that frustration follows. They sense their own irrelevance. They feel the distance growing between their work and anything that matters. The heckling is often a symptom of that frustration, not its cause.

No organisation can afford teams whose relevance depends on someone else’s product set. That is not a support function. That is a dependency masquerading as governance. When a team’s purpose is defined by what another team is building rather than by what they themselves are accountable for delivering, they will always drift toward commentary. They have no other move. Their existence requires the product team to be doing something they can talk about.

The solution is reintegration. Move architects into delivery teams. Embed risk practitioners into sprint ceremonies. Put UX designers in the room when engineering trade offs are being made. Give cyber teams ownership of platform controls rather than audit findings. Make them accountable for outcomes they can actually influence, not scores on a maturity model that no one trusts. And if a team cannot articulate what it produces independently of what another team is building, that is not a communication problem. It is a mandate problem that no amount of heckling will solve.

Most people, given the chance to do real work and contribute to something that ships, will take it. The commentariat is not a permanent condition. It is what happens when talented people are structurally prevented from being useful. Reintegrate them, give them genuine accountability, and most of them will stop narrating and start building.

Corporate heckling is loud, confident, and useless. The bar raiser is quiet, credible, and transformative. Collaboration is harder than commentary, and slower to begin, but it is the only thing that actually compounds. One builds decks. The other builds outcomes.

It is also worth saying plainly: many of the people doing the most visible heckling are not difficult people. They are good people in the wrong structure. They arrived with real skills, genuine ambition, and a sincere desire to contribute. The organisation then placed them at a distance from anything they could actually influence, gave them frameworks to apply to other people’s problems, and measured them on outputs that nobody outside their own function cares about. Over time, distance breeds frustration. Frustration breeds commentary. Commentary, when it gets loud enough, looks like heckling. But the heckling is not the person. It is what the person has been reduced to by a culture and structure that gave them no better option. Move these people. Put them where their skills can actually land. Set them up with real accountability, real context, and real problems that belong to them. Most of them will transform. Not because they have changed, but because the conditions that were suppressing them have. The frustrated heckler in the wrong team is often the most valuable contributor in the right one. The challenge was never the individual. It was always the structure they were trapped inside.

Note: Almost everyone that I tested this article with thought it was pointed at them. On reflection, I believe that the ambiguity of the application of this article is a healthy space to be 🙂

1. The Shoe Planet Problem

In The Hitchhiker’s Guide to the Galaxy, there is a planet where the inhabitants become so obsessed with shoes that the shoes eventually take over. The civilisation does not collapse because it lacks intelligence. It collapses because something peripheral accumulates mass until it dominates everything essential.

Leadership bloat is the corporate equivalent of that shoe event horizon.

Leadership is necessary. Direction matters. Coherence matters. But beyond a certain density, leadership stops orbiting the work and begins consuming it. The organisation crosses an invisible boundary where supervising value creation becomes more important than value creation itself.

That boundary is the leadership event horizon.

2. The One Metre Ruler

Imagine hiring one hundred leaders to stare at a one metre ruler.

How long is it?

One metre.

Will they agree?

Eventually. After workshops. After alignment sessions. After someone reframes the definition of measurement. After governance confirms the interpretation of length. The ruler does not change. Reality does not move. What expands is the interpretive machinery around it.

What did the hundred leaders change? Not the length. They changed the cost base. They changed the latency of decision making. They changed how long it now takes to say something obvious.

Near an event horizon, mass bends time. In organisations, layers bend speed. The more leadership mass you add, the slower information travels. By the time clarity moves up and back down the hierarchy, the market has already moved.

3. When the Shoes Take Control

In the Hitchhiker universe, the tipping point is subtle. People are still discussing shoes, improving shoes, optimising shoes. Only later does it become clear that the accessories are now in charge.

In business, we hire leaders to coordinate teams. Then we hire leaders to coordinate those leaders. Then we create forums to align the coordinating leaders. Each step feels responsible. Collectively, they create gravitational pull.

At some point, the business exists to sustain its leadership ecosystem rather than to win in its market. The org chart becomes the product. Ritual replaces output. The shoes are no longer worn. They are curated.

4. Sectionalising the Galaxy

To manage complexity, we subdivide the business into smaller domains. Each segment gets its own leader. Each leader builds a reporting structure. Each structure develops language, metrics, and boundaries that reinforce autonomy. Internally, this feels like precision. Externally, it feels like fragmentation.

The client does not experience your segmentation model. They experience one product, one service, one brand. Internally, multiple leaders debate which micro domain owns the button the client just pressed. Every boundary introduces a negotiation. Every negotiation introduces delay. The galaxy becomes a federation of guarded territories rather than a coherent competitive force.

Sectionalisation increases interfaces. Interfaces increase friction. Friction reduces speed.

5. Comfort as Gravity

Leaders often hire people they feel comfortable with. People who speak the same conceptual language. People who understand the politics. People who can sit in a room and have sophisticated conversations about alignment and transformation.

But filling rooms with people you enjoy conversing with is not a business model. It is a social structure with a payroll.

Comfort attracts more comfort. The organisation gradually optimises for internal fluency rather than external performance. The gravitational mass increases. Escaping becomes harder.

6. The Fifty Metre Paradox

There is a particular species of gravitational collapse that deserves its own classification.

An executive hires a business head to prioritise and align what a team is doing. That team sits less than fifty metres from the executive’s office. The team already has a leader. That leader already has a mandate. That mandate was, in most cases, given by the same executive who just hired the business head.

What follows is predictable. Two structures now orbit the same work. Both need to understand it. Both need to articulate it. Both need to feel heard. Workshops are convened. Alignment sessions are scheduled. Vocabulary is negotiated. And after weeks of structured convergence, both sides arrive at exactly the same conclusion the team started with.

The executive feels comfort. Two independent hierarchies have validated the same direction. This feels like rigour. It feels like governance. In reality, it is the organisational equivalent of asking someone to confirm that the clock on the wall matches the clock on your wrist.

But the real cost is hidden below. The teams responsible for serving both structures now maintain dual reporting formats, synchronised decks, parallel status updates. Builders become translators. Engineering hours evaporate into PowerPoint. Every sprint loses capacity not to delivery, but to the overhead of proving to two audiences that the same thing is still the same thing.

The work does not move faster. The team does not gain clarity. What grows is the administrative mass required to keep two gravitational centres from visibly contradicting each other.

Fifty metres. Same floor. Same building. Two reporting lines. Zero additional insight.

7. The Trampoline Committee

There is a governance structure so perfectly circular that it deserves a name. Call it the trampoline committee.

A group of senior leaders convenes to review and debate decisions. The decisions were made by their subordinates. Their subordinates are the subject matter experts. They built the systems, analysed the data, assessed the risk, and arrived at a recommendation based on years of domain knowledge the committee does not have.

The committee examines the decision. They do not understand it. This is not a criticism of their intelligence. It is a structural inevitability. They were not hired to understand the detail. They were hired to lead at a level above it.

So they ask questions. Reasonable questions. Probing questions. Questions that feel like oversight. And who answers those questions? The same subordinates who made the decision in the first place. The experts explain the decision. The committee listens. The experts explain it again in different words. The committee nods. The decision is approved. Unchanged.

The decision bounced up, hit the committee, and bounced back down exactly where it started. A trampoline. Energy expended, altitude achieved, net displacement zero.

Nothing was improved. Nothing was caught. Nothing was redirected. The only measurable output is that delivery slowed by whatever elapsed time the committee cycle consumed. Two weeks. Four weeks. Sometimes longer, if the calendar gods are unkind and the committee only sits monthly.

Trampoline committees exist because they feel like control. Executives feel they have exercised judgement. Governance frameworks can point to an approval step. Auditors can see a signature. But the signature confirms what was already confirmed by the people who actually know.

The most telling sign of a trampoline committee is this: if you removed it entirely, nothing downstream would change. The same decisions would be made. The same outcomes would follow. The only difference is they would arrive faster.

8. Less Than Nothing

Beyond the leadership event horizon, adding another leader does not increase clarity. It increases drag.

Decision cycles lengthen because authority is distributed across more layers.

Accountability diffuses because responsibility becomes collective and abstract.

Cost compounds because senior salaries require disproportionate impact to justify their existence.

Layering leaders on leaders achieves less than nothing when it slows the builders. It is not neutral overhead. It is competitive disadvantage.

9. Escaping the Event Horizon

The problem is not leadership. The problem is inversion of priorities.

Competitive organisations are ruthless about identifying the real constraint. If the constraint is engineering throughput, hire engineers. If the constraint is product clarity, hire product thinkers. If the constraint is distribution, hire market makers. Do not reflexively hire supervision when the bottleneck is production.

Strong leadership often manifests as fewer layers, clearer mandates, wider spans of control, and a bias toward builders over commentators. The aim is not to eliminate gravity. The aim is to prevent collapse.

Markets reward output, speed, and coherence.

No number of leaders staring at a one metre ruler will make it any longer.

This is an assessment. It is not balanced. It is not here to validate your instincts, your planning methodology, or your confidence in the delivery framework you inherited. It exists to surface how you actually think about technology leadership when you are deciding whether to trust an engineer, approve a pivot, or override a technical warning to protect a timeline.

Answer honestly. Not as the executive you present in interviews. As the leader you become when the deadline is real, the team is pushing back, and someone senior is asking you for certainty you do not have.

Every option is phrased to sound reasonable, responsible, and professionally defensible. That is the point. The wrong answers are rarely stupid. They are comfortable.

How to Score Yourself

🟢 Strong technology leadership instinct – demonstrates systems thinking, quality, sustainability, and genuine respect for engineering as a discipline
🟡 Acceptable but surface level – not wrong, but reveals a preference for process, optics, or a management lens over a technology leadership lens
🔴 Concerning – reveals a fixation on timelines, revenue, reporting ceremony, or a belief that technologists are execution resources who should deliver rather than think

After answering all questions, count how many 🟢, 🟡, and 🔴 answers you selected. Then read the interpretation at the end.

Questions:

1. A Major Platform Decision Was Approved Six Months Ago

New evidence suggests it may be the wrong choice. What do you do?

A. Revisit the decision with the new evidence and recommend a course correction even if it causes short term disruption
B. Flag the concern but continue execution since the committee already approved it and reversing would delay the programme
C. Raise it informally but keep delivery on track since the timeline commitments to the board cannot slip
D. Continue as planned because reopening approved decisions undermines confidence in the governance process

2. Your Team Proposes Removing an Integration Layer

It will reduce complexity but invalidate three months of another team’s work. How do you proceed?

A. Protect the other team’s work and find a compromise that keeps both approaches since we need to respect the investment already made
B. Evaluate the simplification on its technical merits regardless of sunk cost and proceed if the outcome is better for customers
C. Delay the decision until next quarter’s planning cycle so it can be properly socialised across all stakeholders
D. Proceed only if the simplification can be shown to accelerate the current delivery timeline

3. You Inherit Seven Management Layers Between CTO and Engineers

What is your first instinct?

A. Understand why each layer exists and remove any that do not directly contribute to decision quality or delivery outcomes
B. Add a dedicated delivery management function to coordinate across the layers more effectively
C. Maintain the structure but introduce better reporting dashboards so you can see through the layers
D. Restructure the layers around revenue streams so each layer has clear commercial accountability

4. What Is the Primary Purpose of a Technology Strategy Document?

A. To secure budget approval by demonstrating alignment between technology investments and projected revenue growth
B. To reduce uncertainty by clarifying what the organisation will and will not build, and why
C. To provide a roadmap with delivery dates that the business can hold the technology team accountable to
D. To communicate the technology vision to non technical stakeholders in a way they find compelling

5. What Does Blast Radius Mean in Systems Architecture?

A. The scope of impact when a single component fails, and how far the failure propagates across dependent systems
B. The amount of data lost during a disaster recovery event before backups can be restored
C. The total number of customers affected during a planned maintenance window
D. The financial exposure created by a system outage, measured in lost revenue per minute

6. When Designing a Critical System, What Is Your Primary Architectural Concern?

A. Ensuring the system can scale to meet projected revenue targets for the next three years
B. Designing for graceful failure so the system degrades safely rather than failing catastrophically
C. Selecting the vendor with the strongest enterprise support agreement and SLA guarantees
D. Ensuring the architecture aligns with the approved enterprise reference model and standards

7. What Does It Mean to Design a System Assuming Breach Will Happen?

A. Building layered defences, monitoring, and containment so that when a breach occurs the damage is limited and detected quickly
B. Purchasing comprehensive cyber insurance to cover the financial impact of a breach event
C. Conducting annual penetration tests and remediating all critical findings before the next audit cycle
D. Ensuring all systems are compliant with the relevant regulatory frameworks and industry standards

8. A Project Is Behind Schedule

The team suggests reducing scope to meet the deadline. The business stakeholder wants the full scope delivered on time. What do you recommend?

A. Deliver the reduced scope with high quality and iterate, since shipping broken software on time is worse than shipping less software that works
B. Add additional resources to accelerate delivery since the business committed to the date with external partners
C. Negotiate a two week extension with the full scope since the revenue impact of a delayed launch is manageable
D. Split the team to deliver the core features on time and the remaining features two weeks later as a fast follow

9. How Should Work Ideally Flow Through a Well Functioning Technology Team?

A. Through two week sprints with defined ceremonies, backlog grooming, sprint reviews, and retrospectives
B. Through continuous small changes deployed frequently with clear ownership and minimal handoffs
C. Through quarterly planning cycles with monthly milestone reviews and weekly status reporting
D. Through a prioritised backlog managed by a product owner who coordinates with the business on delivery sequencing

10. A Team Is Delivering Features on Time but Production Incidents Are Increasing

What does this tell you?

A. The team is likely cutting corners on quality to meet deadlines and the delivery metric is masking a growing technical debt problem
B. The team needs better production support tooling and a dedicated site reliability function
C. The team is delivering well but the infrastructure team is not scaling the platform to match the increased feature throughput
D. The incident management process needs improvement since faster triage would reduce the apparent incident volume

11. What Is the Difference Between Vertical Scaling and Horizontal Scaling?

A. Vertical scaling adds more power to a single machine while horizontal scaling adds more machines to distribute the load
B. Vertical scaling increases storage capacity while horizontal scaling increases network bandwidth
C. Vertical scaling is for databases and horizontal scaling is for application servers
D. Vertical scaling is cheaper at small volumes while horizontal scaling is cheaper at large volumes, which is why you choose based on cost projections

12. What Is Technical Debt?

A. Shortcuts or suboptimal decisions in code and architecture that make future changes harder, slower, or riskier
B. The accumulated cost of software licences and infrastructure that the organisation is contractually committed to paying
C. The gap between the current technology stack and the approved target state architecture
D. Legacy systems that have not yet been migrated to the cloud as part of the digital transformation programme

13. Why Is It Important That a System Can Be Observed in Production?

A. Because without visibility into how the system behaves under real conditions you cannot diagnose problems, understand performance, or detect failures early
B. Because the compliance team requires evidence that systems are being monitored as part of the annual audit
C. Because the business needs real time dashboards showing transaction volumes and revenue metrics
D. Because the vendor SLA requires the organisation to demonstrate monitoring capability to qualify for support credits

14. What Is the Primary Benefit of a Public Cloud Provider Like AWS or Azure?

A. The ability to provision and scale infrastructure on demand without managing physical hardware, paying only for what you use
B. Guaranteed lower costs compared to on premises infrastructure for all workload types and volumes
C. Automatic compliance with all regulatory requirements since the cloud provider manages the security controls
D. Eliminating the need for a technology team since the cloud provider manages everything end to end

15. What Is the Shared Responsibility Model in Cloud Computing?

A. The cloud provider is responsible for the security of the cloud infrastructure while the customer is responsible for securing what they build and run on it
B. The cloud provider and the customer share the cost of infrastructure equally based on a negotiated commercial agreement
C. Both the cloud provider and the customer have equal responsibility for all aspects of security and neither can delegate
D. The cloud provider assumes full responsibility for everything deployed on their platform as part of the service agreement

16. What Is an Availability Zone?

A. A physically separate data centre within a cloud region, designed so that failures in one zone do not affect others
B. A geographic region where the cloud provider offers services, such as Europe West or US East
C. A virtual network boundary that isolates different customer workloads from each other for security purposes
D. A pricing tier that determines the level of uptime guarantee and support response time for your workloads

17. What Is Infrastructure as Code?

A. Defining and managing cloud infrastructure through machine readable configuration files that can be version controlled and reviewed like software
B. A software tool that automatically generates infrastructure diagrams from the live cloud environment
C. A methodology for documenting infrastructure decisions in a shared wiki so the team can track changes over time
D. An approach where infrastructure costs are coded into the project budget as a separate line item from application development

18. When Should Testing Happen in the Development Lifecycle?

A. Continuously throughout development, with automated tests running on every code change as part of the build pipeline
B. After development is complete, during a dedicated testing phase before the release is approved for production
C. At key milestones defined in the project plan, with formal sign off required before moving to the next phase
D. Primarily before major releases, with exploratory testing conducted by the QA team in the staging environment

19. A Team Tells You They Have 95% Code Coverage

How confident should you be in their quality?

A. Coverage alone does not indicate quality because tests can cover code without meaningfully validating behaviour or edge cases
B. Very confident since 95% coverage means almost all of the codebase has been validated by automated tests
C. Moderately confident but you would want to see the coverage broken down by module to check for gaps in critical areas
D. You would need to compare the coverage metric against the industry benchmark for their technology stack to assess it properly

20. What Is the Purpose of a Chaos Engineering or Game Day Exercise?

A. To deliberately introduce failures into a system to test how it responds and to build confidence that recovery mechanisms work
B. To simulate peak traffic scenarios to verify the infrastructure can handle projected load during high revenue periods
C. To test the disaster recovery plan by failing over to the secondary site and measuring recovery time against the SLA
D. To stress test the team’s incident management process and identify bottlenecks in the escalation procedures

21. What Is the Difference Between a Data Warehouse and a Data Lake?

A. A data warehouse stores structured, curated data optimised for querying and reporting, while a data lake stores raw data in its native format for flexible future use
B. A data warehouse is an on premises solution while a data lake is a cloud native service that replaces the need for traditional databases
C. A data warehouse is owned by the business intelligence team while a data lake is owned by the engineering team, which is why they are governed separately
D. A data warehouse handles historical data for compliance purposes while a data lake handles real time data for operational dashboards

22. Your Organisation Wants to Build a Machine Learning Model to Predict Customer Churn

What is the first question you should ask?

A. Do we have clean, representative data that captures the behaviours and signals that precede churn, and do we understand the biases in that data
B. What is the expected revenue impact of reducing churn by a target percentage, and does it justify the investment in a data science team
C. Which vendor platform offers the best prebuilt churn prediction model so we can deploy quickly without building a team from scratch
D. Can we have a working model within the current quarter so we can demonstrate the value of AI to the executive committee

23. What Is the Biggest Risk of Deploying a Machine Learning Model Without Ongoing Monitoring?

A. The model will silently degrade as real world data drifts away from the data it was trained on, producing increasingly wrong predictions that nobody notices until damage is done
B. The model will consume increasing amounts of compute resources over time, driving up infrastructure costs beyond the original budget
C. The compliance team may flag the model as a risk because it was deployed without a formal model governance review and sign off process
D. The business will lose confidence in AI if the model produces a visible error, which could jeopardise funding for future AI initiatives

24. A Business Stakeholder Wants an AI Feature That Automates a Customer Decision

The team warns that the training data contains historical bias. What do you do?

A. Take the bias concern seriously. Deploying a biased model at scale will amplify discrimination, create regulatory exposure, and damage customer trust in ways that are extremely difficult to undo
B. Proceed with the deployment but add a disclaimer that the model’s recommendations should be reviewed by a human before any final decision is made
C. Ask the data science team to quantify the bias impact and present a risk assessment to the steering committee so leadership can make an informed commercial decision
D. Deprioritise the concern for now and launch the feature since the competitive advantage of being first to market outweighs the risk, and the bias can be addressed in a future iteration

25. You Have One AI Engineer Embedded in a Feature Team

Nobody in the team or its management chain has AI or machine learning experience. The engineer’s work is reviewed by people who do not understand it. How do you evaluate this structure?

A. This is a problem. The engineer has no peers to learn from, no manager who can grow their career, and no quality gate on their work. They will either stagnate, produce unchallenged work of unknown quality, or leave. AI engineers need to sit in or be connected to a community of practice with people who understand their discipline
B. This is fine as long as the engineer has clear deliverables and the feature team has a strong product owner who can validate the business outcomes of the AI work
C. This is efficient. Embedding specialists directly in feature teams ensures their work is aligned with delivery priorities and avoids the overhead of a separate AI team that operates disconnected from the product
D. This is manageable. Provide the engineer with access to external training and conferences so they can maintain their skills, and ensure their performance is measured on delivery milestones like any other team member

26. What Does Data Governance Mean in Practice?

A. Ensuring the organisation knows what data it has, where it lives, who owns it, how it flows, what quality it is in, and what rules govern its use, so that data is treated as a product rather than an accident
B. A framework of policies and committees that approve data access requests and ensure all data usage complies with the relevant regulatory requirements
C. A set of data classification standards and retention policies that are documented and audited annually to satisfy regulatory obligations
D. A technology platform that enforces role based access controls and encrypts data at rest and in transit across all systems

27. You Need to Hire a Senior Engineer

Which quality matters most?

A. Deep curiosity, the ability to reason through unfamiliar problems, and a track record of simplifying complex systems
B. Certifications in the specific technologies your team currently uses, with at least ten years of experience in the industry
C. Strong communication skills and experience presenting to executive stakeholders and steering committees
D. A proven ability to deliver projects on time and within budget, with references from previous programme managers

28. An Engineer Pushes Back on a Technical Decision You Made

They provide evidence you were wrong. What is the ideal response?

A. Thank them, evaluate the evidence, and change the decision if the evidence warrants it because being right matters more than being in charge
B. Acknowledge their input and ask them to document their concerns formally so they can be reviewed in the next architecture review board
C. Listen carefully but explain the broader strategic context they may not be aware of that influenced your original decision
D. Appreciate the initiative but remind them that decisions at your level factor in commercial and timeline considerations beyond the technical merits

29. What Is the Biggest Risk When a Non Technical Leader Runs a Technology Team?

A. They cannot distinguish between genuine technical risk and comfortable excuses, which leads to either missed danger or wasted time
B. They tend to over rely on vendor solutions and consultancies because they cannot evaluate build versus buy decisions independently
C. They struggle to earn the respect of senior engineers, which leads to talent attrition and difficulty recruiting strong replacements
D. They focus on timelines and deliverables rather than the technical foundations that determine whether those deliverables are sustainable

30. A Vendor Promises to Solve a Critical Problem

What is your first concern?

A. Whether the solution creates a dependency that will be expensive or impossible to exit, and what happens when the vendor changes direction
B. Whether the vendor is on the approved procurement list and whether the commercial terms fit within the current budget cycle
C. Whether the vendor has case studies from similar organisations and what their Net Promoter Score is among existing customers
D. Whether the vendor can commit to a delivery timeline that aligns with the programme milestones already communicated to the board

31. You Are Reviewing Two Architecture Proposals

Proposal A is clever and impressive but requires deep expertise to operate. Proposal B is simpler but less elegant. Which do you prefer?

A. Proposal B, because a system that can be understood, operated, and maintained by the team that inherits it is more valuable than one that impresses today
B. Proposal A, because the additional complexity is justified if it delivers significantly better performance metrics
C. Neither until both proposals include detailed cost projections and a total cost of ownership comparison over five years
D. Whichever proposal the lead architect recommends since they have the deepest technical context on the constraints

32. A 97 Slide Strategy Deck Is Presented to You

What is your reaction?

A. Scepticism, because length often compensates for lack of clarity and a strong strategy should be explainable in a few pages
B. Appreciation, because a thorough strategy deck shows the team has done their due diligence and considered all angles
C. Request an executive summary of no more than five slides that highlights the key investment asks and expected returns
D. Review it in detail because strategic decisions of this magnitude deserve comprehensive analysis and supporting evidence

33. A Technology Team Has No Weekly Status Report

They deploy daily, incidents are low, and customers are satisfied. Is this a problem?

A. No. Outcomes are the evidence. If the system works, customers are happy, and the team ships reliably, the absence of a status report means nothing is being hidden
B. Yes. Without a structured weekly report the leadership team has no visibility into what the team is doing and cannot govern effectively
C. It depends. A lightweight status update would be beneficial for alignment even if things are going well, since stakeholders deserve visibility
D. Yes. Consistent reporting is a professional discipline. Even high performing teams need to document their progress for accountability and audit purposes

34. A Team Discovers Halfway Through a Migration That the Original Plan Was Wrong

They adjust and complete the migration successfully but two weeks later than planned. How do you evaluate this?

A. Positively. Learning while doing is an inherent property of complex work. The team adapted to reality and delivered a successful outcome, which is exactly what good engineering looks like
B. As a planning failure. The incorrect assumptions should have been identified during the planning phase. A proper discovery exercise would have prevented the overrun
C. Neutrally. The outcome was acceptable but the team should produce a lessons learned document to prevent similar planning gaps in future projects
D. As a risk management issue. The two week overrun needs to be logged and the planning process needs to include more rigorous assumption validation before execution begins

35. You Ask a Technology Lead How a Project Is Going

They say they do not know yet because the team is still working through some unknowns. How do you respond?

A. Appreciate the honesty. Not knowing is a valid state early in complex work. Ask what they are doing to reduce the unknowns and when they expect to have a clearer picture
B. Ask them to prepare a risk register and preliminary timeline estimate within two days so you have something to report upward
C. Express concern. A technology lead should always be able to articulate the status of their work, even if uncertain, and should present options with probability weightings
D. Escalate the concern. If the lead cannot provide a clear status update, the project may lack adequate governance and oversight

36. What Is the Most Important Thing to Measure About a Technology Team’s Performance?

A. The business outcomes their work enables, including reliability, customer experience, and the ability to change safely
B. Velocity and throughput, measured by story points completed per sprint across all teams
C. Time to market for new features, measured from business request to production deployment
D. Budget adherence, measured by comparing actual technology spend against the approved annual plan

37. A Senior Architect Strongly Disagrees With Your Proposed Approach

They present an alternative in a team meeting. They are blunt and direct. How do you handle this?

A. Welcome it. Blunt disagreement backed by evidence is a sign of a healthy team. Evaluate the alternative on its merits and decide based on what produces the best outcome
B. Thank them for their perspective but ask them to raise concerns through the proper channels rather than challenging your direction in a group setting
C. Acknowledge their passion but remind the team that once a direction is set, the expectation is to commit and execute rather than relitigate decisions
D. Listen but note that architectural decisions need to factor in business timelines and stakeholder commitments, not just technical preferences

38. How Do You View the Role of Engineers in Decision Making?

A. Engineers are domain experts whose knowledge should be actively extracted, challenged, and synthesised into better decisions. The best outcomes come from iterative collaboration, not instruction
B. Engineers should provide technical input and recommendations, but the final decision authority rests with the business leader who owns the commercial outcome
C. Engineers should focus on execution excellence. They are most effective when given clear requirements and the autonomy to choose the implementation approach
D. Engineers should be consulted on technical feasibility, but strategic decisions about what to build and when should be driven by the product and business teams

39. Your Best Engineers Have Stopped Voicing Opinions in Meetings

What does this tell you?

A. Something is wrong. When strong engineers go quiet, it usually means they have concluded that their input does not matter, which means the organisation is about to lose them or already has in spirit
B. They may be focused on delivery. Not every engineer wants to participate in strategic discussions and some prefer to let their code speak for itself
C. It could indicate that the team has matured and aligned around a shared direction, which reduces the need for debate
D. It suggests the decision making process is working efficiently. Fewer objections means the planning and communication have improved

40. An Engineer Tells You the Proposed Deadline Is Unrealistic

The team will either miss it or ship something that breaks. What do you do?

A. Take the warning seriously. Engineers who raise alarms about deadlines are usually right and ignoring them is how organisations end up with production failures and burnt out teams
B. Acknowledge the concern and ask them to propose an alternative timeline with a clear breakdown of what can be delivered by when
C. Thank them for the flag but explain that the deadline was set based on commercial commitments and the team needs to find a way to make it work
D. Ask them to quantify the risk. If they can show specific technical evidence for why the deadline is unrealistic, you will escalate it. Otherwise the plan stands

---

Answer Key With Explanations

Each option is scored 🟢 🟡 or 🔴, and the explanation focuses on what that option optimises for over time.

1. A Major Platform Decision Was Approved Six Months Ago

Option	Score	Why it is attractive	What it tends to create
A	🟢	Prioritises the right outcome over protecting past decisions	Better products and fewer sunken costs
B	🟡	Honouring governance feels responsible	Delivery of the wrong thing, on time
C	🟡	Protecting board timelines is professionally safe	Informal concerns that go nowhere
D	🔴	Governance confidence is genuinely valuable	Entrenched wrong decisions and learned helplessness

2. Your Team Proposes Removing an Integration Layer

Option	Score	Why it is attractive	What it tends to create
A	🟡	Respecting investment sounds fair	Sunk cost paralysis masquerading as empathy
B	🟢	Merits and customer outcomes as the deciding lens	Better systems and cleaner architecture
C	🟡	Socialisation reduces friction	Delay that allows the right call to be avoided indefinitely
D	🔴	Timeline acceleration is always a defensible frame	Technology decisions subordinated to scheduling

3. You Inherit Seven Management Layers

Option	Score	Why it is attractive	What it tends to create
A	🟢	Cutting what adds no value is the only honest response	Faster decisions and cleaner accountability
B	🔴	Coordination feels like the problem	More layers solving the symptoms of layers
C	🟡	Dashboards feel safe and non disruptive	Visibility into a structure that still doesn’t work
D	🔴	Commercial accountability sounds modern	Revenue framing over delivery quality

4. What Is the Primary Purpose of a Technology Strategy Document?

Option	Score	Why it is attractive	What it tends to create
A	🔴	Budget alignment is how things get funded	Strategy in service of approval rather than clarity
B	🟢	Clarity over what you will and will not build is rare and powerful	Fewer wasted investments and better decisions
C	🟡	Accountability sounds mature	Accountability for the wrong things if the strategy is wrong
D	🟡	Communicating vision is legitimate	Style over substance if the audience cannot push back

5. What Does Blast Radius Mean?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Correct definition with systems thinking built in	Better architectural decisions and safer design
B	🟡	Data loss is a real concern	Conflates backup and resilience concepts
C	🟡	Customer impact is the right concern	Misses cascading failure as the core concept
D	🔴	Financial framing is relatable to business heads	Revenue lens applied to an engineering concept

6. When Designing a Critical System, What Is Your Primary Architectural Concern?

Option	Score	Why it is attractive	What it tends to create
A	🟡	Revenue targets are a real design constraint	Optimises for scale at the expense of resilience
B	🟢	Graceful failure is the most durable design principle	Systems that fail safely rather than catastrophically
C	🟡	Vendor SLAs feel like insurance	Outsources architectural thinking to contracts
D	🟡	Reference models reduce reinvention	Compliance over fitness

7. What Does Designing Assuming Breach Mean?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Layered defence and containment is the correct instinct	Systems that limit damage when breaches happen
B	🟡	Insurance feels like risk management	Financial mitigation without technical defence
C	🟡	Penetration testing is a real practice	Annual exercises are not the same as assume breach design
D	🟡	Compliance feels like security	Compliance theatre that passes audits and fails breaches

8. A Project Is Behind Schedule

Option	Score	Why it is attractive	What it tends to create
A	🟢	Quality over date is the harder but more durable choice	Systems that work and users that trust them
B	🔴	External commitments feel binding	More people working on a broken plan faster
C	🟡	Extension with full scope sounds balanced	May be right if revenue calculation is honest
D	🟡	Splitting delivery sounds pragmatic	Can create integration debt if the fast follow never arrives

9. How Should Work Flow Through a Technology Team?

Option	Score	Why it is attractive	What it tends to create
A	🟡	Agile ceremonies are familiar and teachable	Process compliance rather than actual agility
B	🟢	Continuous flow and minimal handoffs are what actually work	Fast learning and high quality delivery
C	🔴	Quarterly cycles sound like proper governance	Planning theatre that misses reality by a quarter
D	🟡	Product owner coordination feels organised	Backlogs that grow rather than systems that improve

10. Features Are on Time but Incidents Are Increasing

Option	Score	Why it is attractive	What it tends to create
A	🟢	Delivery masking quality debt is the most common failure pattern	Early intervention before the system breaks loudly
B	🟡	Tooling gaps are real	Treats a symptom without asking what caused it
C	🟡	Infrastructure scaling is a genuine bottleneck	Deflects from delivery quality as the root cause
D	🔴	Process improvement sounds constructive	Reduces apparent incidents without reducing actual ones

11. Vertical Versus Horizontal Scaling

Option	Score	Why it is attractive	What it tends to create
A	🟢	Correct and precise	Ability to make informed infrastructure decisions
B	🟡	Storage and bandwidth are real dimensions	Fundamentally wrong definition
C	🟡	Database versus app server is a familiar split	Oversimplification that breaks in practice
D	🔴	Cost framing is relatable	Reduces a technical question to a finance question

12. What Is Technical Debt?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Correct definition that connects to consequences	Ability to have honest conversations about investment
B	🟡	Licence and infrastructure costs feel like debt	Confuses financial obligations with technical constraints
C	🟡	Target state framing is familiar from transformation programmes	Reduces debt to a migration backlog
D	🟡	Legacy systems are a common mental model	Misses the fact that new systems accumulate debt too

13. Why Does Observability in Production Matter?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Correct and operationally grounded	Engineers who can diagnose and improve systems
B	🟡	Compliance evidence is a real requirement	Monitoring as audit artefact rather than operational tool
C	🟡	Business dashboards are a legitimate need	Confuses business reporting with system observability
D	🔴	SLA qualification sounds like a practical reason	Observability in service of vendor contracts, not operations

14. The Primary Benefit of Public Cloud

Option	Score	Why it is attractive	What it tends to create
A	🟢	On demand provisioning and elastic cost is the real value	Infrastructure that scales with reality
B	🟡	Cost reduction is often part of the pitch	False certainty that ignores workload specifics
C	🔴	Compliance automation sounds appealing	Dangerous misunderstanding of shared responsibility
D	🔴	Elimination of overhead sounds efficient	Cloud adoption without understanding what you still own

15. The Shared Responsibility Model

Option	Score	Why it is attractive	What it tends to create
A	🟢	Correct and precise	Security decisions made with accurate mental models
B	🟡	Commercial framing is relatable	Confuses security responsibility with cost sharing
C	🟡	Shared accountability sounds balanced	Removes the clarity that makes the model useful
D	🔴	Full provider responsibility sounds like the deal	Organisations that discover their responsibilities too late

16. What Is an Availability Zone?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Correct and operationally precise	Architecture that plans for and survives zone failures
B	🟡	Regions are a real cloud concept	Conflates region with zone
C	🟡	Network isolation is a related cloud concept	Confuses network boundaries with physical redundancy
D	🔴	Pricing tiers and uptime SLAs are familiar procurement concepts	Infrastructure decisions made on commercial rather than technical grounds

17. What Is Infrastructure as Code?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Correct and captures the key properties	Reproducible, reviewable, version controlled infrastructure
B	🟡	Diagram generation is a related practice	Confuses documentation tooling with infrastructure management
C	🟡	Documentation in a shared wiki sounds collaborative	Infrastructure decisions recorded but not enforced
D	🔴	Budget coding sounds like responsible governance	A finance process confused for an engineering practice

18. When Should Testing Happen?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Continuous automated testing is the correct answer	Fast feedback and high confidence with every change
B	🟡	Dedicated testing phases feel thorough	Late discovery of problems that compound quickly
C	🔴	Milestone sign off sounds like governance	Testing as a gate rather than a continuous signal
D	🟡	Pre release exploratory testing is real and valuable	Leaves too much surface area uncovered between releases

19. A Team Has 95% Code Coverage

Option	Score	Why it is attractive	What it tends to create
A	🟢	Coverage without behaviour validation is a known trap	Honest assessment of quality rather than metric satisfaction
B	🔴	95% sounds high and therefore safe	False confidence in a metric that can be gamed
C	🟡	Module level breakdown adds nuance	Still treats coverage as the primary quality signal
D	🔴	Benchmarking sounds rigorous	Comparing against benchmarks of a flawed metric

20. What Is the Purpose of a Chaos Engineering Exercise?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Deliberate failure injection to test recovery is correct	Verified resilience rather than assumed resilience
B	🟡	Load testing is a related practice	Confuses performance testing with resilience testing
C	🟡	DR failover testing is real and important	Narrower than chaos engineering as a practice
D	🔴	Incident process stress testing sounds useful	Focuses on the organisation’s response rather than the system’s behaviour

21. Data Warehouse Versus Data Lake

Option	Score	Why it is attractive	What it tends to create
A	🟢	Correct definition that captures the key architectural difference	Informed decisions about where data belongs
B	🟡	On premises versus cloud is a familiar axis	Conflates deployment model with data architecture
C	🟡	Team ownership is a real governance question	Reduces an architectural concept to an org chart question
D	🔴	Historical versus real time is a familiar framing	Fundamentally misunderstands both concepts

22. Building a Churn Prediction Model

Option	Score	Why it is attractive	What it tends to create
A	🟢	Data quality and bias are the foundation of any model	Models that work and can be trusted
B	🟡	Revenue impact is a legitimate prioritisation question	Skips past the foundational data question
C	🟡	Vendor platforms are a real option	Deploy fast, discover limits later
D	🔴	Demonstrating value to the executive committee is real pressure	AI theatre that looks impressive and produces wrong answers

23. The Biggest Risk of Unmonitored Production Models

Option	Score	Why it is attractive	What it tends to create
A	🟢	Data drift and silent degradation is the real risk	Monitoring practices that catch decay before it causes harm
B	🟡	Compute costs are a real operational concern	Misses the accuracy decay that is far more damaging
C	🟡	Governance review is a legitimate process	Compliance framing misses the operational risk
D	🔴	Executive confidence is a real concern	Optimises for perception rather than reliability

24. A Biased AI Model Is Proposed for Customer Decisions

Option	Score	Why it is attractive	What it tends to create
A	🟢	Takes bias seriously as a first order concern	Ethical deployment and regulatory protection
B	🟡	Human review sounds like a safeguard	Scales bias while providing legal cover
C	🟡	Steering committee decision sounds like governance	Delegates an ethical decision to a commercial forum
D	🔴	First mover advantage is a real competitive argument	Discrimination at scale with a future iteration that may never arrive

25. One AI Engineer Embedded in a Feature Team

Option	Score	Why it is attractive	What it tends to create
A	🟢	Recognises the structural failure clearly	Deliberate community of practice and proper quality gates
B	🟡	Clear deliverables and product ownership sound sufficient	Unreviewed AI work validated by people who cannot evaluate it
C	🔴	Embedded specialists sound efficient	AI capability that has no peers, no quality gate, and no future
D	🟡	Training and milestone measurement sound supportive	Isolates the engineer while providing the appearance of support

26. What Is Data Governance in Practice?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Treats data as a product with full lifecycle accountability	Trustworthy data that can be used with confidence
B	🟡	Policy and committee governance is a real structure	Bureaucratic access management masquerading as governance
C	🟡	Classification and retention policies are real requirements	Compliance artefacts without operational governance
D	🔴	Technology controls feel like governance	Enforces access without understanding what the data is or means

27. You Need to Hire a Senior Engineer

Option	Score	Why it is attractive	What it tends to create
A	🟢	Curiosity and simplification track record predict long term impact	Engineers who make systems better rather than just larger
B	🟡	Certifications feel like proof of knowledge	Credential matching rather than capability hiring
C	🟡	Communication with executives sounds valuable	Engineers selected for stakeholder management over technical depth
D	🔴	Delivery track record sounds like the right signal	Engineers selected by programme managers rather than engineers

28. An Engineer Proves You Wrong

Option	Score	Why it is attractive	What it tends to create
A	🟢	Being right matters more than being in charge	Trust, psychological safety, and better decisions
B	🟡	Formal documentation sounds thorough	Bureaucratic delay that signals pushback is unwelcome
C	🟡	Strategic context is a real consideration	Strategic context used to override technical evidence
D	🔴	Commercial considerations are real	Teaches engineers their input is decorative

29. The Biggest Risk of a Non Technical Leader

Option	Score	Why it is attractive	What it tends to create
A	🟢	Inability to distinguish risk from excuses is the core failure mode	Leaders who get fooled in both directions
B	🟡	Vendor over reliance is a real pattern	One manifestation of a deeper capability gap
C	🟡	Talent attrition is a real consequence	Symptom rather than root cause
D	🟡	Timeline focus over technical foundations is common	Another symptom of the same underlying problem

30. A Vendor Promises to Solve a Critical Problem

Option	Score	Why it is attractive	What it tends to create
A	🟢	Exit costs and vendor direction changes are the durable concerns	Relationships that preserve architectural independence
B	🟡	Procurement process is a real requirement	Approved vendor lists substituting for technical evaluation
C	🟡	Case studies are useful social proof	NPS and reference customers replacing structural analysis
D	🔴	Timeline alignment is always relevant	Vendor selected based on board commitments rather than fit

31. Clever Architecture Versus Simple Architecture

Option	Score	Why it is attractive	What it tends to create
A	🟢	Operability and maintainability outlast impressiveness	Systems that the next team can understand and fix at 02:00
B	🟡	Performance metrics are a real consideration	Complexity justified by benchmarks that matter at demo time
C	🟡	TCO analysis is legitimate	Analysis paralysis replacing a clear architectural principle
D	🟡	Architect recommendation makes sense	Defers to expertise but avoids the underlying principle

32. A 97 Slide Strategy Deck

Option	Score	Why it is attractive	What it tends to create
A	🟢	Length compensating for clarity is a real and common failure	Pressure for clear thinking over comprehensive coverage
B	🔴	Thoroughness sounds like due diligence	Rewarding volume over clarity
C	🟡	Executive summary sounds practical	May preserve the 97 slides rather than replacing them
D	🟡	Comprehensive review sounds responsible	97 slides reviewed without asking whether they add up to a strategy

33. A High Performing Team Has No Status Report

Option	Score	Why it is attractive	What it tends to create
A	🟢	Outcomes are the evidence. Reports are not the product	Freedom for high performing teams to focus on results
B	🔴	Governance visibility sounds like a legitimate requirement	Reporting as a proxy for leadership confidence
C	🟡	Lightweight alignment sounds reasonable	Process for its own sake introduced into a team that does not need it
D	🔴	Accountability and audit discipline sounds professional	Bureaucratic expectations imposed on a team that is already delivering

34. A Team Adjusts and Delivers Two Weeks Late

Option	Score	Why it is attractive	What it tends to create
A	🟢	Adaptation during complex work is exactly correct behaviour	A culture that engages honestly with what they discover
B	🔴	Planning failure is a clean and familiar frame	Teams that fabricate certainty rather than discovering truth
C	🟡	Lessons learned sounds constructive	Document production as a substitute for genuine understanding
D	🔴	Risk management logging sounds rigorous	More assumption validation that produces more fabricated certainty

35. A Lead Says They Do Not Know Yet

Option	Score	Why it is attractive	What it tends to create
A	🟢	Not knowing is valid. What matters is what reduces the unknowns	Honest engineering cultures that surface uncertainty early
B	🟡	Having something to report upward sounds responsible	Risk registers produced to satisfy upward reporting rather than to manage risk
C	🟡	Probability weightings sound rigorous	Manufactured precision on genuinely uncertain situations
D	🔴	Escalation sounds like accountability	Penalising honesty and teaching people to fake confidence

36. What Is the Most Important Thing to Measure?

Option	Score	Why it is attractive	What it tends to create
A	🟢	Business outcomes, reliability, and safe change are what technology actually exists to produce	Measurement that connects engineering work to things that matter
B	🟡	Velocity is a familiar agile metric	Story point farming that looks productive and may not be
C	🟡	Time to market is a real business concern	Optimises for speed over quality and sustainability
D	🔴	Budget adherence sounds like financial discipline	Measuring spend rather than value

37. A Senior Architect Disagrees Publicly and Bluntly

Option	Score	Why it is attractive	What it tends to create
A	🟢	Blunt disagreement backed by evidence is a sign of health	Better decisions and a culture where truth surfaces
B	🟡	Proper channels sound professional	Teaching people that public disagreement is insubordination
C	🟡	Commitment after a decision is a real norm	Commitment used to prevent legitimate reconsideration
D	🔴	Business timelines as the final frame sounds balanced	Technical expertise subordinated to schedule compliance

38. The Role of Engineers in Decision Making

Option	Score	Why it is attractive	What it tends to create
A	🟢	Active extraction and synthesis of engineering knowledge is how the best decisions get made	Products built from collective intelligence rather than individual instruction
B	🟡	Business leaders owning commercial outcomes sounds right	Technical input as decoration on pre made decisions
C	🟡	Execution excellence and implementation autonomy sound respectful	Engineers who are good at what they are told but disconnected from why
D	🔴	Product and business teams driving strategy sounds efficient	Strategy uninformed by the technical reality that will determine whether it is achievable

39. Your Best Engineers Have Gone Quiet

Option	Score	Why it is attractive	What it tends to create
A	🟢	Silence from strong engineers is almost always a warning	Early intervention before the best people leave in spirit or in practice
B	🟡	Focus and preference for code over meetings is real	Convenient reframe that avoids the harder question
C	🟡	Team maturity and alignment sound positive	Alignment that is actually submission
D	🔴	Fewer objections sounds like improved governance	A team that has learned not to disagree with leaders who do not want to hear it

40. An Engineer Says the Deadline Is Unrealistic

Option	Score	Why it is attractive	What it tends to create
A	🟢	Engineers who raise deadline alarms are usually right	Credible timelines and teams that are not burned out shipping things that break
B	🟡	Alternative timeline with breakdown sounds constructive	Amber because the warning should be taken seriously before asking for proof
C	🔴	Commercial commitments sound binding	Teams that silently absorb impossible constraints and deliver broken software
D	🟡	Quantified risk sounds rigorous	Can become a bar set high enough that legitimate warnings are never escalated

---

Interpretation

Mostly 🟢 means you approach technology leadership with the right instincts. You understand that engineering knowledge is a strategic resource, that quality and sustainability outlast delivery theatre, and that your role is to create conditions in which strong engineers can do their best work.

Mostly 🟡 means your instincts are not dangerous but they are shallow. You rely on process, optics, and familiar governance structures because they feel responsible. Under pressure, those defaults will pull you toward comfort rather than clarity. Watch for which categories your 🟡 answers cluster in because that is where your blind spots live.

Mostly 🔴 means you optimise for timelines, reporting, and the appearance of control. You likely see opinionated engineers as a management problem rather than an intellectual resource. The technology organisations you lead will deliver on time to specifications that were wrong, retain compliant engineers who stopped caring, and struggle to understand why customers leave.

The most damaging technology leaders are not the ones who know nothing. They are the ones who know enough to sound credible while making decisions that slowly hollow out the organisations they run.

---

Inspired by Why Andrew Baker Is the World’s Worst CTO

1. The System That Built Everything

I have spent my entire career inside a single operating system. Logic first. Reality over narrative. Strip the problem down, find the root cause, fix it, move on. Do not waste time on feelings that will resolve themselves once the facts are clear. Do not slow down for comfort when speed determines survival. Do not invest in relationships that might not last when the work is more important than the warmth.

This operating system built everything I have professionally. It is why I can walk into a team that has been failing for years and diagnose the problem in hours. It is why I can strip away defensive process without flinching. It is why I can take on twelve teams in eighteen months and produce results that border on miraculous. It is why I survived algorithmic trading floors, banking crises, and 40 hour production outages without losing my nerve.

It is also why it has costs beyond work.

This article is the one I have been avoiding. It is not about teams, architecture, or corporate culture. It is about the cost of being the person who fixes those things, and about discovering, very late, that the system I relied on was never a choice. It was the only way my brain knew how to work.

2. Logic as Armour

I dealt with significant difficulties in my childhood. The details are not relevant here, but the consequence is. I learned early that emotions were a vulnerability, that the world did not care about your feelings, and that the people who survived were the ones who could see reality clearly and act on it without hesitation. Harden up. Process the facts. Move forward.

This became more than a coping mechanism. It became my entire operating model for life. At work, it was devastatingly effective. I could sit in a room full of politics, blame, and fear, and cut straight to the problem because I was not distracted by any of it. I could make unpopular decisions quickly because I was not weighed down by the social cost of making them. I could be direct, honest, and relentless because I had trained myself to believe that directness was a gift, even when it landed like a weapon.

And there is the first lie you tell yourself as a direct person. You badge it as honesty. “I speak my mind.” “I tell it like it is.” But what you are actually saying, if you are honest about the honesty, is “I do not care how this lands. Deal with it.” That is not strength. That is the absence of something, dressed up as a virtue.

The trouble is that it works. People who operate this way get results. They get promoted. They get brought in to fix things that are broken. And every success reinforces the system, making it harder to see the damage that runs quietly underneath it.

3. The Universal Application Problem

I sincerely believed, for most of my adult life, that logic was the highest order primitive. That feelings were downstream of facts, and that if you could help someone see reality clearly, the emotional turbulence would resolve itself. You would not need to manage emotions if you could manage truth.

I am the same person everywhere. I do not have a work persona and a separate persona outside of work. What you see in a boardroom is what you get everywhere else.

This consistency, which I considered a virtue, created its own set of problems. When someone is in pain and your response is to explain why the pain is not logical, you are not helping them see reality. You are telling them that their reality does not count. I did not understand this distinction for a very long time.

The operating system that made me effective professionally turned out to have significant limitations in contexts where different skills were required. Getting this wrong in personal relationships hits differently from getting it wrong at work. There is no retrospective clever enough to make this feel like a lesson rather than a wound.

4. The Capitec Chapter

When I joined Capitec, the organisation needed a radical shift in how it managed technology. There were rolling outages, significant risks, and an urgency that was impossible to overstate. I was more than happy to drop the niceties and get stuck in.

But I need to be honest about what was happening underneath the urgency. I did not invest in relationships deliberately, and the reason was not purely strategic. Part of me calculated that if it did not work out, if I left or was asked to leave, it would hurt less if I had not built connections. You can walk away from a job. Walking away from people you care about is a different thing entirely. So I kept the distance, told myself it was necessary, and used the crisis as justification for something that was actually self protection.

What we achieved in that period was extraordinary. But it was totally unsustainable. I cared deeply about the outcomes, but I did not allow my feelings to influence my behaviour at all. I operated as pure logic with a human body attached, and I paid for it with my health.

There was a second driver that I have never written about. I had unresolved feelings of disappointment about how a previous employer had treated me, and part of what fuelled the intensity at Capitec was a desire to build something so good that it would serve as a repudiation. I wanted to prove a point. That is an extraordinarily powerful fuel source and it is also poison, because the work stops being about the work and starts being about winning an argument with people who are probably not even watching.

Revenge dressed as ambition will get you further than almost any other motivator. It will also hollow you out if you let it run too long.

5. The Discovery

Late in life, I discovered that my brain is wired differently from most people. It explained everything. The logic first processing. The difficulty understanding why emotional responses did not simply resolve when presented with facts. The ability to hyperfocus on complex problems for sustained periods while struggling to divide attention across competing demands. The strong sense of fairness and rigidity that makes me exceptional at analytical problem solving and genuinely difficult in certain contexts.

What sounds obvious from the outside was invisible from the inside. I never felt different. I felt like the one person in the room who could see clearly while everyone else was being inexplicably emotional, irrational, and strange. I thought everyone else was weird. It never occurred to me that from their perspective, I was the one who was different. This, I now understand, is a Theory of Mind problem, and recognising it was liberating. Things that never made sense suddenly did, and with a fuller framing of the bigger picture it became much easier to adapt.

When I was twenty, a girlfriend’s mother nicknamed me “Android.” Not the phone. The robot. I carried that for over thirty years as an amusing anecdote, a slightly harsh but basically affectionate observation. It was not an anecdote. It was a diagnosis delivered three decades early by someone who could see what I could not.

I had spent decades assuming this was a personality I had built, a set of choices I had made, a system I had designed through discipline and experience. It was not. It was architecture. And like all architecture, it has strengths that are inseparable from its constraints.

The logic first approach got extraordinary results, and those results reinforced the system so completely that I stopped being able to distinguish between my thoughts and my feelings. My feelings became the sum of my thoughts. If the logic was sound, the feeling was correct. If the logic was clear, the emotional response was settled. This worked for decades, and it produced a person who was extraordinarily effective and almost entirely opaque to the people who needed something different from him. If your feelings are fully defined by logic, what are you? The answer that “Android” nickname was reaching for turns out to have been uncomfortably precise.

The directness that makes me effective in a crisis is the same directness that causes harm when the situation calls for patience rather than clarity. The ability to detach from emotion during high pressure events is the same detachment that does not work in contexts that require different skills. The relentless focus that lets me transform twelve teams in eighteen months is the same focus that made me unable to see the cost accumulating in every other part of my life.

These are not different traits. They are the same trait, producing different outcomes in different environments. The operating system does not have a mode switch. It runs the same way everywhere. And when you do not know that, when you believe you are choosing to be this way rather than being built this way, you cannot see the edges where the system fails because you assume you can simply choose differently when it matters. You cannot.

6. What Directness Actually Is

I want to return to directness because it is the trait I am most known for and the one I understand least honestly.

People who are direct often frame it as a service. I am giving you reality early enough that you can respond before it is too late. I am protecting you from a world that treats failure ruthlessly. I am not being cruel. I am being kind in a way that does not feel kind yet.

Some of this is true. Some of it is rationalisation. The honest version is that directness, the way I practice it, contains a core of “I do not care how this lands” that I have spent years dressing up as courage. Nobody ever bemoans winning in the long run. But there is always harm in the process of survival, and ignoring that harm, telling yourself it was necessary, treating the people who were hurt as acceptable collateral in a larger mission, makes you an arsehole. I say this with full understanding that I am describing myself.

The best leaders I have observed are direct and aware of the damage simultaneously. They do not choose one or the other. They hold both. I am still learning to do this, and I am learning it much later than I should have.

7. Logic Is Not Enough

I was recently given a piece of advice that is probably obvious to everyone else, but it caught me off guard.

If you have a strong logic bias, you explain the facts. You listen to responses. You refine the model. Eventually you arrive at a shared understanding of the problem. That feels sufficient. Clarity achieved. Alignment earned.

The assumption underneath this approach is simple: present the facts and let rational adults decide how to feel about them. But here is what I learned. If you want people to feel safe, clarity alone is not enough. It is not sufficient to present the facts and allow everyone to independently derive their emotional response. You have to be intentional about the emotional frame. You have to decide how you want them to feel about the facts.

Without that framing, ambiguity creeps in. Is this a crisis? Is this blame? Is this opportunity? Is this threat? If the leader does not shape that interpretation, the room will.

I had never consciously considered helping people choose the appropriate feeling before. I assumed reason would be enough. But helping people anchor emotionally is not manipulation. It is leadership. It removes unnecessary ambiguity. It builds trust. It increases signal and reduces noise.

Logic first leadership does not mean emotionless leadership. It means sequencing correctly. Lead with reason. Then anchor the emotional posture from which the team should act. Calm. Focused. Accountable. Curious. Determined. This level of intentionality is an upgrade to the operating system. Not a retreat from logic, but a completion of it.

8. We Bleed First

There is a principle I have operated by for a long time that I have never named publicly until now. We bleed first.

Most organisations, when something goes wrong, find a way to make the client absorb the cost. It is rarely explicit. It is structural. It happens through the architecture of pricing, through the age of the technology stack, through a culture that has normalised operational failure as someone else’s problem.

Look at how most banks price their products. The margin is built to cover inefficiency. The organisation cannot control its headcount, cannot rationalise its cost base, cannot decommission the systems that are running their operational risk into the ground, so it prices the gap away. The client pays for the dysfunction they cannot see. The organisation calls this sustainable business practice. It is not. It is a slow extraction dressed as a service model.

Look at fraud. The scammers move faster than almost every institution because the scammers have no legacy. They wake up every morning with a clean sheet. Most banks wake up every morning with a stack of vendor dependencies, upgrade cycles measured in quarters, and a security posture that was designed for a threat landscape that no longer exists. When the client gets hit, the institution absorbs some of the loss and calls it a fraud write off line. The rest lands on the client. The real cost, the experience of being defrauded, the hours trying to recover, the erosion of trust, that never appears on any balance sheet. The organisation has externalised its technical debt directly into the lives of the people it is supposed to serve.

Look at outages. If your systems go down at midnight on a Friday and your clients cannot access their money, you have not had an operational incident. You have had a betrayal. The conversation that follows internally, the post mortem, the root cause analysis, the executive update, that entire apparatus exists to process the event as a business problem. The client processed it as a personal emergency. These are not equivalent experiences and we should stop pretending the paperwork makes them equal.

The logic first version of me wants to frame all of this as a systems problem. And it is. But the deeper issue is one of will. The organisations that let clients absorb the cost do so because the internal incentive structures do not punish it sufficiently. Nobody loses their bonus because a client had a terrible week. The pain is distributed outward and the metrics look acceptable.

If you actually want happy clients, you have to reverse the direction of the pain. You take the hit first. Your pricing reflects your efficiency, not your inefficiency. Your fraud prevention moves faster than your roadmap cycle because you have made it structurally impossible to fall behind. Your systems are modern enough that an outage is a genuine surprise rather than a scheduled embarrassment.

This posture creates significant internal tension. The moment you start arguing that the client should not absorb the organisation’s cost failures, you will be told that this is how it has always worked. You will be told the numbers do not support it. You will be positioned as unreasonable, as someone who does not understand the commercial realities, as a person who is making simple things complicated. These conversations are not comfortable and you will not be popular while you are having them. You are opening hot topics that have been deliberately left closed because closing them was easier than solving them.

Stay in it. The friction is not a signal that you are wrong. It is a signal that you are threatening something that has worked well enough for a long time and that the people who built it do not want to see it restructured. That is a different thing entirely.

What you have to be careful about is the season. The period of fighting for your clients, of absorbing the cost, of taking the weight that should never have been passed to them in the first place, that is not a permanent operating mode. It is a transitional one. You do it until your clients are being properly served. You do it until the pricing reflects genuine value, the fraud controls are ahead of the threat, and the systems are stable enough that reliability is expected rather than celebrated. Once you get there, you transition out of the season. You cannot run an organisation indefinitely on the energy of fighting for what should have been baseline. You normalise it and you move on.

But you have to go through the season first. And most organisations never do, because the people who would have to absorb the cost internally are the same people deciding whether to absorb it. That conflict of interest is the real reason clients keep bleeding.

We bleed first is not a slogan. It is a test of whether the organisation’s loyalty runs in the direction it claims. Most of the time it does not, and the gap between the stated values and the structural reality is where client trust goes to die quietly over many years.

9. Things I Carry

There are decisions from earlier in my career that I carry silently and will probably never explain publicly. They are not lessons. They are not stories with clean endings. They are weights that sit in a place where analysis cannot reach them.

I mention this not to be mysterious but to be honest about something that leadership literature almost never acknowledges: some experiences do not convert into wisdom. They do not become anecdotes for a keynote or frameworks for a blog post. They just stay with you, unresolved, and the best you can do is make sure they inform your judgment without consuming your identity.

The pressure to turn every difficult experience into a narrative with a redemptive arc is immense, especially for people with public profiles. Resist it. Some things are just hard, and pretending they made you better is its own kind of dishonesty.

10. What I Would Tell a Younger Version of Myself

I do not allow retrading. I made the best calls I could each day with the information I had, and I trust that the version of me who woke up each morning did the same. I would not change a thing, because changing anything requires a crystal ball, and if I had one of those I would not need to work in the first place.

But if I could whisper something to the version of me who was building his career and building his identity around the conviction that logic would solve everything, it would be this: the system works brilliantly and it has edges you cannot see yet. The things it cannot process are not weaknesses in other people. They are gaps in you. And by the time you discover them, the cost will already be significant.

You are not choosing to be this way. You are built this way. That does not excuse the damage, but understanding it earlier would have let you build compensating structures sooner, not for work, where the system performs beautifully, but for the contexts where logic alone is insufficient.

11. Why I Am Writing This

I write about corporate culture, leadership failure, and organisational dysfunction with a confidence that borders on contempt. I have torn apart frameworks, methodologies, and leadership archetypes with precision and, if I am honest, with enjoyment.

It would be dishonest to continue doing that without turning the same lens on myself. Not in the charming, self deprecating way of asking ChatGPT to write about why I am the world’s worst CTO. That was fun and it was also armour. This is different.

This is an acknowledgment that the operating system that built my career did not work everywhere I applied it. That the logic first worldview which makes me effective in a crisis is not what is needed in the places where effectiveness is the wrong metric. That directness, stripped of empathy, is just aggression with better vocabulary. And that discovering, very late, why I am wired this way has not fixed anything, but it has given me a framework for understanding the failures that no amount of intelligence could prevent.

Intelligence asks can we do this. Wisdom asks should we do this. I wrote those words in a previous article and believed them completely. What I did not say is that I spent most of my life trapped in the first question, and the second question only became visible after the cost had already been paid.

12. The System Still Runs

I have not totally changed the operating system, I do not know if I can. Logic is still the first thing that fires. Directness is still my default. Hyperfocus still consumes me when a problem is interesting enough, and the people around me still have to wait until the focus releases.

What has changed is that I know the system has edges. I know that what feels like clarity to me, can feel like dismissal to someone else. I know that the ability to detach from emotion is a tool, not a virtue, and that deploying it in every context is not the same as deploying it in a war room. I know that some people need to be heard before they need to be fixed, and that hearing them is not a waste of time even when the fix is obvious.

I am not good at any of this yet. But I am aware of it, and awareness is the precondition for change, even if change is slow, uneven, and nowhere near complete.

The operating system still runs. It still builds extraordinary things. And it still has a cost. The difference is that I can see the invoice now, and I am no longer pretending it does not exist.

Andrew Baker / 11 February 2026 / Corporate Culture

1. The Uncomfortable Silence After the Music Stops

Every organisation that runs on defensive process has a soundtrack. Standups hum at 9am. Sprint reviews crackle on Fridays. Retros generate their familiar low frequency guilt. Planning ceremonies fill the gaps. Remove all of it and the first thing you hear is silence, and silence in a corporate environment is terrifying because it forces a question that most people have been trained to avoid: what are we actually supposed to be doing?

The emotional response to stripping away process is never uniform. It splits immediately and the split is revealing. Some people come alive. These are the ones who were quietly suffocated by the scaffolding, who knew the ceremonies were theatre, and who had been carrying the frustration of watching real work get buried under administrative performance. For them, the silence is not emptiness. It is oxygen.

Others collapse inward. These are the process guardians, the people whose identity, authority, and daily structure were inseparable from the frameworks they administered. When the framework disappears, they do not lose a tool. They lose a role. They feel invalidated, exposed, and deeply vulnerable, and that vulnerability is real, not theatrical. These are often good people who built their careers around something the organisation told them mattered. It is not their fault that it didn’t.

Both reactions are valid. Both are present in every team simultaneously. And managing this emotional fracture without either dismissing it or drowning in it is the first real leadership challenge of building a naked team.

2. Nothing Is Sacred, but Not Everything Is Theatre

Before going any further, I need to correct a misreading that this kind of article invites. Stripping away defensive process is not the same as stripping away all process. That distinction is everything.

A feedback loop is a process. Design reviews are a process. Automated testing gates are a process. Architecture governance that forces domain isolation and creates evolutionary pressure on teams is an extraordinarily demanding process. None of these are removed. Many of them are improved, tightened, or introduced for the first time.

What gets removed is process that exists to defend the organisation from accountability rather than to improve outcomes. The difference is not always obvious from the outside, which is why you cannot approach this with a machete. You have to unpack what you are dismantling before you dismantle it. If you hack at processes without understanding what they are doing, you will disorientate the team and burn trust. If in doubt, leave the process in place and come back to it later. Oscillating destroys credibility faster than bad process ever could.

The principle is not elimination. The principle is that nothing is sacred and everything must earn its place. What survives is intentional. What is removed was not. And what replaces it is often more rigorous than what came before, just rigorous about different things.

3. Start With a Cause, Not a Structure

The instinct after removing process is to replace it with different process. Resist this completely.

The first thing a stripped back team needs is not a new framework, a new board, or a new set of rituals. It needs a cause. A reason to exist that is larger than the mechanics of how it operates. Specifically, it needs an Everest, a problem that the organisation has failed to solve, one that is existential or close to it, something big enough that the answer cannot be found inside the old ways of working because if it could, it would already be solved.

This is deliberate. You do not strip away process and then ask teams to do the same work they were doing before, just without the sticky notes. That creates a vacuum. You strip away process and then point at a mountain that nobody has been able to climb. The mountain provides the urgency. The urgency provides the structure. And the structure that emerges from genuine urgency looks nothing like the structure that was removed, because it is shaped by the problem rather than by organisational comfort.

4. Break the Mountain Into Steps and Take Risks to Get There

An Everest that remains monolithic is paralysing. The next move is decomposition, not into sprints or backlogs, but into short, deliverable steps where progress is visible and real. Each step should be achievable quickly enough that momentum builds before doubt sets in.

This is where risk enters the picture, and risk is the ingredient that process was specifically designed to eliminate. Defensive process exists to ensure that nothing unexpected happens. Naked teams exist to ensure that something does. You take calculated risks. You move faster than feels comfortable. You accept that not every step will land cleanly.

When things go wrong, and they will, it must be a small discreet failure. The steps are short enough that failure is contained, visible, and recoverable. The team also needs to learn how to bounce back and see that failure that does not destroy them. They need to see a leader who responds to a stumble by helping them stand up rather than convening a review board. Each small failure that is handled well builds more trust than any amount of success, because it proves that the new world is not a trap.

And when you score, and you will, the momentum is extraordinary. Teams that have been trapped inside defensive process for years have often forgotten what genuine progress feels like. The first real win, the first time something lands in production and makes a visible difference, is electric. It rewires the team’s relationship with work.

5. Exit Constraints Before You Assess Capability

Before you can evaluate what a team is capable of, you have to remove the constraints that are suppressing their capability. These constraints are often invisible to the team itself because they have been normalised.

The most common constraint I encounter is approval addiction. Teams believe they need sign offs from dozens of people before they can do anything. They create elaborate documentation not because it improves outcomes but because it provides air cover. They spend weeks seeking permission for work that should take days to execute. This entire apparatus exists to protect the organisation from blame, not to protect clients from failure.

On day one, I exit all of it. The question becomes simple: what are you trying to do and what evidence do you have that you will be successful? That is the only gate. If the evidence is strong, move. If it is weak, strengthen it. No committee required.

But removing approval culture is not the same as removing standards. This distinction matters and getting it wrong is how simplification becomes recklessness. I look at a team’s track record in executing change. If it is poor, I block them from production until they meet an agreed testing bar. We then rebuild their test environments, create automated testing scripts, and establish a path to production that is engineered rather than governed. The constraint shifts from human approval to technical evidence. The bar does not drop. It moves from bureaucratic to empirical.

Other constraints vary. Funding structures that prevent movement. Compliance requirements that have calcified into ritual. Infrastructure that makes deployment a three week event. Shared services that respond on geological timescales. My first job is to identify and exit every constraint that stands between the team and the mountain. My second job is to assess what we are actually working with once those constraints are gone.

Teams often carry a piano on their back and wonder why they are struggling. My job is to allow them to leave it behind.

6. Small Groups. Real Impact.

The Manhattan Project. Bletchley Park. Apollo Mission Control. Bitcoin. Name them. Every one of these was driven by a small, highly capable group of people who changed the trajectory of the world. A tight group of physicists at Los Alamos built the atomic bomb. A focused cluster of cryptanalysts at Bletchley broke Enigma. A disciplined team in Houston made the real time decisions that put a man on the moon. Bitcoin began with a single person publishing a whitepaper.

These groups did not succeed because they had scale. They succeeded because they had purpose, focus, and backing, and because someone trusted them enough to let them solve the problem without drowning them in oversight.

Now contrast that with what happens inside large corporations when things start to go wrong. When results weaken, process expands. When progress slows, reporting multiplies. When clarity drops, governance increases. Instead of concentrating capability into a small group and pointing it at the problem, organisations diffuse energy across ceremony. Process begins to defend poor outcomes rather than fix them. It absorbs accountability. It creates motion without ever producing momentum.

Small teams are exposed to reality. There is nowhere to hide when six people own the outcome and the feedback is immediate. Large organisations can hide inside workflow, inside status updates, inside quarterly reviews that describe failure in the language of progress.

Purpose and focus create breakthrough. Process without capability creates insulation.

7. There Is No Such Thing as an Immature Team

The technology industry is addicted to maturity models. Teams are assessed, scored, and categorised. Low maturity teams receive more governance. High maturity teams receive more freedom. The model feels rational and fair. It is neither.

Maturity is a leadership excuse to treat some teams worse than others. I do not believe teams are immature as such. They can be inexperienced or misdirected, but the word maturity implies a fixed state, a ceiling, a reason to wait. Every team I have ever worked with had the potential to be successful. The question was never whether they could get there. The question was what was preventing them from getting there, and the answer was almost always one of two things: the leadership above them or one or two individuals inside them.

Sometimes the answer is to add engineering skills and weaken management structures. Sometimes it is the reverse. Sometimes a team needs extreme structure applied selectively to solve a chronic weakness, and in those cases I apply it without hesitation. The point is not that structure is always bad. The point is that the prescription must fit the condition, and the condition is almost never “the team is immature.” It is almost always “the team has been poorly led, poorly composed, or poorly directed.”. So when we say a team is immature, what we are actually saying is that the leadership is failing. If you frame it like this the term vanishes overnight!

This matters because maturity models let organisations defer responsibility. If the team is immature, it is the team’s problem. If the team is misdirected, it is a leadership problem. The distinction determines where the fix lands, and maturity models reliably land it in the wrong place.

So whats the process to recover these teams? I have never use a fixed approach. The principles are similar each time, but the application varies. What I can say is that you start to spot patterns with the types of failures, and they almost always stem from the top, not the bottom.

8. Replace Ceremony With Reality

Once you remove standups, sprint reviews, retrospectives, and burndown charts, you need something in their place. Not a lighter ceremony. Not a more agile version of agile. You need reality.

At Capitec, we built something called ELS, our Error Logging Service. Every single time a product team presents a client with a generic error screen, a “something went wrong” moment, the system records it. Not in a log file that nobody reads. Not in a dashboard that gets reviewed once a quarter. It records it immediately, in detail, and surfaces it to the teams responsible.

Each error generates a diagnostic ticket. An AI model running on AWS Bedrock analyses the HTTP request chain, identifies the root cause, and produces a structured assessment that tells you exactly what failed and why. A profile service returning a status code zero at the fifth step of a Send Cash transaction is not ambiguous. It is a network connectivity failure or a service outage at a specific endpoint, and the diagnostic says so within seconds.

The summary view groups errors by frequency and page. When your domain is generating 800 errors per hour and the entire organisation can see which pages are failing and how often, there is no need for a scrum master to tell you how your sprint is going. Your clients are telling you directly, at machine speed.

This is what replaces ceremony. Not a different meeting. Not a better board. A system that makes reality unavoidable. Burndown charts measure compliance with a plan. ELS measures whether clients are suffering. Teams do not need to be told to act when they can see, in real time, that they are failing the people they exist to serve.

The feedback loop must be functioning, not performative. Praise alone is not enough. Progress must be visible to the team itself, not reported upward through a chain of status updates. When teams can see their own impact, directly and immediately, the motivation problem disappears. You do not need to manufacture urgency when reality provides it.

9. Let the System Heal Itself

The hardest discipline for a leader in this environment is restraint.

When the old process is removed and the process guardians are sitting in their discomfort, the temptation is to intervene, to coach, to reassure, to manage each person through the transition individually. I deliberately do not do this. I allow the person to sit in their emotions and to observe what is happening around them.

What I attack is what was created under their watch, not the person who created it. I focus relentlessly on speed, simplicity, and quality. I demonstrate through action what the new standard looks like, and then I watch each person’s response.

Teams, when trusted, create their own order. They heal. The people with genuine capability find new footing because the new environment rewards contribution rather than compliance. The people who were hiding behind process are revealed, but not by me. They are revealed by the contrast between what was and what is now possible.

My role in this phase is to acknowledge progress and actively encourage risk taking. I do not do individual coaching sessions with large teams. I take large groups on together and let the group dynamic do the work. That said, people do come to speak with me individually, and I am always happy to share, to open up, and to reassure where necessary. The door is open but I do not push anyone through it.

I have almost never had to fire or dismiss anyone through this process. People either find their place in the new order or they self select out. I do not believe in fear as a motivational tool. I do not like grovelling, performative loyalty, or leadership praise. We are all just humans doing work, and nobody is special, including me.

10. The Transition Is Not Cold Turkey

A reasonable question at this point is whether stripping away process means walking into a room on Monday morning and announcing that everything the team has known for the last five years is cancelled. The answer is no, and doing that would be as dogmatic as the frameworks being replaced.

Most people who work inside Agile ceremonies do not have a religious attachment to them. A process is just a process, and when something more efficient and more honest replaces it, most people transition quickly and with visible relief. If someone wants to keep their work in Jira because that is how they organise their thinking, I genuinely do not care. The tool is not the problem. The problem is when the tool becomes the thinking, when creativity and judgment are anchored in process dogma rather than freed by it.

The people who struggle most are not the ones who used Agile. They are the ones who became Agile. People who have invested years attending conferences, collecting certifications, and building an identity around a methodology will experience its removal as an existential threat. Their grasp on it is so strong that letting go feels like losing themselves. I have empathy for this, but I cannot let it govern the pace of change. What I can do is give people space to make the adjustment, and most of them do.

The transition works because the replacement is visible. When teams start climbing, when errors drop, when clients are better served, and when the evidence is undeniable, most process attachment dissolves on its own. You do not need to argue people out of a belief system. You need to show them something better.

11. The Personal Cost of Doing This at Scale

There is a version of this story that ends cleanly. One team, six to twelve months, a visible transformation, everyone learns and grows. I have done that version and it works beautifully.

Then there is the version I lived through at Capitec after the 40 hour outage that was widely reported in the South African media. I looked at the scale of what needed to change and I took on too much at once. Not one team. Twelve teams in eighteen months. Multiple large problems running in parallel, each demanding the same intensity, the same presence, the same emotional labour.

It was personally very painful. It made me unwell. My family suffered.

I am not going to reframe this as a learning experience or extract a tidy lesson about pacing and boundaries. I do not allow retrading. I made the best call at that point in time with everything I knew. I could have pivoted and I chose not to. Therefore I trust that the version of me who woke up each morning made the right calls with the information available on that day.

If you ask me what I would have done differently, the answer is nothing, unless I had a crystal ball, in which case I would not need to work in the first place.

The cost was real. I paid it. The teams are better. The systems are better. The clients are better served. Whether the price was right is not a question I am interested in answering retrospectively.

12. What Naked Teams Actually Look Like

A naked team, fully formed, does not look chaotic. It looks calm. It has a clear domain. It has a direct path to production. It has automated testing that provides confidence without requiring human approval chains. It has real time visibility into how it is serving its clients. It has a mountain it is climbing and it can see the progress it is making.

It does not have a scrum master, a sprint cadence, a burndown chart, or a retrospective. It does not have a 97 slide deck explaining its operating model. It does not have a RACI matrix.

What it has is ownership that was earned through action rather than declared through governance. What it has is speed that comes from engineering rather than from frameworks. What it has is quality that is enforced by machines rather than by meetings.

The silence that was terrifying in week one becomes the sound of a team that knows exactly what it is doing and does not need to perform the act of knowing it.

13. Conclusion: Stripping Back Is Not Destruction

Removing defensive process is not an act of destruction. It is an act of trust. Trust that the people in the team have capability that was suppressed. Trust that reality, made visible, is a better motivator than ceremony. Trust that problems, honestly confronted, get solved faster than problems wrapped in governance.

It is also an act of discernment. Not everything gets removed. What survives is intentional. What is added is deliberate. What is removed was never earning its place. The rigour does not decrease. It changes shape, from performative to empirical, from ceremonial to engineered, from defensive to honest.

The piano was never helping them climb. It was just heavy, familiar, and nobody had given them permission to put it down.

Give them the permission. Point at the mountain. And then get out of the way.

1. Ownership Has Been Turned Into a Moral Shortcut

Ownership has become one of the most lazily celebrated concepts in modern organisations. Leaders demand it reflexively, teams chase it performatively, and entire operating models are justified by invoking it as if ownership itself produces outcomes. It does not. Ownership is merely a structural choice, and when that structure is poorly designed it actively works against execution, accountability, and most importantly the client. The uncomfortable truth is that many organisations are not suffering from a lack of ownership at all, but from badly applied ownership that creates the illusion of progress while quietly degrading everything underneath.

2. End to End Ownership Is a Comforting Fiction

The idea of end to end ownership sounds decisive and mature, but in large organisations it is almost always a fiction that collapses under scrutiny. Product teams claim full ownership and then, either explicitly or by slow organisational creep, begin to recreate the entire company inside their vertical. HR functions appear inside product teams, finance controls get duplicated, cyber rules diverge, fraud logic fragments, and KYC processes quietly multiply. What is framed internally as empowerment becomes externalised as chaos.

From the client’s perspective, this is a disaster. The same human is forced to complete multiple product specific KYCs, contact details drift across systems, risk assessments contradict one another, and trust erodes because the organisation no longer behaves like a single entity. Internally, the cost base inflates, scarce specialist skills are diluted, and the organisation becomes heavier while convincing itself it has become faster. This is not ownership delivering value; it is ownership used as justification for fragmentation.

3. Weak Ownership Produces Motion Without Resolution

At the opposite extreme, weak or ambiguous ownership creates a different but equally corrosive failure mode. When nothing is clearly owned, nothing is ever truly fixed. Issues circulate endlessly between teams, each handoff accompanied by explanation, context, and increasingly defensive narratives. Meetings multiply, artefacts grow thicker, and everyone stays busy while the underlying problem remains untouched.

What makes weak ownership so dangerous is that it does not feel like failure. It feels like activity. People learn to survive by explaining rather than resolving, by managing perception instead of outcomes, and by optimising for personal safety rather than systemic improvement. Over time, the organisation becomes extremely good at describing problems and extremely bad at eliminating them.

4. The Sweet Spot Is Designed, Not Discovered

Healthy ownership models are never accidental. They are intentional structures built with a clear understanding of which capabilities must be shared and which outcomes must be owned. Certain functions simply do not benefit from fragmentation. Digital channels, cyber security, fraud platforms, finance, and HR improve through consistency, concentration, and scale. They get stronger when they are shared, not when they are cloned into every product silo under the banner of autonomy.

Products should own client outcomes, adoption, and value delivery, but they should consume shared capabilities that evolve faster precisely because they are centralised. The real challenge is cultural, not structural. Strong shared platforms only work when product leaders trust them, and that trust only exists when leadership resists the temptation to let teams rebuild the world in miniature for the sake of perceived control.

5. Ownership Should Never Drive Technical Architecture

One of the most damaging side effects of ownership theatre is when it is allowed to dictate technical architecture. Ownership is an organisational concern, not an architectural primitive, yet many systems are fractured purely to flatter product boundaries rather than to serve durability, simplicity, or client experience. A document domain is a good example of this failure mode. Instead of maintaining a coherent, durable document platform, organisations split documentation into heterogeneous product specific domains simply so each product can claim ownership.

This creates duplication, inconsistency, and long term fragility, all while pretending to improve autonomy. The correct solution is rarely to fracture the domain. A single document platform with strong metadata, tagging, and access controls can give every product the precise view it needs without destroying the integrity of the underlying system. Architecture should optimise for coherence, reuse, and longevity, while ownership should sit above it as a governance and accountability layer. When these two are inverted, technical debt is guaranteed.

6. Product Excos Institutionalise Entitlement

Product executive committees are one of the most consistently toxic structures in large organisations. They create artificial sovereignty, inflate self importance, and slowly detach product leaders from the reality that they are stewards of client value rather than owners of territory. Over time, these forums reward flag planting over problem solving, visibility over effectiveness, and ownership claims over measurable improvement.

In these environments, owning an issue becomes more valuable than resolving it. Leaders compete to be seen as accountable while quietly preserving the existence of the problem itself. The client fades into the background as internal status games take centre stage, and the organisation congratulates itself on governance while outcomes deteriorate.

7. Ownership vs Customer Experience

In a startup with one product and one app, end to end ownership feels clean. One codebase. One backlog. One deployment pipeline. But that only works when you have one thing.

When you expand, the question becomes obvious: do you launch a new app for every new product? Do you make customers register and log in on every channel to interact with you? That isn’t customer-centric design, that’s organisational narcissism masquerading as “ownership.”

Digitally native products increasingly live inside other people’s platforms because that’s where the customer already is. The goal isn’t to maximise internal control; it’s to maximise relevance and convenience. This means tolerating lower ownership in service of the customer, eliminating swivel-chairing between apps, and reducing friction. Control is a means, not the objective.

If you want to offer a car loan, the most client-centric place to do it isn’t inside your own banking app. It’s inside AutoTrader at the moment someone is choosing a car. That’s not weakness, it’s strategic focus. Once ownership becomes the constraint, you optimise for yourself, not your customer.

8. Clients Experience Journeys, Not Products

Clients do not care about your organisational boundaries, your ownership model, or your internal narratives. They experience journeys, coherence, and trust, and they judge you on whether interacting with you feels like dealing with one institution or many loosely coordinated ones. Products exist to serve clients, not the other way around, and any ownership model that forces repetition, reauthentication, or relearning is fundamentally broken regardless of how clean it looks in a deck.

When ownership is designed around internal comfort rather than external experience, the client always pays the price, usually long before leadership notices.

9. Fix the Problem First, Worry About Ownership Later

When a real issue is discovered, the instinct to immediately plant an ownership flag is almost always the wrong move. Declaring ownership feels decisive, but it subtly shifts attention away from resolution and towards structure, advocacy, and territory. The organisation starts asking who owns the problem instead of how quickly and correctly the problem can be fixed, and from that moment the outcome is already compromised.

The healthier response is far less theatrical and far more demanding. Bring the best people you can get into a room, irrespective of reporting lines, titles, or which box they sit in on the org chart, and focus entirely on fixing the issue. Do not pre partition the narrative by assigning agency and advocacy upfront. Do not turn the problem into a token that must be carried by a single function. Just offer help, roll your sleeves up, and stay present until the solution is moving in the right direction.

Strong cultures heal around problems when they are trusted to do so. They naturally pull in the right expertise, the right challenge, and the right pressure when leaders resist the urge to control the story. Ownership emerges after resolution as a by product of action, not before it as a declaration of intent. This is how organisations learn, rather than ossify.

The most corrosive behaviour is when leaders push a pawn forward, declare that the issue is now owned, and mentally check out as if their contribution is complete. Ownership is not the end of involvement. It is the beginning of responsibility. If you are not still engaged when the trade offs are made, the hard decisions are taken, and the consequences are absorbed, then what you pushed forward was never ownership at all, just distance disguised as governance.

10. Ownership Should Eliminate Problems, Not Label Them

The purpose of ownership is to reduce waste, complexity, and failure, not to assign names to unresolved mess. Organisations that celebrate ownership without demanding resolution inevitably turn into landfills of unresolved issues, each proudly marked, carefully managed, and quietly allowed to rot. Leaders stand on top of these piles planting flags, mistaking declaration for delivery.

Strong organisations are not obsessed with who owns a problem. They are obsessed with why the problem still exists. That difference is subtle, uncomfortable, and decisive, and it is the line between performative ownership and real accountability.

11. Conclusion: Ownership Is a Tool, Not an Identity

Ownership was never meant to be a virtue in itself. It is a design choice, a means to an end, and when it becomes an identity it stops serving the organisation and starts serving egos. Weak ownership creates endless motion without progress, while over indexed ownership fractures the organisation into competing fiefdoms that optimise locally and fail globally. Both failure modes look different internally, but to the client they feel the same: repetitive, incoherent, and exhausting.

The organisations that scale with integrity are the ones that design ownership deliberately rather than ideologically. They share what must be shared, they centralise what improves through consistency, and they hold products accountable for outcomes without allowing them to rebuild the company inside themselves or fracture technical architecture for the sake of perceived control. They reject the theatre of ownership flags and focus instead on the harder work of eliminating the conditions that create problems in the first place.

When ownership is treated as a responsibility to resolve rather than a right to claim, structures get lighter, systems get simpler, clients get cleaner experiences, and leaders stop mistaking control for progress. That is the difference between organisations that merely look accountable and those that actually are.

1. Fear, Motion, and the Illusion of Progress

In the last few months I’ve come up with two of the most powerful fraud controls of my career. Not in a workshop. Not in a brainstorm with sticky notes and a facilitator. I walked to the car park, lay down in my car, closed my eyes, and tried to frame the problem differently, from a client’s perspective rather than a banking one. Both times, the answer arrived within about twenty minutes of doing absolutely nothing. If anyone had walked past and seen me horizontal in a Fortuner at 2pm on a Tuesday, they’d have assumed I was either napping or having some kind of episode. In fact, I was doing the most productive work I’d done all week.

I mention this because it’s a perfect illustration of something most organisations have got completely backwards.

In the previous article on fear and seasons of leadership, the core idea was simple but uncomfortable: most organisations aren’t slow because of constraints, they’re slow because they’re afraid. And fear has a favourite disguise: motion.

Calendars fill up, backlogs multiply, dashboards glow a reassuring green, and everyone is busy while nobody is thinking. The organisation is running flat out, but it’s not actually hunting anything. It’s just… running.

This is where boredom enters the picture, and where things get interesting.

Boredom is what happens when the immediate threat disappears and nobody is screaming at you. In fear driven cultures, that emptiness feels dangerous. It gets filled immediately with another meeting, another initiative, another “quick sync.” But boredom, that uncomfortable silence when nothing is on fire, is actually the only state where foresight, innovation, and real judgment have any chance of forming.

Kill boredom, and you kill the organisation’s ability to see what’s coming. You just won’t notice until it arrives.

2. Operational Saturation and the Collapse of Foresight

I’ve watched this pattern play out more times than I’d like to admit, sometimes in teams I was responsible for. A team becomes operationally saturated, with every ounce of cognitive capacity spent responding to the present. They ship constantly, attend endlessly, and react perpetually. What they don’t do is think.

The consequences are predictable: innovation dies because novelty needs unused mental bandwidth, foresight collapses because anticipation requires some distance from the immediate moment, and strategy becomes retrospective, written after events have already materialised, which isn’t really strategy at all. It’s a post mortem dressed up in a slide deck.

These teams aren’t navigating the future; they’re being tossed around by whatever lands on them next. Every surprise feels external and every shock feels unfair, but the signals were always there. Perception requires slack, and without slack there is no horizon. You’re just staring at your shoes while you run.

Boredom isn’t laziness. It’s unused operational capacity, and unused capacity is the only place where perception lives.

3. Why Boredom Feels Uncomfortable to Leaders

Here’s the bit I find hardest to write about honestly, because I’ve been this leader.

A team that isn’t visibly busy feels unsafe, a calendar with white space feels like exposure, and a quiet standup feels like something is wrong. This is leadership anxiety, not a delivery reality, but it feels indistinguishable from the real thing when you’re the one sweating.

High performing teams often appear calm because they’re not saturated. They have space to notice weak signals, question assumptions, and think in systems rather than tickets. To leaders conditioned by fear (and if you’ve spent twenty years in financial services, you’ve been conditioned by fear), this calm looks like underutilisation. In truth, it’s readiness.

Boredom forces leaders to confront an uncomfortable question: if my team isn’t reacting, what am I actually here to do? For many of us, motion has quietly replaced judgment, and removing motion exposes the gap. The gap is not flattering.

4. Reflection as the Engine Inside Boredom

Boredom on its own isn’t magic, and left unchecked it degrades into drift. People browse LinkedIn, reorganise their desktops, and start wondering whether they should learn Rust. (They probably should, but that’s beside the point.)

Reflection is what converts empty space into advantage.

Reflection is the deliberate act of pausing to analyse experience. Experience alone is raw data, and reflection is the process that turns that data into understanding, judgment, and eventually something approaching wisdom. John Dewey captured this better than I can: we don’t learn from experience; we learn from reflecting on experience.

Boredom creates the space, and reflection determines whether that space compounds or decays.

5. From Experience to Wisdom

I think of reflection as editing. Mindfulness, if you’ll forgive the slightly overused word, captures high definition footage of thoughts, emotions, and reactions as they happen. Reflection edits that footage into meaning, and without the edit, experience remains noisy and repetitive. You keep filming the same scene over and over without ever watching the rushes.

There’s a neurological basis for this: reflection engages the prefrontal cortex, integrating emotional input with long term reasoning, and this is how short term reactions become durable learning. When reflection is paired with awareness, it creates a feedback loop that improves emotional clarity and decision quality, so that experience stops looping and starts compounding.

Teams without reflection repeat incidents, while teams with reflection extract lessons. The difference isn’t intelligence; it’s pause.

6. Reflection, Self Mastery, and Leadership Depth

Without reflection, people live but don’t learn. The same mistakes recur, justified by new circumstances but driven by identical patterns. I can say this with some authority because I have a well stocked archive of personal examples.

Through reflection, patterns emerge, triggers become visible, and reactions become predictable. This awareness shifts behaviour from reactive to intentional, widening the space between emotion and action, and in that space lives whatever leadership actually is.

For leaders, reflection produces humility because it reveals bias, blind spots, and habitual shortcuts. I know mine better now than I did ten years ago, which is another way of saying I was blissfully unaware of them for a decade. This isn’t weakness; it’s the foundation of something closer to authentic authority. Leaders who reflect don’t posture certainty, they develop judgment, and in my experience teams trust judgment far more than they trust confidence. They can smell the difference.

7. Practical Structures for Reflection at Scale

Reflection doesn’t require retreats, meditation bowls, or inspirational posters in the kitchen. It requires structure.

The simplest model I’ve found useful is What, So What, Now What. What happened, without the narrative or the defence mechanism. So what mattered, without blame. Now what changes, without the vague commitments that evaporate by Wednesday.

Micro reflection matters. Sixty seconds after an event to ask “what did I notice?” or “what did I learn?” doesn’t sound like much, but it builds a habit of awareness. Over time, this compounds into pattern recognition. It’s the cheapest investment in leadership development I’ve ever encountered, and it doesn’t require a consultant.

Journaling slows cognition in a useful way because writing forces precision, and thoughts that feel complex and nuanced in your head often dissolve into incoherence when you try to articulate them. I know this because most of my draft blog posts start as what I thought were brilliant insights and end up being gently rewritten three times before they make any sense. Leaders who write think better because they’re forced to confront incoherence rather than hide behind it.

The future self method is one I find particularly useful. Asking how a wiser future version of yourself would have handled the situation shifts reflection from regret to design, building agency instead of rumination. It’s humbling, because the answer is almost always “with more patience and less email.”

8. The Discipline of Discomfort

True reflection is uncomfortable because it requires honesty when momentum would be easier and slowing down when the organisation rewards speed. This is why high achievers often avoid it: motion protects the ego, while reflection challenges it.

I’ve lost count of the number of times I’ve chosen to be busy rather than sit with an uncomfortable question about whether a decision I made was actually wrong. Busyness is an excellent anaesthetic.

Wisdom doesn’t arrive in moments of intensity; it forms in moments of stillness. Reflection must be habitual rather than episodic, and daily or weekly rituals matter more than dramatic offsites. Unlike knowledge, wisdom can’t be imported, and no framework, consultant, or tool can substitute for reflected experience. You can’t buy it. You can only earn it, slowly, by being willing to sit in the discomfort of your own imperfection.

9. Boredom as a Strategic Asset

Boredom isn’t the absence of work; it’s the absence of fear driven urgency, and it’s the signal that an organisation has room to think.

Teams that are never bored are blind. Teams that are sometimes bored can see.

If fear keeps you running, boredom allows you to choose direction, and if saturation keeps you reactive, reflection makes you anticipatory.

The power of boredom isn’t that nothing happens. It’s that something finally has the chance to. Sometimes that something is lying in a car park at 2pm, staring at the roof of your car, and realising you’ve been solving the wrong problem for six months.

A Self Assessment for Technology Leaders

This questionnaire explores how you think about technology leadership, systems, teams, and delivery. There are no right or wrong answers. Each question presents four options that reflect different leadership styles and priorities. Simply select the option that best reflects your natural instinct in each situation.

Select one answer per question. Do not overthink it. Your first instinct is what matters.

1 Leadership Philosophy

Question 1. A major platform decision was approved by the steering committee six months ago. New evidence suggests it may be the wrong choice. What do you do?

A) Revisit the decision with the new evidence and recommend a course correction even if it causes short term disruption

B) Flag the concern but continue execution since the committee already approved it and reversing would delay the programme

C) Raise it informally but keep delivery on track since the timeline commitments to the board cannot slip

D) Continue as planned because reopening approved decisions undermines confidence in the governance process

Question 2. Your team proposes simplifying a system by removing an integration layer. It will reduce complexity but invalidate three months of another team’s work. How do you proceed?

A) Protect the other team’s work and find a compromise that keeps both approaches since we need to respect the investment already made

B) Evaluate the simplification on its technical merits regardless of sunk cost and proceed if the outcome is better for customers

C) Delay the decision until next quarter’s planning cycle so it can be properly socialised across all stakeholders

D) Proceed only if the simplification can be shown to accelerate the current delivery timeline

Question 3. You inherit a technology organisation with seven management layers between the CTO and the engineers writing code. What is your first instinct?

A) Understand why each layer exists and remove any that do not directly contribute to decision quality or delivery outcomes

B) Add a dedicated delivery management function to coordinate across the layers more effectively

C) Maintain the structure but introduce better reporting dashboards so you can see through the layers

D) Restructure the layers around revenue streams so each layer has clear commercial accountability

Question 4. What is the primary purpose of a technology strategy document?

A) To secure budget approval by demonstrating alignment between technology investments and projected revenue growth

B) To reduce uncertainty by clarifying what the organisation will and will not build, and why

C) To provide a roadmap with delivery dates that the business can hold the technology team accountable to

D) To communicate the technology vision to non technical stakeholders in a way they find compelling

2 Architecture and Systems Thinking

Question 5. What does the term blast radius mean in the context of systems architecture?

A) The scope of impact when a single component fails, and how far the failure propagates across dependent systems

B) The amount of data lost during a disaster recovery event before backups can be restored

C) The total number of customers affected during a planned maintenance window

D) The financial exposure created by a system outage, measured in lost revenue per minute

Question 6. When designing a critical system, which of the following should be your primary architectural concern?

A) Ensuring the system can scale to meet projected revenue targets for the next three years

B) Designing for graceful failure so the system degrades safely rather than failing catastrophically

C) Selecting the vendor with the strongest enterprise support agreement and SLA guarantees

D) Ensuring the architecture aligns with the approved enterprise reference model and standards

Question 7. What does it mean to design a system assuming breach will happen?

A) Building layered defences, monitoring, and containment so that when a breach occurs the damage is limited and detected quickly

B) Purchasing comprehensive cyber insurance to cover the financial impact of a breach event

C) Conducting annual penetration tests and remediating all critical findings before the next audit cycle

D) Ensuring all systems are compliant with the relevant regulatory frameworks and industry standards

3 Delivery and Process

Question 8. A project is behind schedule. The team suggests reducing scope to meet the deadline. The business stakeholder wants the full scope delivered on time. What do you recommend?

A) Deliver the reduced scope with high quality and iterate, since shipping broken software on time is worse than shipping less software that works

B) Add additional resources to accelerate delivery since the business committed to the date with external partners

C) Negotiate a two week extension with the full scope since the revenue impact of a delayed launch is manageable

D) Split the team to deliver the core features on time and the remaining features two weeks later as a fast follow

Question 9. How should work ideally flow through a well functioning technology team?

A) Through two week sprints with defined ceremonies, backlog grooming, sprint reviews, and retrospectives

B) Through continuous small changes deployed frequently with clear ownership and minimal handoffs

C) Through quarterly planning cycles with monthly milestone reviews and weekly status reporting

D) Through a prioritised backlog managed by a product owner who coordinates with the business on delivery sequencing

Question 10. A team is consistently delivering features on time but production incidents are increasing. What does this tell you?

A) The team is likely cutting corners on quality to meet deadlines and the delivery metric is masking a growing technical debt problem

B) The team needs better production support tooling and a dedicated site reliability function

C) The team is delivering well but the infrastructure team is not scaling the platform to match the increased feature throughput

D) The incident management process needs improvement since faster triage would reduce the apparent incident volume

4 Technical Fundamentals

Question 11. What is the difference between vertical scaling and horizontal scaling?

A) Vertical scaling adds more power to a single machine while horizontal scaling adds more machines to distribute the load

B) Vertical scaling increases storage capacity while horizontal scaling increases network bandwidth

C) Vertical scaling is for databases and horizontal scaling is for application servers

D) Vertical scaling is cheaper at small volumes while horizontal scaling is cheaper at large volumes, which is why you choose based on cost projections

Question 12. What is technical debt?

A) Shortcuts or suboptimal decisions in code and architecture that make future changes harder, slower, or riskier

B) The accumulated cost of software licences and infrastructure that the organisation is contractually committed to paying

C) The gap between the current technology stack and the approved target state architecture

D) Legacy systems that have not yet been migrated to the cloud as part of the digital transformation programme

Question 13. Why is it important that a system can be observed in production?

A) Because without visibility into how the system behaves under real conditions you cannot diagnose problems, understand performance, or detect failures early

B) Because the compliance team requires evidence that systems are being monitored as part of the annual audit

C) Because the business needs real time dashboards showing transaction volumes and revenue metrics

D) Because the vendor SLA requires the organisation to demonstrate monitoring capability to qualify for support credits

5 Cloud Computing

Question 14. What is the primary benefit of using a public cloud provider like AWS or Azure?

A) The ability to provision and scale infrastructure on demand without managing physical hardware, paying only for what you use

B) Guaranteed lower costs compared to on premises infrastructure for all workload types and volumes

C) Automatic compliance with all regulatory requirements since the cloud provider manages the security controls

D) Eliminating the need for a technology team since the cloud provider manages everything end to end

Question 15. What is the shared responsibility model in cloud computing?

A) The cloud provider is responsible for the security of the cloud infrastructure while the customer is responsible for securing what they build and run on it

B) The cloud provider and the customer share the cost of infrastructure equally based on a negotiated commercial agreement

C) Both the cloud provider and the customer have equal responsibility for all aspects of security and neither can delegate

D) The cloud provider assumes full responsibility for everything deployed on their platform as part of the service agreement

Question 16. What is an availability zone in the context of cloud infrastructure?

A) A physically separate data centre within a cloud region, designed so that failures in one zone do not affect others

B) A geographic region where the cloud provider offers services, such as Europe West or US East

C) A virtual network boundary that isolates different customer workloads from each other for security purposes

D) A pricing tier that determines the level of uptime guarantee and support response time for your workloads

Question 17. What is Infrastructure as Code?

A) Defining and managing cloud infrastructure through machine readable configuration files that can be version controlled and reviewed like software

B) A software tool that automatically generates infrastructure diagrams from the live cloud environment

C) A methodology for documenting infrastructure decisions in a shared wiki so the team can track changes over time

D) An approach where infrastructure costs are coded into the project budget as a separate line item from application development

6 Testing Strategy

Question 18. When should testing happen in the development lifecycle?

A) Continuously throughout development, with automated tests running on every code change as part of the build pipeline

B) After development is complete, during a dedicated testing phase before the release is approved for production

C) At key milestones defined in the project plan, with formal sign off required before moving to the next phase

D) Primarily before major releases, with exploratory testing conducted by the QA team in the staging environment

Question 19. A team tells you they have 95% code coverage. How confident should you be in their quality?

A) Coverage alone does not indicate quality because tests can cover code without meaningfully validating behaviour or edge cases

B) Very confident since 95% coverage means almost all of the codebase has been validated by automated tests

C) Moderately confident but you would want to see the coverage broken down by module to check for gaps in critical areas

D) You would need to compare the coverage metric against the industry benchmark for their technology stack to assess it properly

Question 20. What is the purpose of a chaos engineering or game day exercise?

A) To deliberately introduce failures into a system to test how it responds and to build confidence that recovery mechanisms work

B) To simulate peak traffic scenarios to verify the infrastructure can handle projected load during high revenue periods

C) To test the disaster recovery plan by failing over to the secondary site and measuring recovery time against the SLA

D) To stress test the team’s incident management process and identify bottlenecks in the escalation procedures

7 Data and AI

Question 21. What is the difference between a data warehouse and a data lake?

A) A data warehouse stores structured, curated data optimised for querying and reporting, while a data lake stores raw data in its native format for flexible future use

B) A data warehouse is an on premises solution while a data lake is a cloud native service that replaces the need for traditional databases

C) A data warehouse is owned by the business intelligence team while a data lake is owned by the engineering team, which is why they are governed separately

D) A data warehouse handles historical data for compliance purposes while a data lake handles real time data for operational dashboards

Question 22. Your organisation wants to build a machine learning model to predict customer churn. What is the first question you should ask?

A) Do we have clean, representative data that captures the behaviours and signals that precede churn, and do we understand the biases in that data

B) What is the expected revenue impact of reducing churn by a target percentage, and does it justify the investment in a data science team

C) Which vendor platform offers the best prebuilt churn prediction model so we can deploy quickly without building a team from scratch

D) Can we have a working model within the current quarter so we can demonstrate the value of AI to the executive committee

Question 23. What is the biggest risk of deploying a machine learning model into production without ongoing monitoring?

A) The model will silently degrade as real world data drifts away from the data it was trained on, producing increasingly wrong predictions that nobody notices until damage is done

B) The model will consume increasing amounts of compute resources over time, driving up infrastructure costs beyond the original budget

C) The compliance team may flag the model as a risk because it was deployed without a formal model governance review and sign off process

D) The business will lose confidence in AI if the model produces a visible error, which could jeopardise funding for future AI initiatives

Question 24. A business stakeholder asks you to build an AI feature that automates a customer decision. The team warns that the training data contains historical bias. What do you do?

A) Take the bias concern seriously. Deploying a biased model at scale will amplify discrimination, create regulatory exposure, and damage customer trust in ways that are extremely difficult to undo

B) Proceed with the deployment but add a disclaimer that the model’s recommendations should be reviewed by a human before any final decision is made

C) Ask the data science team to quantify the bias impact and present a risk assessment to the steering committee so leadership can make an informed commercial decision

D) Deprioritise the concern for now and launch the feature since the competitive advantage of being first to market outweighs the risk, and the bias can be addressed in a future iteration

Question 25. You have hired one AI engineer and placed them alone in a feature team surrounded by backend and frontend developers. Nobody in the team or its management chain has AI or machine learning experience. The engineer’s work is reviewed by people who do not understand it. How do you evaluate this structure?

A) This is a problem. The engineer has no peers to learn from, no manager who can grow their career, and no quality gate on their work. They will either stagnate, produce unchallenged work of unknown quality, or leave. AI engineers need to sit in or be connected to a community of practice with people who understand their discipline

B) This is fine as long as the engineer has clear deliverables and the feature team has a strong product owner who can validate the business outcomes of the AI work

C) This is efficient. Embedding specialists directly in feature teams ensures their work is aligned with delivery priorities and avoids the overhead of a separate AI team that operates disconnected from the product

D) This is manageable. Provide the engineer with access to external training and conferences so they can maintain their skills, and ensure their performance is measured on delivery milestones like any other team member

Question 26. What does data governance mean in practice?

A) Ensuring the organisation knows what data it has, where it lives, who owns it, how it flows, what quality it is in, and what rules govern its use, so that data is treated as a product rather than an accident

B) A framework of policies and committees that approve data access requests and ensure all data usage complies with the relevant regulatory requirements

C) A set of data classification standards and retention policies that are documented and audited annually to satisfy regulatory obligations

D) A technology platform that enforces role based access controls and encrypts data at rest and in transit across all systems

8 People and Hiring

Question 27. You need to hire a senior engineer. Which quality matters most?

A) Deep curiosity, the ability to reason through unfamiliar problems, and a track record of simplifying complex systems

B) Certifications in the specific technologies your team currently uses, with at least ten years of experience in the industry

C) Strong communication skills and experience presenting to executive stakeholders and steering committees

D) A proven ability to deliver projects on time and within budget, with references from previous programme managers

Question 28. An engineer pushes back on a technical decision you have made, providing evidence you were wrong. What is the ideal response?

A) Thank them, evaluate the evidence, and change the decision if the evidence warrants it because being right matters more than being in charge

B) Acknowledge their input and ask them to document their concerns formally so they can be reviewed in the next architecture review board

C) Listen carefully but explain the broader strategic context they may not be aware of that influenced your original decision

D) Appreciate the initiative but remind them that decisions at your level factor in commercial and timeline considerations beyond the technical merits

Question 29. What is the biggest risk when a non technical leader runs a technology team?

A) They cannot distinguish between genuine technical risk and comfortable excuses, which leads to either missed danger or wasted time

B) They tend to over rely on vendor solutions and consultancies because they cannot evaluate build versus buy decisions independently

C) They struggle to earn the respect of senior engineers, which leads to talent attrition and difficulty recruiting strong replacements

D) They focus on timelines and deliverables rather than the technical foundations that determine whether those deliverables are sustainable

9 Quality and Sustainability

Question 30. A vendor promises to solve a critical problem with their platform. What is your first concern?

A) Whether the solution creates a dependency that will be expensive or impossible to exit, and what happens when the vendor changes direction

B) Whether the vendor is on the approved procurement list and whether the commercial terms fit within the current budget cycle

C) Whether the vendor has case studies from similar organisations and what their Net Promoter Score is among existing customers

D) Whether the vendor can commit to a delivery timeline that aligns with the programme milestones already communicated to the board

Question 31. You are reviewing two architecture proposals. Proposal A is clever and impressive but requires deep expertise to operate. Proposal B is simpler but less elegant. Which do you prefer?

A) Proposal B, because a system that can be understood, operated, and maintained by the team that inherits it is more valuable than one that impresses today

B) Proposal A, because the additional complexity is justified if it delivers significantly better performance metrics

C) Neither until both proposals include detailed cost projections and a total cost of ownership comparison over five years

D) Whichever proposal the lead architect recommends since they have the deepest technical context on the constraints

Question 32. A 97 slide strategy deck is presented to you. What is your reaction?

A) Scepticism, because length often compensates for lack of clarity and a strong strategy should be explainable in a few pages

B) Appreciation, because a thorough strategy deck shows the team has done their due diligence and considered all angles

C) Request an executive summary of no more than five slides that highlights the key investment asks and expected returns

D) Review it in detail because strategic decisions of this magnitude deserve comprehensive analysis and supporting evidence

10 Reporting and Planning

Question 33. A technology team has no weekly status report. They deploy daily, incidents are low, and customers are satisfied. Is this a problem?

A) No. Outcomes are the evidence. If the system works, customers are happy, and the team ships reliably, the absence of a status report means nothing is being hidden

B) Yes. Without a structured weekly report the leadership team has no visibility into what the team is doing and cannot govern effectively

C) It depends. A lightweight status update would be beneficial for alignment even if things are going well, since stakeholders deserve visibility

D) Yes. Consistent reporting is a professional discipline. Even high performing teams need to document their progress for accountability and audit purposes

Question 34. A team starts a complex migration and discovers halfway through that the original plan was based on incorrect assumptions. They adjust and complete the migration successfully but two weeks later than planned. How do you evaluate this?

A) Positively. Learning while doing is an inherent property of complex work. The team adapted to reality and delivered a successful outcome, which is exactly what good engineering looks like

B) As a planning failure. The incorrect assumptions should have been identified during the planning phase. A proper discovery exercise would have prevented the overrun

C) Neutrally. The outcome was acceptable but the team should produce a lessons learned document to prevent similar planning gaps in future projects

D) As a risk management issue. The two week overrun needs to be logged and the planning process needs to include more rigorous assumption validation before execution begins

Question 35. You ask a technology lead how a project is going. They say they do not know yet because the team is still working through some unknowns. How do you respond?

A) Appreciate the honesty. Not knowing is a valid state early in complex work. Ask what they are doing to reduce the unknowns and when they expect to have a clearer picture

B) Ask them to prepare a risk register and preliminary timeline estimate within two days so you have something to report upward

C) Express concern. A technology lead should always be able to articulate the status of their work, even if uncertain, and should present options with probability weightings

D) Escalate the concern. If the lead cannot provide a clear status update, the project may lack adequate governance and oversight

Question 36. What is the most important thing to measure about a technology team’s performance?

A) The business outcomes their work enables, including reliability, customer experience, and the ability to change safely

B) Velocity and throughput, measured by story points completed per sprint across all teams

C) Time to market for new features, measured from business request to production deployment

D) Budget adherence, measured by comparing actual technology spend against the approved annual plan

11 Relationship with Technologists

Question 37. A senior architect strongly disagrees with your proposed approach and presents an alternative in a team meeting. They are blunt and direct. How do you handle this?

A) Welcome it. Blunt disagreement backed by evidence is a sign of a healthy team. Evaluate the alternative on its merits and decide based on what produces the best outcome

B) Thank them for their perspective but ask them to raise concerns through the proper channels rather than challenging your direction in a group setting

C) Acknowledge their passion but remind the team that once a direction is set, the expectation is to commit and execute rather than relitigate decisions

D) Listen but note that architectural decisions need to factor in business timelines and stakeholder commitments, not just technical preferences

Question 38. How do you view the role of engineers in the decision making process?

A) Engineers are domain experts whose knowledge should be actively extracted, challenged, and synthesised into better decisions. The best outcomes come from iterative collaboration, not instruction

B) Engineers should provide technical input and recommendations, but the final decision authority rests with the business leader who owns the commercial outcome

C) Engineers should focus on execution excellence. They are most effective when given clear requirements and the autonomy to choose the implementation approach

D) Engineers should be consulted on technical feasibility, but strategic decisions about what to build and when should be driven by the product and business teams

Question 39. You notice your best engineers have stopped voicing opinions in meetings. What does this tell you?

A) Something is wrong. When strong engineers go quiet, it usually means they have concluded that their input does not matter, which means the organisation is about to lose them or already has in spirit

B) They may be focused on delivery. Not every engineer wants to participate in strategic discussions and some prefer to let their code speak for itself

C) It could indicate that the team has matured and aligned around a shared direction, which reduces the need for debate

D) It suggests the decision making process is working efficiently. Fewer objections means the planning and communication have improved

Question 40. An engineer tells you the proposed deadline is unrealistic and the team will either miss it or ship something that breaks. What do you do?

A) Take the warning seriously. Engineers who raise alarms about deadlines are usually right and ignoring them is how organisations end up with production failures and burnt out teams

B) Acknowledge the concern and ask them to propose an alternative timeline with a clear breakdown of what can be delivered by when

C) Thank them for the flag but explain that the deadline was set based on commercial commitments and the team needs to find a way to make it work

D) Ask them to quantify the risk. If they can show specific technical evidence for why the deadline is unrealistic, you will escalate it. Otherwise the plan stands

---

Assessor Guide

Everything below this line is for the assessor only. Do not share with the candidate.

Traffic Light Scoring

Each answer is scored using a traffic light system.

Green. Strong technology leadership instinct. The answer demonstrates understanding of systems thinking, quality, sustainability, customer outcomes, or respect for engineering as a discipline.

Amber. Acceptable but surface level. The answer is not wrong but reveals a preference for process, optics, conventional wisdom, or a management lens over a technology leadership lens.

Red. Concerning. The answer reveals a fixation on timelines, revenue projections, reporting, governance ceremony, or a belief that technologists are interchangeable resources who should execute rather than think.

Answer Key

#	Category	Green	Amber	Red
1	Leadership	A	B, C	D
2	Leadership	B	A, C	D
3	Leadership	A	B, C	D
4	Leadership	B	C, D	A
5	Architecture	A	B, C	D
6	Architecture	B	C, D	A
7	Architecture	A	B, C	D
8	Delivery	A	C, D	B
9	Delivery	B	A, D	C
10	Delivery	A	B, C	D
11	Technical	A	B, C	D
12	Technical	A	B, C	D
13	Technical	A	B, D	C
14	Cloud	A	B, C	D
15	Cloud	A	B, C	D
16	Cloud	A	B, C	D
17	Cloud	A	B, C	D
18	Testing	A	B, D	C
19	Testing	A	B, C	D
20	Testing	A	C, D	B
21	Data and AI	A	B, C	D
22	Data and AI	A	B, C	D
23	Data and AI	A	B, C	D
24	Data and AI	A	B, C	D
25	Data and AI	A	B, D	C
26	Data and AI	A	B, C	D
27	People	A	B, C	D
28	People	A	B, C	D
29	People	A	B, C	D
30	Quality	A	B, C	D
31	Quality	A	B, D	C
32	Quality	A	B, C	D
33	Reporting	A	C, D	B
34	Reporting	A	C, D	B
35	Reporting	A	B, C	D
36	Reporting	A	B, C	D
37	Technologists	A	B, C	D
38	Technologists	A	B, D	C
39	Technologists	A	B, C	D
40	Technologists	A	B, D	C

Scoring Thresholds

30 to 40 Green. Strong candidate. Likely to build sustainable technology, retain talented engineers, and make sound architectural decisions.

20 to 29 Green. Moderate. May need coaching on the difference between managing a technology team and leading one. Watch for patterns in which categories the red answers cluster.

Below 20 Green. Significant risk. Likely to prioritise optics and timelines over quality, struggle to retain senior technologists, and make hiring decisions based on compliance rather than capability.

10 or more Red. Disqualifying regardless of green count. The candidate consistently gravitates toward answers that would damage engineering culture, product quality, and team retention.

Red Flag Patterns

Beyond the raw count, watch for clustering patterns that reveal specific blind spots.

The Timeline Addict. Red answers cluster in Delivery and Quality. The candidate treats every question as a scheduling problem and evaluates every decision through the lens of “will this delay the programme.”

The Dashboard Governor. Red answers cluster in Reporting and Planning. The candidate believes that better reporting equals better understanding, and that learning while doing is evidence of poor planning rather than an inherent property of complex work.

The Order Taker Factory. Red answers cluster in Relationship with Technologists. The candidate sees engineers as execution resources, gets uncomfortable with opinionated technologists, and interprets pushback as insubordination rather than intellectual rigour.

The Revenue Lens. Red answers cluster across multiple categories but consistently reference commercial outcomes, revenue projections, or stakeholder commitments as the deciding factor. Technology decisions are subordinated to the current quarter’s numbers.

The Process Worshipper. Red answers cluster in Delivery and Leadership. The candidate equates process with progress, ceremonies with delivery, and governance with good judgment.

The AI Tourist. Red answers cluster in Data and AI. The candidate treats AI as a buzzword to be deployed for competitive optics rather than a discipline that requires data quality, monitoring, ethical consideration, and properly supported specialists. They see nothing wrong with isolating a single AI engineer in a team that cannot grow, challenge, or manage them.

A Note on Opinionated Technologists

One of the most revealing dimensions of this assessment is how the candidate responds to questions about engineers who push back, disagree, or hold strong technical opinions. Business heads who have succeeded in environments where teams execute instructions often find opinionated technologists threatening. They interpret technical pushback as resistance, disagreement as disloyalty, and independent thinking as a management problem.

The reality is the opposite. The best technology teams are built from opinionated people who care deeply about the work. The role of the leader is not to suppress those opinions but to create an environment where they can be heard, challenged, and synthesised into better decisions. A leader who cannot tolerate dissent will build a team of compliant executors who ship mediocre products on time and wonder why the customers leave.

A Note on Learning While Doing

Business heads with a strong planning orientation often view learning while doing as evidence of failure. If you had planned properly, you would not need to learn anything during execution. This belief is incompatible with technology leadership.

Complex systems cannot be fully understood before they are built. Architecture emerges from contact with reality. Requirements change as users interact with early versions. Performance characteristics only reveal themselves under production load. Security vulnerabilities surface through adversarial testing, not through documentation reviews.

A leader who demands complete certainty before starting will either never start or will force the team to fabricate certainty they do not have, which is worse. The right instinct is to plan enough to reduce the biggest risks, start building, learn from what you discover, and adjust. This is not the absence of planning. It is the only kind of planning that works for complex technology.

A Note on Engineers as Order Takers

The most damaging instinct a business head can carry into a technology organisation is the belief that engineers exist to execute instructions. This mental model treats technology as a cost centre staffed by interchangeable resources whose job is to convert requirements into code on schedule.

In practice, the best engineers carry deep domain knowledge, architectural intuition, and an understanding of how systems behave under stress that cannot be replicated by reading a requirements document. A leader who treats them as order takers will never access this knowledge. They will receive exactly what they ask for, nothing more, and the products they ship will reflect the limits of their own understanding rather than the collective intelligence of the team.

The alternative is to treat every interaction with a technologist as an opportunity to iteratively extract intellectual property. Ask what they think. Ask why they disagree. Ask what they would build if they had the authority. The answers will be better than anything a steering committee can produce.

A Note on the Isolated AI Engineer

Question 25 is one of the most diagnostic questions in this assessment. The pattern it describes is common: an organisation hires a single AI or machine learning engineer, places them in a feature team composed entirely of people from different disciplines, and declares the AI capability embedded.

The candidate who sees nothing wrong with this structure reveals several dangerous blind spots simultaneously.

No quality gate. Machine learning work is unlike conventional software engineering. Model selection, feature engineering, training methodology, bias detection, and evaluation metrics require peer review from people who understand the discipline. An engineer whose work is reviewed only by people who cannot evaluate it is an engineer whose mistakes go undetected.

No career growth. Engineers grow by working alongside people who are better than them, or at least different enough to challenge their assumptions. A single AI engineer in a feature team has no mentor, no sparring partner, and no career path. They will plateau and leave, and the organisation will have to start again.

No management competence. If nobody in the management chain understands what the AI engineer does, nobody can set meaningful objectives, evaluate performance, identify when they are struggling, or advocate for the resources they need. The engineer is simultaneously unsupported and unaccountable.

No intellectual community. AI and machine learning are disciplines where techniques evolve rapidly. An isolated engineer has no internal community of practice, no one to discuss new approaches with, and no one to challenge their methodology. They become a single point of knowledge failure.

The green answer recognises that specialist disciplines need communities of practice. This does not necessarily mean a separate AI team, but it does mean deliberate structures that connect specialists, provide peer review, enable career progression, and ensure management understands the work well enough to support it.

The red answers treat the AI engineer as a fungible delivery resource whose value is measured by output against a timeline, which is the same mistake that drives experienced engineers out of organisations that claim they cannot find talent.

Final Thought

This assessment is not a test of intelligence. It is a test of instinct. Intelligent people can hold damaging instincts. The business head who optimises for reporting, timelines, and compliant teams is not stupid. They are applying a mental model that works in other domains but fails catastrophically in technology.

The purpose of this assessment is to find out which mental model the candidate carries before they are given the keys to a technology organisation and the careers of the people inside it.

Score Sheet

Field	Value
Candidate Name
Assessment Date
Assessor

Score	Count
Green	/40
Amber	/40
Red	/40

Category	Green	Amber	Red
Leadership (Q1 to Q4)	/4	/4	/4
Architecture (Q5 to Q7)	/3	/3	/3
Delivery (Q8 to Q10)	/3	/3	/3
Technical (Q11 to Q13)	/3	/3	/3
Cloud (Q14 to Q17)	/4	/4	/4
Testing (Q18 to Q20)	/3	/3	/3
Data and AI (Q21 to Q26)	/6	/6	/6
People (Q27 to Q29)	/3	/3	/3
Quality (Q30 to Q32)	/3	/3	/3
Reporting and Planning (Q33 to Q36)	/4	/4	/4
Technologist Relationship (Q37 to Q40)	/4	/4	/4

Red Flag Pattern	Detected
Timeline Addict
Dashboard Governor
Order Taker Factory
Revenue Lens
Process Worshipper
AI Tourist

|Overall Assessment||
|——————||
|Recommendation ||
|Notes ||

---

Inspired by Why Andrew Baker Is the World’s Worst CTO