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

2. Your Team Proposes Removing an Integration Layer

3. You Inherit Seven Management Layers

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

5. What Does Blast Radius Mean?

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

7. What Does Designing Assuming Breach Mean?

8. A Project Is Behind Schedule

9. How Should Work Flow Through a Technology Team?

10. Features Are on Time but Incidents Are Increasing

11. Vertical Versus Horizontal Scaling

12. What Is Technical Debt?

13. Why Does Observability in Production Matter?

14. The Primary Benefit of Public Cloud

15. The Shared Responsibility Model

16. What Is an Availability Zone?

17. What Is Infrastructure as Code?

18. When Should Testing Happen?

19. A Team Has 95% Code Coverage

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

21. Data Warehouse Versus Data Lake

22. Building a Churn Prediction Model

23. The Biggest Risk of Unmonitored Production Models

24. A Biased AI Model Is Proposed for Customer Decisions

25. One AI Engineer Embedded in a Feature Team

26. What Is Data Governance in Practice?

27. You Need to Hire a Senior Engineer

28. An Engineer Proves You Wrong

29. The Biggest Risk of a Non Technical Leader

30. A Vendor Promises to Solve a Critical Problem

31. Clever Architecture Versus Simple Architecture

32. A 97 Slide Strategy Deck

33. A High Performing Team Has No Status Report

34. A Team Adjusts and Delivers Two Weeks Late

35. A Lead Says They Do Not Know Yet

36. What Is the Most Important Thing to Measure?

37. A Senior Architect Disagrees Publicly and Bluntly

38. The Role of Engineers in Decision Making

39. Your Best Engineers Have Gone Quiet

40. An Engineer Says the Deadline Is Unrealistic

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.

This is a self assessment. It is not balanced. It is not gentle. It is not here to validate your operating model, your org chart, or the deck you use to reassure executives. It exists to surface how you actually think about technology leadership when pressure arrives and incentives collide with reality.

Answer honestly. Not as the leader you describe in interviews. As the leader you become when systems fail, timelines slip, engineers disagree, and someone senior wants a simple answer to a complex problem.

This is written like a Cosmopolitan quiz for people who run technology at scale. Every option is phrased to sound reasonable, responsible, and professionally defensible. That is the point. The wrong answers are rarely stupid. They are seductive.

How to Score Yourself

🟢 Durable leadership – builds long term capability, speed, and resilience
🟡 Context dependent – reasonable sometimes, dangerous as a default
🔴 Fragile leadership – optimises for optics, control, and personal safety

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

Questions

1. A Major Production Outage Happens at 02:00

Engineers are already working on it. Your first instinct is to:

A. Take command of coordination so decisions are fast and consistent
B. Stabilise stakeholders early so the business stays calm and aligned
C. Ask for impact, current mitigation, and what help the team needs, then get out of the way
D. Jump into the technical detail where you can add leverage immediately

2. An Engineer Pushes Back on Your Deadline

They say the timeline is unrealistic. You respond with:

A. Keep the date but ask the team to propose explicit tradeoffs to protect quality
B. Keep the date to preserve confidence, then work on increasing capacity or reducing friction
C. Re open assumptions together, quantify risk, and reset the plan transparently
D. Ask for options and let the team choose the best path so ownership stays with them

3. A Project Misses Its Delivery Date

Your immediate conclusion is:

A. Execution needs tightening, so you will introduce clearer routines and stronger follow through
B. Signalling failed, so you will improve reporting so leadership is never surprised again
C. The system failed, so you will examine scope, dependencies, architecture, and incentives
D. Sequencing failed, so you will revisit the plan to create a more credible delivery path

4. How Do You View Architecture?

Which best matches your belief?

A. Architecture is guardrails that keep teams safe and aligned at speed
B. Architecture is clarity: decisions recorded so people stop debating the same things
C. Architecture is the constraint system that determines how cheaply you can change
D. Architecture is enablement: it should remove friction and increase throughput

5. A Team Wants to Pivot Mid Stream

New information invalidates the original approach. You say:

A. Pivot if the learning is real, but time box it and control blast radius
B. Pivot carefully because confidence matters, and churn can destroy momentum
C. Pivot early if staying the course is more expensive than switching
D. Pivot only with a crisp alternative and a clear risk reduction story

6. How Do You Measure Engineering Performance?

Your most trusted signals are:

