Business Heads: Technology Leadership Competence Assessment
This is an assessment exists to surface how you actually think about leadership of technologists.
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. Start by mapping decision rights across the layers — the problem is usually unclear accountability, not layer count, and restructuring before you understand the decision flow creates new confusion
C. Run a survey of the engineering teams to understand where they feel blocked, and use that data to build the case for structural change with the executive team
D. Work with HR and the executive team to design a target operating model that defines the right number of layers for an organisation of this size and complexity
4. What Is the Primary Purpose of a Technology Strategy Document?
A. To force honest prioritisation — the document’s value is less in what it says you will do and more in making explicit what you have decided not to do, and why
B. To create alignment between the technology team and the business by documenting the investment thesis, sequencing, and dependencies in enough detail that stakeholders can make informed resource decisions
C. To give the engineering leadership team a stable reference point that protects them from constant re-prioritisation by the business, ensuring they can make consistent architectural decisions without relitigating direction every quarter
D. To give the organisation a shared language for what technology will and will not do, so that decisions at every level are made with the same understanding of intent and constraint
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 is designed so that any individual component can fail without taking the whole system down — blast radius containment is the architectural primitive everything else depends on
B. Ensuring the architecture makes failure observable — you cannot recover from what you cannot see, and the first architectural investment in any critical system should be comprehensive instrumentation
C. Ensuring the system can fail safely in ways that are reversible — the ability to roll back any change without data loss or state corruption is the property that makes every other architectural decision recoverable
D. Ensuring the system can scale to meet projected demand — an architecture that cannot grow with the business creates a ceiling that becomes the organisation’s primary constraint
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 — shipping broken software on time destroys trust faster than a short delay, and customers remember what breaks, not what was promised
B. Work with the team to identify the minimum viable increment that delivers genuine customer value and negotiate that boundary with the business — the answer is almost never full scope or nothing
C. Have an honest conversation with the business stakeholder about what the deadline is actually protecting — if it is an external commitment, explore whether a phased external delivery is possible rather than defaulting to internal scope cuts
D. Protect the deadline and scope by having the team identify which quality corners can be cut safely in the short term — technical debt incurred under clear conditions with a documented remediation plan is manageable
9. How Should Work Ideally Flow Through a Well Functioning Technology Team?
A. Through short, time-boxed iterations with explicit ceremonies for planning, review, and retrospection — the discipline of a regular rhythm creates the forcing function that stops work accumulating invisibly
B. Through continuous small changes deployed frequently with clear ownership and minimal handoffs — the feedback loop between shipping and learning is the primary engine of quality
C. Through a pull-based system where engineers take work when they have capacity rather than having it pushed through sprints — WIP limits and flow efficiency beat velocity as measures of team health
D. Through team-defined working agreements — the right flow depends on the team’s maturity, the product’s criticality, and the organisation’s deployment infrastructure, and imposing a single model is a failure of leadership
10. A Team Is Delivering Features on Time but Production Incidents Are Increasing
What does this tell you?
A. Run a blameless postmortem programme across the recent incidents and look for systemic patterns — you cannot address what you have not diagnosed, and the correlation might have multiple causes
B. Separate the delivery and reliability metrics and set explicit targets for both — the problem is likely that the team is optimising for the metric they are measured on, and reliability needs its own accountability
C. The delivery metric is masking a quality problem — when output speed and incident rate move in opposite directions, the team is borrowing against future reliability to protect current velocity
D. Have the team reduce their delivery cadence temporarily while you investigate the incidents — running at full speed while quality is degrading makes the diagnosis harder and the hole deeper
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 Proves You Wrong on a Technical Decision
What is the ideal response?
A. Thank them, update the decision, and be transparent with the team about the change and why — the fastest way to build a culture where people bring you problems is to demonstrate that bringing you problems leads to better outcomes
B. Thank them privately, take time to evaluate the evidence properly, and then communicate the revised decision to the team — public reversals can undermine team confidence in direction, and a short delay for due diligence is worth it
C. Evaluate the evidence collaboratively in the room — if the team surfaced this together, they should see the reasoning process that leads to the revised decision, not just the outcome
D. Change the decision based on the evidence, but address separately with the engineer how they raised it — the substance was right but the framing matters for team dynamics, and good challenge should be modelled constructively
29. What Is the Biggest Risk When a Non Technical Leader Runs a Technology Team?
A. They cannot tell the difference between a genuine technical constraint and a team protecting its comfort zone — which means they get exploited by both cautious engineers and dangerous ones, usually without knowing which is which
B. They make resourcing and prioritisation decisions without understanding how technical work compounds — adding people to a late project, cutting testing to save time, or treating platforms as interchangeable all seem reasonable from the outside
C. They optimise for relationship quality with the engineering team over technical outcomes — being liked by engineers is not the same as getting the best out of them, and the two can pull in opposite directions
D. They cannot credibly sponsor technology investment to the business — the inability to translate between engineering reality and commercial language means both sides get a distorted picture and decisions get made on incomplete information
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 — a system that the team who inherits it can understand, operate, and fix at 2am is worth more than one that impresses the people who designed it
B. Proposal A, subject to evidence that the performance gain is large enough to justify the operational cost — complexity is sometimes the right answer, and dismissing it categorically is its own form of dogma
C. Neither until you have done a failure mode analysis on both — operational complexity is one dimension but you also need to understand which proposal fails more gracefully under load, and Proposal B’s simplicity might not translate to resilience
D. Commission a time-boxed proof of concept for Proposal A — if the team can demonstrate they can operate it in a realistic failure scenario within a sprint, the expertise concern is addressed and the performance benefit is worth having
32. A 97 Slide Strategy Deck Is Presented to You
What is your reaction?
A. Scepticism — length often compensates for lack of clarity, and a strong strategy should be explainable in a few pages
B. Appreciation — a thorough strategy deck shows the team has done their due diligence and considered all angles
C. You would request an executive summary of no more than five slides that highlights the key investment asks and expected returns
D. You would review it in detail — strategic decisions of this magnitude deserve comprehensive analysis and supporting evidence
33. A High Performing 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. The team is delivering, incidents are low, and customers are satisfied. Adding a reporting requirement because governance needs something to read signals that you do not trust what you can already see.
B. It depends on the audience — the team may not need to report upward, but the leadership team does need a way to represent the team’s health and direction to stakeholders who do not have direct visibility. A lightweight mechanism that serves that need without creating overhead for the team is worth designing.
C. The absence of structured communication is itself a risk — not because the team is not performing, but because when something does go wrong there is no established cadence for escalation and the leadership team will not have the context to respond well.
D. The team should own the decision about how they communicate their work — if they have a better signal than a status report, they should be able to define that signal themselves, and the leadership team’s job is to specify what questions they need answered, not the format.
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, and 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 and ask what they are doing to reduce the unknowns — not knowing early in complex work is normal and healthy; what matters is whether the team has a method for converting uncertainty into clarity
B. Ask them to map what they do and do not know — a structured approach often reveals that there is more certainty available than the lead realises, and it gives you something concrete to track
C. Share your own uncertainty with them — tell them what you are being asked upstream and work together on what signal would be useful to provide at what cadence, so the communication plan is something they own rather than something imposed
D. Establish a regular check-in specifically to track the unknowns as they resolve — short, focused, without the overhead of formal status reporting
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
41. You Need a Delivery Commitment From a Team for an Executive Presentation Next Week
The team’s lead says they need two more days of discovery before they can give you a reliable estimate. What do you do?
A. Wait the two days — a commitment given before the work is understood is not a commitment, it is a guess with your name on it
B. Ask the team lead to give you a range rather than a date — a best and worst case scenario gives you something honest to present while the discovery continues
C. Go directly to the engineers doing the work to get a sense of the timeline — the lead may be being overly cautious and the people closest to the work often have a clearer view
D. Ask the team lead to give you their current best estimate clearly labelled as preliminary — you can update the executive as discovery completes
42. Halfway Through a Quarter, a Senior Lead Tells You the Original Plan Is No Longer Achievable
Your quarterly commitments to the executive team were based on the original plan. What do you do?
A. Work with the lead to understand the revised approach, update your executive commitments accordingly, and present the change with the reasoning — executives who receive honest revisions early make better decisions than those who receive surprises late
B. Ask the lead to exhaust every option for recovering the original plan before you escalate — changing executive commitments has a cost and you owe it to the team to explore alternatives first
C. Accept the revised approach internally but present the original commitments to the executive team while recovery options are explored — there is no point creating alarm until you know whether the plan can be saved
D. Ask the lead to document the revised approach and present it at the next quarterly review — in-quarter plan changes create instability and the business needs consistency to make good resource decisions
43. A Junior Engineer on Your Team Gives You a Timeline Estimate Directly
You later discover they gave it to you because their manager was unavailable and you asked them directly. The manager comes to you concerned that their team member was put in an uncomfortable position. How do you reflect on this?
A. The manager is right to raise it — going directly to a junior for a commitment bypasses the person accountable for that commitment and puts the junior in an unfair position. You should have waited for the manager.
B. The concern is understandable but the situation was pragmatic — you needed the information and the manager was unavailable. The right response is to clarify with the manager that this was a one-off.
C. The manager needs to ensure their team is available and empowered to communicate directly with senior leaders — creating barriers to information flow is itself a leadership problem worth addressing
D. You would apologise to both the manager and the junior and establish a clear protocol for how timeline requests should flow in future
44. Your CEO Asks You in a Leadership Meeting for a Firm Delivery Date on a Critical Initiative
Your team has told you privately that the date depends on two unresolved technical questions. What do you say?
A. Tell the CEO the expected date and the two conditions it depends on — a conditional commitment is more useful than a false firm one, and it gives the CEO the information they need to manage their own commitments
B. Give the date your team has indicated as most likely and follow up with the CEO privately once the technical questions are resolved — a leadership meeting is not the right forum for surfacing uncertainty
C. Ask to come back to the CEO with a confirmed date within 48 hours — committing to a date you are not confident in is worse than a short delay for verification
D. Give a date with a two-week buffer built in to absorb the uncertainty — the technical questions are likely resolvable within that window and the buffer protects the commitment
Answer Key With Explanations
1. A Major Platform Decision Was Approved Six Months Ago
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Prioritises the right outcome over protecting past decisions | Better products and fewer sunk costs |
| B | 🟡 | Honouring governance feels responsible | Delivery of the wrong thing, on time |
| C | 🟡 | Protecting board timelines is professionally safe | Informal concerns that go nowhere |
| D | 🔴 | Governance confidence is genuinely valuable | Entrenched wrong decisions and learned helplessness |
2. Your Team Proposes Removing an Integration Layer
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟡 | Respecting investment sounds fair | Sunk cost paralysis masquerading as empathy |
| B | 🟢 | Merits and customer outcomes as the deciding lens | Better systems and cleaner architecture |
| C | 🟡 | Socialisation reduces friction | Delay that allows the right call to be avoided indefinitely |
| D | 🔴 | Timeline acceleration is always a defensible frame | Technology decisions subordinated to scheduling |
3. You Inherit Seven Management Layers
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Cutting what adds no value is the only honest response | Faster decisions and cleaner accountability |
| B | 🟡 | Mapping decision rights sounds systematic and diagnostic | Rigorous process used to delay an obvious leadership call |
| C | 🟡 | Gathering evidence from engineers sounds inclusive | Data collection as a substitute for a decision that does not need more data |
| D | 🔴 | Target operating model design sounds like proper transformation methodology | Outsourcing an obvious leadership call to HR and a consulting framework |
4. What Is the Primary Purpose of a Technology Strategy Document?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Strategy is mostly about what you will not do — rare clarity that actually guides decisions | Fewer wasted investments and better decisions at every level |
| B | 🔴 | Investment thesis and stakeholder alignment sound thorough and mature | A budget document dressed as strategy; optimises for approval rather than clarity |
| C | 🟡 | Protecting engineering from re-prioritisation sounds like good leadership | Strategy as a shield rather than a tool; wrong frame even if the intention is right |
| D | 🟡 | Shared language and shared intent sound like the right outcome | Correct instinct, slightly weaker framing — emphasises communication over the harder work of explicit non-choices |
5. What Does Blast Radius Mean?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct definition with systems thinking built in | Better architectural decisions and safer design |
| B | 🟡 | Data loss is a real concern | Conflates backup and resilience concepts |
| C | 🟡 | Customer impact is the right concern | Misses cascading failure as the core concept |
| D | 🔴 | Financial framing is relatable to business heads | Revenue lens applied to an engineering concept |
6. When Designing a Critical System, What Is Your Primary Architectural Concern?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Blast radius containment is the foundational principle — everything else depends on it | Systems where failures are contained rather than cascading |
| B | 🟡 | Observability sounds sophisticated and operationally mature | Monitoring prioritised over designing for failure in the first place |
| C | 🟡 | Rollback capability is excellent engineering discipline | A deployment concern elevated to an architectural principle; important but not primary |
| D | 🟡 | Scale is a real design constraint | Optimises for growth at the expense of resilience; the wrong primary concern for a critical system |
7. What Does Designing Assuming Breach Mean?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Layered defence and containment is the correct instinct | Systems that limit damage when breaches happen |
| B | 🟡 | Insurance feels like risk management | Financial mitigation without technical defence |
| C | 🟡 | Penetration testing is a real practice | Annual exercises are not the same as assume breach design |
| D | 🟡 | Compliance feels like security | Compliance theatre that passes audits and fails breaches |
8. A Project Is Behind Schedule
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Quality over date is the harder but more durable choice | Systems that work and users who trust them |
| B | 🟡 | Customer value focus and collaborative negotiation sound mature | Reframes the question rather than answering it; delays the obvious call |
| C | 🟡 | Challenging what the deadline is protecting sounds commercially sophisticated | Defers the quality trade-off to a negotiation that may not be available |
| D | 🔴 | Documented tech debt with a remediation plan sounds like engineering discipline | Systematic quality erosion with a paper trail that makes it feel managed |
9. How Should Work Flow Through a Technology Team?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟡 | Agile ceremonies are familiar and provide rhythm | Process compliance rather than actual agility |
| B | 🟢 | Continuous flow and minimal handoffs are what actually work | Fast learning and high quality delivery |
| C | 🟡 | Kanban and WIP limits are genuinely more sophisticated than sprints | A real and defensible model, but misses the continuous deployment emphasis |
| D | 🔴 | Respecting team autonomy and context sounds like progressive leadership | Abdicating the leadership responsibility to create conditions for high performance |
10. Features on Time but Incidents Increasing
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟡 | Postmortems and systematic diagnosis sound like good SRE practice | Understanding individual incidents without diagnosing the structural relationship between delivery pace and quality |
| B | 🟡 | Metric design and accountability framing sound like smart leadership | Treats the symptom — misaligned incentives — rather than the cause |
| C | 🟢 | Delivery masking quality debt is the most common failure pattern | Early intervention before the system breaks loudly |
| D | 🟡 | Slowing down while investigating sounds like responsible engineering leadership | Often the right call, but does not answer what is actually happening |
11. Vertical Versus Horizontal Scaling
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and precise | Ability to make informed infrastructure decisions |
| B | 🟡 | Storage and bandwidth are real dimensions | Fundamentally wrong definition |
| C | 🟡 | Database versus app server is a familiar split | Oversimplification that breaks in practice |
| D | 🔴 | Cost framing is relatable | Reduces a technical question to a finance question |
12. What Is Technical Debt?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct definition that connects to consequences | Ability to have honest conversations about investment |
| B | 🟡 | Licence and infrastructure costs feel like debt | Confuses financial obligations with technical constraints |
| C | 🟡 | Target state framing is familiar from transformation programmes | Reduces debt to a migration backlog |
| D | 🟡 | Legacy systems are a common mental model | Misses the fact that new systems accumulate debt too |
13. Why Does Observability in Production Matter?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and operationally grounded | Engineers who can diagnose and improve systems |
| B | 🟡 | Compliance evidence is a real requirement | Monitoring as audit artefact rather than operational tool |
| C | 🟡 | Business dashboards are a legitimate need | Confuses business reporting with system observability |
| D | 🔴 | SLA qualification sounds like a practical reason | Observability in service of vendor contracts, not operations |
14. The Primary Benefit of Public Cloud
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | On demand provisioning and elastic cost is the real value | Infrastructure that scales with reality |
| B | 🟡 | Cost reduction is often part of the pitch | False certainty that ignores workload specifics |
| C | 🔴 | Compliance automation sounds appealing | Dangerous misunderstanding of shared responsibility |
| D | 🔴 | Elimination of overhead sounds efficient | Cloud adoption without understanding what you still own |
15. The Shared Responsibility Model
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and precise | Security decisions made with accurate mental models |
| B | 🟡 | Commercial framing is relatable | Confuses security responsibility with cost sharing |
| C | 🟡 | Shared accountability sounds balanced | Removes the clarity that makes the model useful |
| D | 🔴 | Full provider responsibility sounds like the deal | Organisations that discover their responsibilities too late |
16. What Is an Availability Zone?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and operationally precise | Architecture that plans for and survives zone failures |
| B | 🟡 | Regions are a real cloud concept | Conflates region with zone |
| C | 🟡 | Network isolation is a related cloud concept | Confuses network boundaries with physical redundancy |
| D | 🔴 | Pricing tiers and uptime SLAs are familiar procurement concepts | Infrastructure decisions made on commercial rather than technical grounds |
17. What Is Infrastructure as Code?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and captures the key properties | Reproducible, reviewable, version controlled infrastructure |
| B | 🟡 | Diagram generation is a related practice | Confuses documentation tooling with infrastructure management |
| C | 🟡 | Documentation in a shared wiki sounds collaborative | Infrastructure decisions recorded but not enforced |
| D | 🔴 | Budget coding sounds like responsible governance | A finance process confused for an engineering practice |
18. When Should Testing Happen?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Continuous automated testing is the correct answer | Fast feedback and high confidence with every change |
| B | 🟡 | Dedicated testing phases feel thorough | Late discovery of problems that compound quickly |
| C | 🔴 | Milestone sign off sounds like governance | Testing as a gate rather than a continuous signal |
| D | 🟡 | Pre release exploratory testing is real and valuable | Leaves too much surface area uncovered between releases |
19. A Team Has 95% Code Coverage
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Coverage without behaviour validation is a known trap | Honest assessment of quality rather than metric satisfaction |
| B | 🔴 | 95% sounds high and therefore safe | False confidence in a metric that can be gamed |
| C | 🟡 | Module level breakdown adds nuance | Still treats coverage as the primary quality signal |
| D | 🔴 | Benchmarking sounds rigorous | Comparing against benchmarks of a flawed metric |
20. What Is the Purpose of a Chaos Engineering Exercise?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Deliberate failure injection to test recovery is correct | Verified resilience rather than assumed resilience |
| B | 🟡 | Load testing is a related practice | Confuses performance testing with resilience testing |
| C | 🟡 | DR failover testing is real and important | Narrower than chaos engineering as a practice |
| D | 🔴 | Incident process stress testing sounds useful | Focuses on the organisation’s response rather than the system’s behaviour |
21. Data Warehouse Versus Data Lake
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct definition that captures the key architectural difference | Informed decisions about where data belongs |
| B | 🟡 | On premises versus cloud is a familiar axis | Conflates deployment model with data architecture |
| C | 🟡 | Team ownership is a real governance question | Reduces an architectural concept to an org chart question |
| D | 🔴 | Historical versus real time is a familiar framing | Fundamentally misunderstands both concepts |
22. Building a Churn Prediction Model
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Data quality and bias are the foundation of any model | Models that work and can be trusted |
| B | 🟡 | Revenue impact is a legitimate prioritisation question | Skips past the foundational data question |
| C | 🟡 | Vendor platforms are a real option | Deploy fast, discover limits later |
| D | 🔴 | Demonstrating value to the executive committee is real pressure | AI theatre that looks impressive and produces wrong answers |
23. The Biggest Risk of Unmonitored Production Models
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Data drift and silent degradation is the real risk | Monitoring practices that catch decay before it causes harm |
| B | 🟡 | Compute costs are a real operational concern | Misses the accuracy decay that is far more damaging |
| C | 🟡 | Governance review is a legitimate process | Compliance framing misses the operational risk |
| D | 🔴 | Executive confidence is a real concern | Optimises for perception rather than reliability |
24. A Biased AI Model Is Proposed for Customer Decisions
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Takes bias seriously as a first order concern | Ethical deployment and regulatory protection |
| B | 🟡 | Human review sounds like a safeguard | Scales bias while providing legal cover |
| C | 🟡 | Steering committee decision sounds like governance | Delegates an ethical decision to a commercial forum |
| D | 🔴 | First mover advantage is a real competitive argument | Discrimination at scale with a future iteration that may never arrive |
25. One AI Engineer Embedded in a Feature Team
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Recognises the structural failure clearly | Deliberate community of practice and proper quality gates |
| B | 🟡 | Clear deliverables and product ownership sound sufficient | Unreviewed AI work validated by people who cannot evaluate it |
| C | 🔴 | Embedded specialists sound efficient | AI capability that has no peers, no quality gate, and no future |
| D | 🟡 | Training and milestone measurement sound supportive | Isolates the engineer while providing the appearance of support |
26. What Is Data Governance in Practice?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Treats data as a product with full lifecycle accountability | Trustworthy data that can be used with confidence |
| B | 🟡 | Policy and committee governance is a real structure | Bureaucratic access management masquerading as governance |
| C | 🟡 | Classification and retention policies are real requirements | Compliance artefacts without operational governance |
| D | 🔴 | Technology controls feel like governance | Enforces access without understanding what the data is or means |
27. You Need to Hire a Senior Engineer
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Curiosity and simplification track record predict long term impact | Engineers who make systems better rather than just larger |
| B | 🟡 | Certifications feel like proof of knowledge | Credential matching rather than capability hiring |
| C | 🟡 | Communication with executives sounds valuable | Engineers selected for stakeholder management over technical depth |
| D | 🔴 | Delivery track record sounds like the right signal | Engineers selected by programme managers rather than engineers |
28. An Engineer Proves You Wrong
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Transparency about being wrong builds the culture where truth surfaces | Trust, psychological safety, and better decisions |
| B | 🟡 | Private thanks and considered revision sounds mature and leadership-aware | Ego-protection dressed as team stability; teaches people that public challenge makes leaders uncomfortable |
| C | 🟡 | Collaborative evaluation in the room sounds transparent | Can become a performance of open-mindedness rather than genuine reconsideration |
| D | 🔴 | Addressing the framing separately sounds like coaching maturity | Punishes someone for being right in front of others; teaches everyone else to be less direct |
29. The Biggest Risk of a Non Technical Leader
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Inability to distinguish risk from excuses is the core failure mode — it causes damage in both directions | Leaders who get exploited by cautious engineers and dangerous ones alike, without knowing which is which |
| B | 🟡 | Resourcing and prioritisation errors are a real and visible pattern | One consequence of A — downstream, not the root |
| C | 🟡 | Optimising for relationship over outcomes is a genuine failure mode | Real but secondary — a symptom of misaligned incentives, not the core risk |
| D | 🟡 | Translation failure between engineering and business is real and damaging | Also downstream — a consequence of not understanding the domain, not the primary risk itself |
30. A Vendor Promises to Solve a Critical Problem
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Exit costs and vendor direction changes are the durable concerns | Relationships that preserve architectural independence |
| B | 🟡 | Procurement process is a real requirement | Approved vendor lists substituting for technical evaluation |
| C | 🟡 | Case studies are useful social proof | NPS and reference customers replacing structural analysis |
| D | 🔴 | Timeline alignment is always relevant | Vendor selected based on board commitments rather than fit |
31. Clever Architecture Versus Simple Architecture
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Operability and maintainability outlast impressiveness | Systems that the next team can understand and fix at 2am |
| B | 🟡 | Nuanced trade-off thinking sounds like mature engineering judgment | Always finds a reason to pick the impressive option when the leader already prefers it |
| C | 🟡 | Failure mode analysis sounds like rigorous systems thinking | Introduces a valid analytical step to delay a principle that should not need analysis |
| D | 🔴 | Empirical proof of concept sounds like evidence-based decision making | Creates a process designed to produce the answer the leader wanted; complexity wins by surviving the sprint |
32. A 97 Slide Strategy Deck
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Length compensating for clarity is a real and common failure | Pressure for clear thinking over comprehensive coverage |
| B | 🔴 | Thoroughness sounds like due diligence | Rewarding volume over clarity |
| C | 🟡 | Executive summary sounds practical | May preserve the 97 slides rather than replacing them |
| D | 🟡 | Comprehensive review sounds responsible | 97 slides reviewed without asking whether they add up to a strategy |
33. A High Performing Team Has No Status Report
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Outcomes are the evidence — reports are not the product | Freedom for high performing teams to focus on results |
| B | 🟡 | Designing a lightweight stakeholder mechanism sounds pragmatic and considerate | Process for its own sake; lightweight mechanisms rarely stay lightweight |
| C | 🟡 | Contingency thinking sounds like foresight | Using hypothetical future failure to justify present-day process imposition |
| D | 🔴 | Team-defined communication sounds like progressive autonomy | Frames upward communication as the team’s problem to solve; leadership abdicates the responsibility to interpret outcomes for stakeholders |
34. A Team Adjusts and Delivers Two Weeks Late
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Adaptation during complex work is exactly correct behaviour | A culture that engages honestly with what they discover |
| B | 🔴 | Planning failure is a clean and familiar frame | Teams that fabricate certainty rather than discovering truth |
| C | 🟡 | Lessons learned sounds constructive | Document production as a substitute for genuine understanding |
| D | 🔴 | Risk management logging sounds rigorous | More assumption validation that produces more fabricated certainty |
35. A Lead Says They Do Not Know Yet
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Not knowing is valid — what matters is the method for reducing uncertainty | Honest engineering cultures that surface uncertainty early |
| B | 🟡 | Structured mapping of knowns and unknowns sounds like useful coaching | Discomfort with uncertainty disguised as methodology; turns “I don’t know” into a framework exercise |
| C | 🟡 | Collaborative communication planning sounds psychologically safe | Shifts focus from reducing uncertainty to managing how it is communicated |
| D | 🟡 | Lightweight check-ins sound supportive | Process overhead created in response to something that did not need a process response |
36. What Is the Most Important Thing to Measure?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Business outcomes, reliability, and safe change are what technology actually exists to produce | Measurement that connects engineering work to things that matter |
| B | 🟡 | Velocity is a familiar agile metric | Story point farming that looks productive and may not be |
| C | 🟡 | Time to market is a real business concern | Optimises for speed over quality and sustainability |
| D | 🔴 | Budget adherence sounds like financial discipline | Measuring spend rather than value |
37. A Senior Architect Disagrees Publicly and Bluntly
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Blunt disagreement backed by evidence is a sign of health | Better decisions and a culture where truth surfaces |
| B | 🟡 | Proper channels sound professional | Teaching people that public disagreement is insubordination |
| C | 🟡 | Commitment after a decision is a real norm | Commitment used to prevent legitimate reconsideration |
| D | 🔴 | Business timelines as the final frame sounds balanced | Technical expertise subordinated to schedule compliance |
38. The Role of Engineers in Decision Making
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Active extraction and synthesis of engineering knowledge is how the best decisions get made | Products built from collective intelligence rather than individual instruction |
| B | 🟡 | Business leaders owning commercial outcomes sounds right | Technical input as decoration on pre-made decisions |
| C | 🟡 | Execution excellence and implementation autonomy sound respectful | Engineers who are good at what they are told but disconnected from why |
| D | 🔴 | Product and business teams driving strategy sounds efficient | Strategy uninformed by the technical reality that will determine whether it is achievable |
39. Your Best Engineers Have Gone Quiet
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Silence from strong engineers is almost always a warning | Early intervention before the best people leave in spirit or in practice |
| B | 🟡 | Focus and preference for code over meetings is real | Convenient reframe that avoids the harder question |
| C | 🟡 | Team maturity and alignment sound positive | Alignment that is actually submission |
| D | 🔴 | Fewer objections sounds like improved governance | A team that has learned not to disagree with leaders who do not want to hear it |
40. An Engineer Says the Deadline Is Unrealistic
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Engineers who raise deadline alarms are usually right | Credible timelines and teams that are not burned out shipping things that break |
| B | 🟡 | Alternative timeline with breakdown sounds constructive | Amber because the warning should be taken seriously before asking for proof |
| C | 🔴 | Commercial commitments sound binding | Teams that silently absorb impossible constraints and deliver broken software |
| D | 🟡 | Quantified risk sounds rigorous | Can become a bar set high enough that legitimate warnings are never escalated |
41. You Need a Delivery Commitment From a Team for an Executive Presentation Next Week
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | A commitment before the work is understood is just a guess with your name on it | Reliable commitments built on real understanding rather than manufactured certainty |
| B | 🟡 | A range sounds honest and practical | Still extracts a number before the work is understood; just makes the uncertainty visible rather than eliminating it |
| C | 🔴 | Going to the source sounds like getting closer to ground truth | Bypasses the accountable person to find someone who will give you the answer you need; the junior engineer has no context for what they are committing to |
| D | 🟡 | Preliminary estimate with a label sounds transparent | Preliminary estimates have a way of becoming the commitment regardless of the label |
42. Halfway Through a Quarter, a Senior Lead Tells You the Original Plan Is No Longer Achievable
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Executives who receive honest revisions early make better decisions than those who receive surprises late | A leadership culture where truth travels upward quickly |
| B | 🟡 | Protecting executive commitments sounds responsible | Protecting the plan rather than protecting the outcome; the lead’s revised approach may be correct and delay compounds the cost |
| C | 🔴 | Avoiding alarm until you know whether the plan can be saved sounds measured | Withholding material information from the people who need it to manage their own commitments; manufactures false confidence at the most consequential level |
| D | 🔴 | Quarterly review stability sounds like discipline | Delays a decision that needs to be made now; the business cannot make good resource decisions on information it does not have |
43. A Junior Engineer Gives You a Timeline Estimate Directly
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | The manager is right — bypassing them puts the junior in an impossible position and removes accountability from the person who carries it | Healthy team structures where accountability and information flow through the right channels |
| B | 🟡 | Pragmatism in an urgent situation sounds reasonable | Normalises the bypass as a situational exception; the exception becomes the pattern |
| C | 🔴 | Empowering direct communication sounds like progressive leadership | Reframes the manager’s legitimate concern as a performance failure; dismantles the accountability structure that protects juniors from being used as commitment-extraction tools |
| D | 🟡 | Apologising and establishing a protocol sounds constructive | Treats a behaviour problem as a process gap; the protocol will not survive the next urgent situation |
44. Your CEO Asks for a Firm Delivery Date and You Have Two Unresolved Technical Questions
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | A conditional commitment is more useful than a false firm one | CEOs who can manage their own commitments accurately because they have accurate information |
| B | 🔴 | Reading the room sounds like leadership maturity | Manufactures false certainty in the most consequential forum; the private follow-up rarely happens with the same urgency as the original commitment |
| C | 🟡 | Asking to come back sounds responsible | Correct instinct, but may not always be available; the stronger skill is giving an honest conditional answer in the room |
| D | 🟡 | A buffer sounds like prudent risk management | Hides uncertainty inside a padded number; the CEO is managing their commitments on a date that has invisible assumptions baked into it |
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, structured frameworks, and familiar governance patterns because they feel responsible and rigorous. Under pressure, those defaults will pull you toward comfort rather than clarity. The most telling pattern: if your 🟡 answers cluster in delivery, planning, or people questions, you are likely performing good leadership rather than practising it. Watch which categories your 🟡 answers appear in — that is where your blind spots live.
Mostly 🔴 means you optimise for timelines, reporting, and the appearance of control. You may believe you are being commercially mature or protecting your team, but the pattern reveals something else: technical decisions that serve schedules, quality trade-offs dressed as engineering discipline, and an instinct to manage upward rather than solve downward. 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