A. Predictable delivery plus stable operations, because reliability is a feature
B. Stakeholder confidence, because alignment reduces thrash and rework
C. Lead time, failure rate, recovery time, and client outcomes
D. A balanced view: delivery, quality, people health, and operational maturity

7. A Senior Engineer Disagrees With You Publicly

In a meeting they challenge your decision. You:

A. Welcome it, but structure the debate so it stays constructive and time boxed
B. Acknowledge it and move it offline so the group stays aligned and productive
C. Explore it openly if it improves the decision and teaches the room
D. Ask for a clear alternative, evidence, and a decision recommendation

8. Planning Means What to You?

When you hear planning you think:

A. Commitments with explicit tradeoffs so delivery is credible
B. A narrative that keeps stakeholders confident and reduces churn
C. Direction, constraints, and fast feedback loops that allow adaptation
D. A tool to reduce chaos while preserving optionality

9. A System Is Known to Be Fragile

It works, but only if nobody touches it. You choose to:

A. Stabilise it with targeted fixes while keeping delivery moving
B. Reduce the surface area of change to keep risk contained
C. Invest in removing fragility because it compounds and taxes every change
D. Contain it, ring fence it, and build a replacement plan

10. How Much Management Do You Want to Hire?

As the organisation grows, your instinct is to:

A. Add leaders only where coordination genuinely increases throughput
B. Add management capacity so engineers can focus and stakeholders are handled
C. Keep it flatter and scale through platforms, clarity, and better interfaces
D. Blend strong technical leads with a small, high leverage management layer

11. Which Reports Do You Value Most?

You feel safest when you see:

A. Delivery and stability metrics with leading indicators
B. Executive summaries that are clear, confident, and action oriented
C. Trend lines tied to outcomes, explained plainly
D. A small set of metrics teams trust and do not game

12. How Do You View Engineers?

Pick the closest description.

A. Skilled professionals who need clarity, constraints, and autonomy
B. Partners in execution who need protection from churn and noise
C. Problem solvers who need context, trust, and feedback
D. Craftspeople who need high standards and space to do quality work

13. What Is the Ideal Career Path for an Engineer?

In your organisation, growth means:

A. Two paths: management for some, deep technical impact for others
B. Broader influence across stakeholders and business outcomes
C. Technical mastery that scales impact without forced management
D. A clear ladder where impact, scope, mentoring, and judgement define seniority

14. A Team Asks for Time to Pay Down Technical Debt

Your reaction is:

A. Support it if it is tied to reliability, speed, or risk reduction
B. Support it if it can be planned without disrupting delivery commitments
C. Support it because debt compounds and removes future options
D. Support it with guardrails and measurable outcomes so it stays bounded

15. Client Centricity Shows Up When?

Client focus matters most when:

A. Tradeoffs are made, because priorities become real
B. Stakeholder stories are written, because narratives drive investment
C. Engineers can explain client impact without being prompted
D. Roadmaps are shaped by behaviour, pain, and retention

16. A New Tool or Platform Is Proposed

You decide based on:

A. Strategic fit and total cost of ownership over time
B. Defensibility and alignment with standards so governance friction is low
C. Operability, durability, and the ability to change safely at speed
D. Team capability and long term maintainability, not the demo

17. Cost Pressure Hits the Organisation

Your instinctive response is to:

A. Remove waste first, then protect investments that buy durability
B. Introduce clear cost controls so spend is disciplined and visible
C. Separate cosmetic savings from structural cost reduction
D. Shift spend toward automation and platforms that reduce run costs

18. Outsourcing and Vendors

Which best matches your stance?

A. Outsource non core execution, keep accountability and architecture internal
B. Use vendors to scale quickly and reduce delivery risk, with strong oversight
C. Outsource execution but keep primitives, recovery, and design authority in house
D. Delegate build and run, and focus on outcomes, governance, and oversight

19. “Tried and Tested” Technology Leadership

When you use this phrase, you mean:

A. Proven patterns reduce risk and free attention for real problems
B. Familiar approaches reduce friction and keep stakeholders comfortable
C. Known tradeoffs are chosen consciously with eyes open
D. Boring technology is stable, scalable, and easier to operate

20. Upwards Management

A senior executive wants certainty you cannot honestly provide yet. You:

A. Provide ranges and scenarios, and explain what will reduce uncertainty next
B. Provide a confident narrative to keep momentum, then refine details underneath
C. Provide the truth plainly, including risk and what is unknown
D. Provide a short answer now, then follow up once validated

Answer Key With Explanations

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

1. A Major Production Outage Happens at 02:00

2. An Engineer Pushes Back on Your Deadline

3. A Project Misses Its Delivery Date

4. How Do You View Architecture?

5. A Team Wants to Pivot Mid Stream

6. How Do You Measure Engineering Performance?

7. A Senior Engineer Disagrees With You Publicly

8. Planning Means What to You?

9. A System Is Known to Be Fragile

10. How Much Management Do You Want to Hire?

11. Which Reports Do You Value Most?

12. How Do You View Engineers?

13. Ideal Career Path for an Engineer

14. A Team Asks for Time to Pay Down Technical Debt

15. Client Centricity Shows Up When?

16. A New Tool or Platform Is Proposed

17. Cost Pressure Hits the Organisation

18. Outsourcing and Vendors

19. Tried and Tested Technology Leadership

20. Upwards Management

Interpretation

Mostly 🟢 means you are building a durable technology organisation. You can delegate without losing ownership, use vendors without outsourcing thinking, and manage up without lying.

Mostly 🟡 means you have good instincts but pressure pushes you toward convenience. Under stress, your worst defaults will dominate unless you consciously correct them.

Mostly 🔴 means you optimise for optics, comfort, and personal safety. You are likely an upwards management leader. Your organisation will look calm right until it fails loudly.

The most dangerous leaders are not incompetent. They are reassuring.

Leadership failures rarely announce themselves politely. They arrive disguised as “can we just check in?” or “let’s align on a better way of working.” It sounds constructive, even mature. But scratch the surface and the origin story is almost always the same: something went wrong, and the organisation does not know how to deal with it cleanly. What follows is a predictable, energy wasting ritual. And the organisations that repeat it are fragile by design.

1. When Something Goes Wrong, Only Two Things Matter

When an issue occurs, only two things should happen. First, do we agree that something went wrong. Second, how do we fix it and make sure it does not happen again. That is it. Everything else is noise.

The first step is often stormy. That is normal. Storming is not dysfunction; it is the process of forcing a shared understanding to emerge. Different facts, interpretations and incentives collide in the open. This collision is healthy if, and only if, it is not personalised. The storm is about the problem, not the people. Fragile organisations confuse the two.

2. The Fatal Error: Personalising the Storm

Somewhere during the storm, someone inevitably says: “I perceive that you are angry” or “I perceive that you are frustrated.” This is projection masquerading as emotional intelligence.

Busy, effective leaders are rarely angry or frustrated in these moments. Both require emotional energy they are not willing to waste. What they care about is whether the room converges on a shared understanding of reality. The moment the conversation shifts from facts to perceived emotions, the entire system derails. Now the discussion is no longer about what happened; it is about managing feelings, defending intent and protecting ego. That is fragility revealing itself.

3. Blame Is Not Ownership

The next predictable move is attribution. “I just want to be clear, person A did X, Y and Z. My team did nothing wrong.” This sentence is never followed by progress. It is not ownership; it is blame wrapped in professional language.

Ownership sounds very different. “Leave this with me. I will get it sorted and I will make sure it does not happen again.” Ownership does not require seniority. It does not require proximity to the original failure. It does not require proving innocence first. Ownership is a mindset that says: whatever this is, I can help fix it, and I do not care where the fault ultimately lands.

Weak organisations are obsessed with fault lines. Strong ones are obsessed with outcomes.

4. Leadership Without Fragility

Fragile leaders need private consensus. They need side rooms, pre meetings and alignment calls to protect their image before engaging in the real conversation. They cannot say, “Sorry, I think I may have duffed this one.” So instead, they diffuse accountability, soften language and drain urgency from execution.

This does not build trust. It destroys it.

Trust is built when problems are confronted openly, owned decisively and fixed aggressively. Trust is built when leaders do not flinch during the storm.

5. After the Storm, There Is Only Execution

Once common understanding exists, discussion should end. Now we execute, with prejudice and vigour. Not cautiously. Not diplomatically. Not with endless follow ups designed to protect feelings.

Execution is the trust building mechanism. Every time ownership leads to visible action, credibility compounds. Every time blame leads to delay, fragility compounds.

Do not hide the storm. Embrace it. Do not fear ownership. Seek it. Do not mistake calmness for weakness; it is often unshakeable strength. The best leaders I have worked with all share one trait: they smile when you try to trigger them. Not because they do not care, but because they know exactly what matters next.

And it is never blame.

1. Every company I have worked for was running from a Lion

Every company I have ever worked for was running from a lion. Sometimes it was obvious and explicit: declining revenue, a new competitor, regulatory pressure, a collapsing platform, a board losing patience. Sometimes it was quieter and more personal: a role under threat, a team being “restructured”, a mandate with a six month half life. But the pattern was always the same. There was an existential threat somewhere in the room, even if nobody wanted to say it out loud.

Fear became the background radiation of the organisation. Decisions were framed as survival moves. Roadmaps were rewritten to “buy time”. Strategy decks were really just elaborate ways of explaining why today would not be the day the lion finally caught us. When you live like that for long enough, you stop questioning whether this is a healthy way to operate. You just assume this is what work feels like.

2. Fear is a finite motivator

Fear is powerful, but it is not infinite. It works exceptionally well in short bursts. If you jump into the ocean and a shark starts circling you, every neuron in your body lights up. You will paddle, kick, scream and invent new muscle groups you did not know you had. Fear sharpens focus and compresses time.

But fear has a shelf life. If you have been in the water for two weeks and the shark has not eaten you, something changes. The terror dulls. You start naming the shark. You learn its patterns. It stops being an immediate threat and starts becoming part of the environment. At that point the shark is no longer your executioner. It is your pet.

This is where many companies quietly break. They do not escape the lion. They simply get used to it. Fear mutates into resignation, then into ritual. Status reports, steering committees and “transformation programmes” become coping mechanisms, not solutions. People stop asking how to win and start asking how to survive without being noticed.

3. Trauma or acceptance: the two dominant corporate states

Once fear runs out, organisations tend to fall into one of two states.

The first is trauma. Everything feels urgent, but nothing is coherent. Decisions are reactive. Leaders shout about agility while adding layers of approval. Teams are burned out but still told to “push harder”. The lion is always seconds away, even if it has been chasing the company for five years and never quite closing the gap.

The second is acceptance. This is quieter and more dangerous. People accept that decline is inevitable. Innovation becomes cosmetic. Metrics are chosen to flatter rather than inform. The lion is no longer discussed because everyone has already made peace with being eaten, just not today.

Most large organisations oscillate between these two states, mistaking motion for progress and endurance for strategy.

4. The uncomfortable truth about your competitors

Here is the part most companies miss: even the organisations threatening your existence are running from their own lions. The market leader fears disruption. The disruptor fears regulation. The startup fears running out of cash. The giant fears becoming irrelevant. There is no finish line where the lion disappears forever.

The difference is not whether a lion exists. The difference is whether the organisation defines itself as prey or predator. Prey organisations optimise for escape. Predator organisations optimise for strength, position and intent. One is reactive by design. The other is deliberate, even under pressure.

Becoming the lion does not mean becoming ruthless or reckless. It means shifting from fear driven movement to purpose driven action. It means choosing where to run, who to chase and, critically, when to stop running altogether.

5. Seasons, not strategies

The hardest thing to do in any company is to transition between seasons. To run when you need to run, hunt when you need to hunt, laugh when you need to laugh and cry when you need to cry. Too many companies have institutionalised fear. Even when the season shifts around them, they do not acknowledge it and they do not react to it.

When it is your turn to be the lion, be the lion. When it is your turn to run, then run. Do not confuse bravery with stubbornness or caution with cowardice. The most amazing companies in the world can spin on a dime, moving from reacting to risk to chasing revenue, from dominating competition to enduring compression.

Whatever your leadership does, it needs to be able to shift. In the world we are moving into, you may be running from a lion in the morning and chasing impalas in the evening. Strategy that cannot change tempo is not strategy at all, it is inertia with better branding.

6. From running to choosing

The real transition is psychological, not structural. It is the moment an organisation stops asking “How do we avoid dying?” and starts asking “What game are we actually trying to win?” That shift changes how strategy is formed, how people are rewarded and how risk is understood. Survival is no longer the goal; it is merely the baseline.

If you are in a fear driven company, there is one thing you should understand clearly: compression is coming. It always does. It will not stop until leadership is durable and wise enough to respond to the waves of volatility that are now a permanent feature of the world.

Most companies never make this transition. They stay fit enough to keep running, but never strong enough to turn around. And in doing so, they condemn themselves to a lifetime of being chased by increasingly imaginary lions.

The irony is brutal but simple: the lion you are running from is probably just as scared as you are. The moment you realise that, you have a choice. Keep running until fear turns into numbness, or stop, turn around, and decide to become the lion.