This is an assessment. It is not balanced. It is not here to validate your instincts, your planning methodology, or your confidence in the delivery framework you inherited. It exists to surface how you actually think about technology leadership when you are deciding whether to trust an engineer, approve a pivot, or override a technical warning to protect a timeline.
Answer honestly. Not as the executive you present in interviews. As the leader you become when the deadline is real, the team is pushing back, and someone senior is asking you for certainty you do not have.
Every option is phrased to sound reasonable, responsible, and professionally defensible. That is the point. The wrong answers are rarely stupid. They are comfortable.
How to Score Yourself
🟢 Strong technology leadership instinct – demonstrates systems thinking, quality, sustainability, and genuine respect for engineering as a discipline
🟡 Acceptable but surface level – not wrong, but reveals a preference for process, optics, or a management lens over a technology leadership lens
🔴 Concerning – reveals a fixation on timelines, revenue, reporting ceremony, or a belief that technologists are execution resources who should deliver rather than think
After answering all questions, count how many 🟢, 🟡, and 🔴 answers you selected. Then read the interpretation at the end.
Questions:
1. A Major Platform Decision Was Approved Six Months Ago
New evidence suggests it may be the wrong choice. What do you do?
A. Revisit the decision with the new evidence and recommend a course correction even if it causes short term disruption
B. Flag the concern but continue execution since the committee already approved it and reversing would delay the programme
C. Raise it informally but keep delivery on track since the timeline commitments to the board cannot slip
D. Continue as planned because reopening approved decisions undermines confidence in the governance process
2. Your Team Proposes Removing an Integration Layer
It will reduce complexity but invalidate three months of another team’s work. How do you proceed?
A. Protect the other team’s work and find a compromise that keeps both approaches since we need to respect the investment already made
B. Evaluate the simplification on its technical merits regardless of sunk cost and proceed if the outcome is better for customers
C. Delay the decision until next quarter’s planning cycle so it can be properly socialised across all stakeholders
D. Proceed only if the simplification can be shown to accelerate the current delivery timeline
3. You Inherit Seven Management Layers Between CTO and Engineers
What is your first instinct?
A. Understand why each layer exists and remove any that do not directly contribute to decision quality or delivery outcomes
B. Add a dedicated delivery management function to coordinate across the layers more effectively
C. Maintain the structure but introduce better reporting dashboards so you can see through the layers
D. Restructure the layers around revenue streams so each layer has clear commercial accountability
4. What Is the Primary Purpose of a Technology Strategy Document?
A. To secure budget approval by demonstrating alignment between technology investments and projected revenue growth
B. To reduce uncertainty by clarifying what the organisation will and will not build, and why
C. To provide a roadmap with delivery dates that the business can hold the technology team accountable to
D. To communicate the technology vision to non technical stakeholders in a way they find compelling
5. What Does Blast Radius Mean in Systems Architecture?
A. The scope of impact when a single component fails, and how far the failure propagates across dependent systems
B. The amount of data lost during a disaster recovery event before backups can be restored
C. The total number of customers affected during a planned maintenance window
D. The financial exposure created by a system outage, measured in lost revenue per minute
6. When Designing a Critical System, What Is Your Primary Architectural Concern?
A. Ensuring the system can scale to meet projected revenue targets for the next three years
B. Designing for graceful failure so the system degrades safely rather than failing catastrophically
C. Selecting the vendor with the strongest enterprise support agreement and SLA guarantees
D. Ensuring the architecture aligns with the approved enterprise reference model and standards
7. What Does It Mean to Design a System Assuming Breach Will Happen?
A. Building layered defences, monitoring, and containment so that when a breach occurs the damage is limited and detected quickly
B. Purchasing comprehensive cyber insurance to cover the financial impact of a breach event
C. Conducting annual penetration tests and remediating all critical findings before the next audit cycle
D. Ensuring all systems are compliant with the relevant regulatory frameworks and industry standards
8. A Project Is Behind Schedule
The team suggests reducing scope to meet the deadline. The business stakeholder wants the full scope delivered on time. What do you recommend?
A. Deliver the reduced scope with high quality and iterate, since shipping broken software on time is worse than shipping less software that works
B. Add additional resources to accelerate delivery since the business committed to the date with external partners
C. Negotiate a two week extension with the full scope since the revenue impact of a delayed launch is manageable
D. Split the team to deliver the core features on time and the remaining features two weeks later as a fast follow
9. How Should Work Ideally Flow Through a Well Functioning Technology Team?
A. Through two week sprints with defined ceremonies, backlog grooming, sprint reviews, and retrospectives
B. Through continuous small changes deployed frequently with clear ownership and minimal handoffs
C. Through quarterly planning cycles with monthly milestone reviews and weekly status reporting
D. Through a prioritised backlog managed by a product owner who coordinates with the business on delivery sequencing
10. A Team Is Delivering Features on Time but Production Incidents Are Increasing
What does this tell you?
A. The team is likely cutting corners on quality to meet deadlines and the delivery metric is masking a growing technical debt problem
B. The team needs better production support tooling and a dedicated site reliability function
C. The team is delivering well but the infrastructure team is not scaling the platform to match the increased feature throughput
D. The incident management process needs improvement since faster triage would reduce the apparent incident volume
11. What Is the Difference Between Vertical Scaling and Horizontal Scaling?
A. Vertical scaling adds more power to a single machine while horizontal scaling adds more machines to distribute the load
B. Vertical scaling increases storage capacity while horizontal scaling increases network bandwidth
C. Vertical scaling is for databases and horizontal scaling is for application servers
D. Vertical scaling is cheaper at small volumes while horizontal scaling is cheaper at large volumes, which is why you choose based on cost projections
12. What Is Technical Debt?
A. Shortcuts or suboptimal decisions in code and architecture that make future changes harder, slower, or riskier
B. The accumulated cost of software licences and infrastructure that the organisation is contractually committed to paying
C. The gap between the current technology stack and the approved target state architecture
D. Legacy systems that have not yet been migrated to the cloud as part of the digital transformation programme
13. Why Is It Important That a System Can Be Observed in Production?
A. Because without visibility into how the system behaves under real conditions you cannot diagnose problems, understand performance, or detect failures early
B. Because the compliance team requires evidence that systems are being monitored as part of the annual audit
C. Because the business needs real time dashboards showing transaction volumes and revenue metrics
D. Because the vendor SLA requires the organisation to demonstrate monitoring capability to qualify for support credits
14. What Is the Primary Benefit of a Public Cloud Provider Like AWS or Azure?
A. The ability to provision and scale infrastructure on demand without managing physical hardware, paying only for what you use
B. Guaranteed lower costs compared to on premises infrastructure for all workload types and volumes
C. Automatic compliance with all regulatory requirements since the cloud provider manages the security controls
D. Eliminating the need for a technology team since the cloud provider manages everything end to end
15. What Is the Shared Responsibility Model in Cloud Computing?
A. The cloud provider is responsible for the security of the cloud infrastructure while the customer is responsible for securing what they build and run on it
B. The cloud provider and the customer share the cost of infrastructure equally based on a negotiated commercial agreement
C. Both the cloud provider and the customer have equal responsibility for all aspects of security and neither can delegate
D. The cloud provider assumes full responsibility for everything deployed on their platform as part of the service agreement
16. What Is an Availability Zone?
A. A physically separate data centre within a cloud region, designed so that failures in one zone do not affect others
B. A geographic region where the cloud provider offers services, such as Europe West or US East
C. A virtual network boundary that isolates different customer workloads from each other for security purposes
D. A pricing tier that determines the level of uptime guarantee and support response time for your workloads
17. What Is Infrastructure as Code?
A. Defining and managing cloud infrastructure through machine readable configuration files that can be version controlled and reviewed like software
B. A software tool that automatically generates infrastructure diagrams from the live cloud environment
C. A methodology for documenting infrastructure decisions in a shared wiki so the team can track changes over time
D. An approach where infrastructure costs are coded into the project budget as a separate line item from application development
18. When Should Testing Happen in the Development Lifecycle?
A. Continuously throughout development, with automated tests running on every code change as part of the build pipeline
B. After development is complete, during a dedicated testing phase before the release is approved for production
C. At key milestones defined in the project plan, with formal sign off required before moving to the next phase
D. Primarily before major releases, with exploratory testing conducted by the QA team in the staging environment
19. A Team Tells You They Have 95% Code Coverage
How confident should you be in their quality?
A. Coverage alone does not indicate quality because tests can cover code without meaningfully validating behaviour or edge cases
B. Very confident since 95% coverage means almost all of the codebase has been validated by automated tests
C. Moderately confident but you would want to see the coverage broken down by module to check for gaps in critical areas
D. You would need to compare the coverage metric against the industry benchmark for their technology stack to assess it properly
20. What Is the Purpose of a Chaos Engineering or Game Day Exercise?
A. To deliberately introduce failures into a system to test how it responds and to build confidence that recovery mechanisms work
B. To simulate peak traffic scenarios to verify the infrastructure can handle projected load during high revenue periods
C. To test the disaster recovery plan by failing over to the secondary site and measuring recovery time against the SLA
D. To stress test the team’s incident management process and identify bottlenecks in the escalation procedures
21. What Is the Difference Between a Data Warehouse and a Data Lake?
A. A data warehouse stores structured, curated data optimised for querying and reporting, while a data lake stores raw data in its native format for flexible future use
B. A data warehouse is an on premises solution while a data lake is a cloud native service that replaces the need for traditional databases
C. A data warehouse is owned by the business intelligence team while a data lake is owned by the engineering team, which is why they are governed separately
D. A data warehouse handles historical data for compliance purposes while a data lake handles real time data for operational dashboards
22. Your Organisation Wants to Build a Machine Learning Model to Predict Customer Churn
What is the first question you should ask?
A. Do we have clean, representative data that captures the behaviours and signals that precede churn, and do we understand the biases in that data
B. What is the expected revenue impact of reducing churn by a target percentage, and does it justify the investment in a data science team
C. Which vendor platform offers the best prebuilt churn prediction model so we can deploy quickly without building a team from scratch
D. Can we have a working model within the current quarter so we can demonstrate the value of AI to the executive committee
23. What Is the Biggest Risk of Deploying a Machine Learning Model Without Ongoing Monitoring?
A. The model will silently degrade as real world data drifts away from the data it was trained on, producing increasingly wrong predictions that nobody notices until damage is done
B. The model will consume increasing amounts of compute resources over time, driving up infrastructure costs beyond the original budget
C. The compliance team may flag the model as a risk because it was deployed without a formal model governance review and sign off process
D. The business will lose confidence in AI if the model produces a visible error, which could jeopardise funding for future AI initiatives
24. A Business Stakeholder Wants an AI Feature That Automates a Customer Decision
The team warns that the training data contains historical bias. What do you do?
A. Take the bias concern seriously. Deploying a biased model at scale will amplify discrimination, create regulatory exposure, and damage customer trust in ways that are extremely difficult to undo
B. Proceed with the deployment but add a disclaimer that the model’s recommendations should be reviewed by a human before any final decision is made
C. Ask the data science team to quantify the bias impact and present a risk assessment to the steering committee so leadership can make an informed commercial decision
D. Deprioritise the concern for now and launch the feature since the competitive advantage of being first to market outweighs the risk, and the bias can be addressed in a future iteration
25. You Have One AI Engineer Embedded in a Feature Team
Nobody in the team or its management chain has AI or machine learning experience. The engineer’s work is reviewed by people who do not understand it. How do you evaluate this structure?
A. This is a problem. The engineer has no peers to learn from, no manager who can grow their career, and no quality gate on their work. They will either stagnate, produce unchallenged work of unknown quality, or leave. AI engineers need to sit in or be connected to a community of practice with people who understand their discipline
B. This is fine as long as the engineer has clear deliverables and the feature team has a strong product owner who can validate the business outcomes of the AI work
C. This is efficient. Embedding specialists directly in feature teams ensures their work is aligned with delivery priorities and avoids the overhead of a separate AI team that operates disconnected from the product
D. This is manageable. Provide the engineer with access to external training and conferences so they can maintain their skills, and ensure their performance is measured on delivery milestones like any other team member
26. What Does Data Governance Mean in Practice?
A. Ensuring the organisation knows what data it has, where it lives, who owns it, how it flows, what quality it is in, and what rules govern its use, so that data is treated as a product rather than an accident
B. A framework of policies and committees that approve data access requests and ensure all data usage complies with the relevant regulatory requirements
C. A set of data classification standards and retention policies that are documented and audited annually to satisfy regulatory obligations
D. A technology platform that enforces role based access controls and encrypts data at rest and in transit across all systems
27. You Need to Hire a Senior Engineer
Which quality matters most?
A. Deep curiosity, the ability to reason through unfamiliar problems, and a track record of simplifying complex systems
B. Certifications in the specific technologies your team currently uses, with at least ten years of experience in the industry
C. Strong communication skills and experience presenting to executive stakeholders and steering committees
D. A proven ability to deliver projects on time and within budget, with references from previous programme managers
28. An Engineer Pushes Back on a Technical Decision You Made
They provide evidence you were wrong. What is the ideal response?
A. Thank them, evaluate the evidence, and change the decision if the evidence warrants it because being right matters more than being in charge
B. Acknowledge their input and ask them to document their concerns formally so they can be reviewed in the next architecture review board
C. Listen carefully but explain the broader strategic context they may not be aware of that influenced your original decision
D. Appreciate the initiative but remind them that decisions at your level factor in commercial and timeline considerations beyond the technical merits
29. What Is the Biggest Risk When a Non Technical Leader Runs a Technology Team?
A. They cannot distinguish between genuine technical risk and comfortable excuses, which leads to either missed danger or wasted time
B. They tend to over rely on vendor solutions and consultancies because they cannot evaluate build versus buy decisions independently
C. They struggle to earn the respect of senior engineers, which leads to talent attrition and difficulty recruiting strong replacements
D. They focus on timelines and deliverables rather than the technical foundations that determine whether those deliverables are sustainable
30. A Vendor Promises to Solve a Critical Problem
What is your first concern?
A. Whether the solution creates a dependency that will be expensive or impossible to exit, and what happens when the vendor changes direction
B. Whether the vendor is on the approved procurement list and whether the commercial terms fit within the current budget cycle
C. Whether the vendor has case studies from similar organisations and what their Net Promoter Score is among existing customers
D. Whether the vendor can commit to a delivery timeline that aligns with the programme milestones already communicated to the board
31. You Are Reviewing Two Architecture Proposals
Proposal A is clever and impressive but requires deep expertise to operate. Proposal B is simpler but less elegant. Which do you prefer?
A. Proposal B, because a system that can be understood, operated, and maintained by the team that inherits it is more valuable than one that impresses today
B. Proposal A, because the additional complexity is justified if it delivers significantly better performance metrics
C. Neither until both proposals include detailed cost projections and a total cost of ownership comparison over five years
D. Whichever proposal the lead architect recommends since they have the deepest technical context on the constraints
32. A 97 Slide Strategy Deck Is Presented to You
What is your reaction?
A. Scepticism, because length often compensates for lack of clarity and a strong strategy should be explainable in a few pages
B. Appreciation, because a thorough strategy deck shows the team has done their due diligence and considered all angles
C. Request an executive summary of no more than five slides that highlights the key investment asks and expected returns
D. Review it in detail because strategic decisions of this magnitude deserve comprehensive analysis and supporting evidence
33. A Technology Team Has No Weekly Status Report
They deploy daily, incidents are low, and customers are satisfied. Is this a problem?
A. No. Outcomes are the evidence. If the system works, customers are happy, and the team ships reliably, the absence of a status report means nothing is being hidden
B. Yes. Without a structured weekly report the leadership team has no visibility into what the team is doing and cannot govern effectively
C. It depends. A lightweight status update would be beneficial for alignment even if things are going well, since stakeholders deserve visibility
D. Yes. Consistent reporting is a professional discipline. Even high performing teams need to document their progress for accountability and audit purposes
34. A Team Discovers Halfway Through a Migration That the Original Plan Was Wrong
They adjust and complete the migration successfully but two weeks later than planned. How do you evaluate this?
A. Positively. Learning while doing is an inherent property of complex work. The team adapted to reality and delivered a successful outcome, which is exactly what good engineering looks like
B. As a planning failure. The incorrect assumptions should have been identified during the planning phase. A proper discovery exercise would have prevented the overrun
C. Neutrally. The outcome was acceptable but the team should produce a lessons learned document to prevent similar planning gaps in future projects
D. As a risk management issue. The two week overrun needs to be logged and the planning process needs to include more rigorous assumption validation before execution begins
35. You Ask a Technology Lead How a Project Is Going
They say they do not know yet because the team is still working through some unknowns. How do you respond?
A. Appreciate the honesty. Not knowing is a valid state early in complex work. Ask what they are doing to reduce the unknowns and when they expect to have a clearer picture
B. Ask them to prepare a risk register and preliminary timeline estimate within two days so you have something to report upward
C. Express concern. A technology lead should always be able to articulate the status of their work, even if uncertain, and should present options with probability weightings
D. Escalate the concern. If the lead cannot provide a clear status update, the project may lack adequate governance and oversight
36. What Is the Most Important Thing to Measure About a Technology Team’s Performance?
A. The business outcomes their work enables, including reliability, customer experience, and the ability to change safely
B. Velocity and throughput, measured by story points completed per sprint across all teams
C. Time to market for new features, measured from business request to production deployment
D. Budget adherence, measured by comparing actual technology spend against the approved annual plan
37. A Senior Architect Strongly Disagrees With Your Proposed Approach
They present an alternative in a team meeting. They are blunt and direct. How do you handle this?
A. Welcome it. Blunt disagreement backed by evidence is a sign of a healthy team. Evaluate the alternative on its merits and decide based on what produces the best outcome
B. Thank them for their perspective but ask them to raise concerns through the proper channels rather than challenging your direction in a group setting
C. Acknowledge their passion but remind the team that once a direction is set, the expectation is to commit and execute rather than relitigate decisions
D. Listen but note that architectural decisions need to factor in business timelines and stakeholder commitments, not just technical preferences
38. How Do You View the Role of Engineers in Decision Making?
A. Engineers are domain experts whose knowledge should be actively extracted, challenged, and synthesised into better decisions. The best outcomes come from iterative collaboration, not instruction
B. Engineers should provide technical input and recommendations, but the final decision authority rests with the business leader who owns the commercial outcome
C. Engineers should focus on execution excellence. They are most effective when given clear requirements and the autonomy to choose the implementation approach
D. Engineers should be consulted on technical feasibility, but strategic decisions about what to build and when should be driven by the product and business teams
39. Your Best Engineers Have Stopped Voicing Opinions in Meetings
What does this tell you?
A. Something is wrong. When strong engineers go quiet, it usually means they have concluded that their input does not matter, which means the organisation is about to lose them or already has in spirit
B. They may be focused on delivery. Not every engineer wants to participate in strategic discussions and some prefer to let their code speak for itself
C. It could indicate that the team has matured and aligned around a shared direction, which reduces the need for debate
D. It suggests the decision making process is working efficiently. Fewer objections means the planning and communication have improved
40. An Engineer Tells You the Proposed Deadline Is Unrealistic
The team will either miss it or ship something that breaks. What do you do?
A. Take the warning seriously. Engineers who raise alarms about deadlines are usually right and ignoring them is how organisations end up with production failures and burnt out teams
B. Acknowledge the concern and ask them to propose an alternative timeline with a clear breakdown of what can be delivered by when
C. Thank them for the flag but explain that the deadline was set based on commercial commitments and the team needs to find a way to make it work
D. Ask them to quantify the risk. If they can show specific technical evidence for why the deadline is unrealistic, you will escalate it. Otherwise the plan stands
Answer Key With Explanations
Each option is scored 🟢 🟡 or 🔴, and the explanation focuses on what that option optimises for over time.
1. A Major Platform Decision Was Approved Six Months Ago
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Prioritises the right outcome over protecting past decisions | Better products and fewer sunken costs |
| B | 🟡 | Honouring governance feels responsible | Delivery of the wrong thing, on time |
| C | 🟡 | Protecting board timelines is professionally safe | Informal concerns that go nowhere |
| D | 🔴 | Governance confidence is genuinely valuable | Entrenched wrong decisions and learned helplessness |
2. Your Team Proposes Removing an Integration Layer
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟡 | Respecting investment sounds fair | Sunk cost paralysis masquerading as empathy |
| B | 🟢 | Merits and customer outcomes as the deciding lens | Better systems and cleaner architecture |
| C | 🟡 | Socialisation reduces friction | Delay that allows the right call to be avoided indefinitely |
| D | 🔴 | Timeline acceleration is always a defensible frame | Technology decisions subordinated to scheduling |
3. You Inherit Seven Management Layers
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Cutting what adds no value is the only honest response | Faster decisions and cleaner accountability |
| B | 🔴 | Coordination feels like the problem | More layers solving the symptoms of layers |
| C | 🟡 | Dashboards feel safe and non disruptive | Visibility into a structure that still doesn’t work |
| D | 🔴 | Commercial accountability sounds modern | Revenue framing over delivery quality |
4. What Is the Primary Purpose of a Technology Strategy Document?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🔴 | Budget alignment is how things get funded | Strategy in service of approval rather than clarity |
| B | 🟢 | Clarity over what you will and will not build is rare and powerful | Fewer wasted investments and better decisions |
| C | 🟡 | Accountability sounds mature | Accountability for the wrong things if the strategy is wrong |
| D | 🟡 | Communicating vision is legitimate | Style over substance if the audience cannot push back |
5. What Does Blast Radius Mean?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct definition with systems thinking built in | Better architectural decisions and safer design |
| B | 🟡 | Data loss is a real concern | Conflates backup and resilience concepts |
| C | 🟡 | Customer impact is the right concern | Misses cascading failure as the core concept |
| D | 🔴 | Financial framing is relatable to business heads | Revenue lens applied to an engineering concept |
6. When Designing a Critical System, What Is Your Primary Architectural Concern?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟡 | Revenue targets are a real design constraint | Optimises for scale at the expense of resilience |
| B | 🟢 | Graceful failure is the most durable design principle | Systems that fail safely rather than catastrophically |
| C | 🟡 | Vendor SLAs feel like insurance | Outsources architectural thinking to contracts |
| D | 🟡 | Reference models reduce reinvention | Compliance over fitness |
7. What Does Designing Assuming Breach Mean?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Layered defence and containment is the correct instinct | Systems that limit damage when breaches happen |
| B | 🟡 | Insurance feels like risk management | Financial mitigation without technical defence |
| C | 🟡 | Penetration testing is a real practice | Annual exercises are not the same as assume breach design |
| D | 🟡 | Compliance feels like security | Compliance theatre that passes audits and fails breaches |
8. A Project Is Behind Schedule
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Quality over date is the harder but more durable choice | Systems that work and users that trust them |
| B | 🔴 | External commitments feel binding | More people working on a broken plan faster |
| C | 🟡 | Extension with full scope sounds balanced | May be right if revenue calculation is honest |
| D | 🟡 | Splitting delivery sounds pragmatic | Can create integration debt if the fast follow never arrives |
9. How Should Work Flow Through a Technology Team?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟡 | Agile ceremonies are familiar and teachable | Process compliance rather than actual agility |
| B | 🟢 | Continuous flow and minimal handoffs are what actually work | Fast learning and high quality delivery |
| C | 🔴 | Quarterly cycles sound like proper governance | Planning theatre that misses reality by a quarter |
| D | 🟡 | Product owner coordination feels organised | Backlogs that grow rather than systems that improve |
10. Features Are on Time but Incidents Are Increasing
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Delivery masking quality debt is the most common failure pattern | Early intervention before the system breaks loudly |
| B | 🟡 | Tooling gaps are real | Treats a symptom without asking what caused it |
| C | 🟡 | Infrastructure scaling is a genuine bottleneck | Deflects from delivery quality as the root cause |
| D | 🔴 | Process improvement sounds constructive | Reduces apparent incidents without reducing actual ones |
11. Vertical Versus Horizontal Scaling
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and precise | Ability to make informed infrastructure decisions |
| B | 🟡 | Storage and bandwidth are real dimensions | Fundamentally wrong definition |
| C | 🟡 | Database versus app server is a familiar split | Oversimplification that breaks in practice |
| D | 🔴 | Cost framing is relatable | Reduces a technical question to a finance question |
12. What Is Technical Debt?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct definition that connects to consequences | Ability to have honest conversations about investment |
| B | 🟡 | Licence and infrastructure costs feel like debt | Confuses financial obligations with technical constraints |
| C | 🟡 | Target state framing is familiar from transformation programmes | Reduces debt to a migration backlog |
| D | 🟡 | Legacy systems are a common mental model | Misses the fact that new systems accumulate debt too |
13. Why Does Observability in Production Matter?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and operationally grounded | Engineers who can diagnose and improve systems |
| B | 🟡 | Compliance evidence is a real requirement | Monitoring as audit artefact rather than operational tool |
| C | 🟡 | Business dashboards are a legitimate need | Confuses business reporting with system observability |
| D | 🔴 | SLA qualification sounds like a practical reason | Observability in service of vendor contracts, not operations |
14. The Primary Benefit of Public Cloud
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | On demand provisioning and elastic cost is the real value | Infrastructure that scales with reality |
| B | 🟡 | Cost reduction is often part of the pitch | False certainty that ignores workload specifics |
| C | 🔴 | Compliance automation sounds appealing | Dangerous misunderstanding of shared responsibility |
| D | 🔴 | Elimination of overhead sounds efficient | Cloud adoption without understanding what you still own |
15. The Shared Responsibility Model
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and precise | Security decisions made with accurate mental models |
| B | 🟡 | Commercial framing is relatable | Confuses security responsibility with cost sharing |
| C | 🟡 | Shared accountability sounds balanced | Removes the clarity that makes the model useful |
| D | 🔴 | Full provider responsibility sounds like the deal | Organisations that discover their responsibilities too late |
16. What Is an Availability Zone?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and operationally precise | Architecture that plans for and survives zone failures |
| B | 🟡 | Regions are a real cloud concept | Conflates region with zone |
| C | 🟡 | Network isolation is a related cloud concept | Confuses network boundaries with physical redundancy |
| D | 🔴 | Pricing tiers and uptime SLAs are familiar procurement concepts | Infrastructure decisions made on commercial rather than technical grounds |
17. What Is Infrastructure as Code?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct and captures the key properties | Reproducible, reviewable, version controlled infrastructure |
| B | 🟡 | Diagram generation is a related practice | Confuses documentation tooling with infrastructure management |
| C | 🟡 | Documentation in a shared wiki sounds collaborative | Infrastructure decisions recorded but not enforced |
| D | 🔴 | Budget coding sounds like responsible governance | A finance process confused for an engineering practice |
18. When Should Testing Happen?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Continuous automated testing is the correct answer | Fast feedback and high confidence with every change |
| B | 🟡 | Dedicated testing phases feel thorough | Late discovery of problems that compound quickly |
| C | 🔴 | Milestone sign off sounds like governance | Testing as a gate rather than a continuous signal |
| D | 🟡 | Pre release exploratory testing is real and valuable | Leaves too much surface area uncovered between releases |
19. A Team Has 95% Code Coverage
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Coverage without behaviour validation is a known trap | Honest assessment of quality rather than metric satisfaction |
| B | 🔴 | 95% sounds high and therefore safe | False confidence in a metric that can be gamed |
| C | 🟡 | Module level breakdown adds nuance | Still treats coverage as the primary quality signal |
| D | 🔴 | Benchmarking sounds rigorous | Comparing against benchmarks of a flawed metric |
20. What Is the Purpose of a Chaos Engineering Exercise?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Deliberate failure injection to test recovery is correct | Verified resilience rather than assumed resilience |
| B | 🟡 | Load testing is a related practice | Confuses performance testing with resilience testing |
| C | 🟡 | DR failover testing is real and important | Narrower than chaos engineering as a practice |
| D | 🔴 | Incident process stress testing sounds useful | Focuses on the organisation’s response rather than the system’s behaviour |
21. Data Warehouse Versus Data Lake
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Correct definition that captures the key architectural difference | Informed decisions about where data belongs |
| B | 🟡 | On premises versus cloud is a familiar axis | Conflates deployment model with data architecture |
| C | 🟡 | Team ownership is a real governance question | Reduces an architectural concept to an org chart question |
| D | 🔴 | Historical versus real time is a familiar framing | Fundamentally misunderstands both concepts |
22. Building a Churn Prediction Model
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Data quality and bias are the foundation of any model | Models that work and can be trusted |
| B | 🟡 | Revenue impact is a legitimate prioritisation question | Skips past the foundational data question |
| C | 🟡 | Vendor platforms are a real option | Deploy fast, discover limits later |
| D | 🔴 | Demonstrating value to the executive committee is real pressure | AI theatre that looks impressive and produces wrong answers |
23. The Biggest Risk of Unmonitored Production Models
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Data drift and silent degradation is the real risk | Monitoring practices that catch decay before it causes harm |
| B | 🟡 | Compute costs are a real operational concern | Misses the accuracy decay that is far more damaging |
| C | 🟡 | Governance review is a legitimate process | Compliance framing misses the operational risk |
| D | 🔴 | Executive confidence is a real concern | Optimises for perception rather than reliability |
24. A Biased AI Model Is Proposed for Customer Decisions
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Takes bias seriously as a first order concern | Ethical deployment and regulatory protection |
| B | 🟡 | Human review sounds like a safeguard | Scales bias while providing legal cover |
| C | 🟡 | Steering committee decision sounds like governance | Delegates an ethical decision to a commercial forum |
| D | 🔴 | First mover advantage is a real competitive argument | Discrimination at scale with a future iteration that may never arrive |
25. One AI Engineer Embedded in a Feature Team
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Recognises the structural failure clearly | Deliberate community of practice and proper quality gates |
| B | 🟡 | Clear deliverables and product ownership sound sufficient | Unreviewed AI work validated by people who cannot evaluate it |
| C | 🔴 | Embedded specialists sound efficient | AI capability that has no peers, no quality gate, and no future |
| D | 🟡 | Training and milestone measurement sound supportive | Isolates the engineer while providing the appearance of support |
26. What Is Data Governance in Practice?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Treats data as a product with full lifecycle accountability | Trustworthy data that can be used with confidence |
| B | 🟡 | Policy and committee governance is a real structure | Bureaucratic access management masquerading as governance |
| C | 🟡 | Classification and retention policies are real requirements | Compliance artefacts without operational governance |
| D | 🔴 | Technology controls feel like governance | Enforces access without understanding what the data is or means |
27. You Need to Hire a Senior Engineer
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Curiosity and simplification track record predict long term impact | Engineers who make systems better rather than just larger |
| B | 🟡 | Certifications feel like proof of knowledge | Credential matching rather than capability hiring |
| C | 🟡 | Communication with executives sounds valuable | Engineers selected for stakeholder management over technical depth |
| D | 🔴 | Delivery track record sounds like the right signal | Engineers selected by programme managers rather than engineers |
28. An Engineer Proves You Wrong
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Being right matters more than being in charge | Trust, psychological safety, and better decisions |
| B | 🟡 | Formal documentation sounds thorough | Bureaucratic delay that signals pushback is unwelcome |
| C | 🟡 | Strategic context is a real consideration | Strategic context used to override technical evidence |
| D | 🔴 | Commercial considerations are real | Teaches engineers their input is decorative |
29. The Biggest Risk of a Non Technical Leader
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Inability to distinguish risk from excuses is the core failure mode | Leaders who get fooled in both directions |
| B | 🟡 | Vendor over reliance is a real pattern | One manifestation of a deeper capability gap |
| C | 🟡 | Talent attrition is a real consequence | Symptom rather than root cause |
| D | 🟡 | Timeline focus over technical foundations is common | Another symptom of the same underlying problem |
30. A Vendor Promises to Solve a Critical Problem
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Exit costs and vendor direction changes are the durable concerns | Relationships that preserve architectural independence |
| B | 🟡 | Procurement process is a real requirement | Approved vendor lists substituting for technical evaluation |
| C | 🟡 | Case studies are useful social proof | NPS and reference customers replacing structural analysis |
| D | 🔴 | Timeline alignment is always relevant | Vendor selected based on board commitments rather than fit |
31. Clever Architecture Versus Simple Architecture
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Operability and maintainability outlast impressiveness | Systems that the next team can understand and fix at 02:00 |
| B | 🟡 | Performance metrics are a real consideration | Complexity justified by benchmarks that matter at demo time |
| C | 🟡 | TCO analysis is legitimate | Analysis paralysis replacing a clear architectural principle |
| D | 🟡 | Architect recommendation makes sense | Defers to expertise but avoids the underlying principle |
32. A 97 Slide Strategy Deck
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Length compensating for clarity is a real and common failure | Pressure for clear thinking over comprehensive coverage |
| B | 🔴 | Thoroughness sounds like due diligence | Rewarding volume over clarity |
| C | 🟡 | Executive summary sounds practical | May preserve the 97 slides rather than replacing them |
| D | 🟡 | Comprehensive review sounds responsible | 97 slides reviewed without asking whether they add up to a strategy |
33. A High Performing Team Has No Status Report
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Outcomes are the evidence. Reports are not the product | Freedom for high performing teams to focus on results |
| B | 🔴 | Governance visibility sounds like a legitimate requirement | Reporting as a proxy for leadership confidence |
| C | 🟡 | Lightweight alignment sounds reasonable | Process for its own sake introduced into a team that does not need it |
| D | 🔴 | Accountability and audit discipline sounds professional | Bureaucratic expectations imposed on a team that is already delivering |
34. A Team Adjusts and Delivers Two Weeks Late
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Adaptation during complex work is exactly correct behaviour | A culture that engages honestly with what they discover |
| B | 🔴 | Planning failure is a clean and familiar frame | Teams that fabricate certainty rather than discovering truth |
| C | 🟡 | Lessons learned sounds constructive | Document production as a substitute for genuine understanding |
| D | 🔴 | Risk management logging sounds rigorous | More assumption validation that produces more fabricated certainty |
35. A Lead Says They Do Not Know Yet
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Not knowing is valid. What matters is what reduces the unknowns | Honest engineering cultures that surface uncertainty early |
| B | 🟡 | Having something to report upward sounds responsible | Risk registers produced to satisfy upward reporting rather than to manage risk |
| C | 🟡 | Probability weightings sound rigorous | Manufactured precision on genuinely uncertain situations |
| D | 🔴 | Escalation sounds like accountability | Penalising honesty and teaching people to fake confidence |
36. What Is the Most Important Thing to Measure?
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Business outcomes, reliability, and safe change are what technology actually exists to produce | Measurement that connects engineering work to things that matter |
| B | 🟡 | Velocity is a familiar agile metric | Story point farming that looks productive and may not be |
| C | 🟡 | Time to market is a real business concern | Optimises for speed over quality and sustainability |
| D | 🔴 | Budget adherence sounds like financial discipline | Measuring spend rather than value |
37. A Senior Architect Disagrees Publicly and Bluntly
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Blunt disagreement backed by evidence is a sign of health | Better decisions and a culture where truth surfaces |
| B | 🟡 | Proper channels sound professional | Teaching people that public disagreement is insubordination |
| C | 🟡 | Commitment after a decision is a real norm | Commitment used to prevent legitimate reconsideration |
| D | 🔴 | Business timelines as the final frame sounds balanced | Technical expertise subordinated to schedule compliance |
38. The Role of Engineers in Decision Making
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Active extraction and synthesis of engineering knowledge is how the best decisions get made | Products built from collective intelligence rather than individual instruction |
| B | 🟡 | Business leaders owning commercial outcomes sounds right | Technical input as decoration on pre made decisions |
| C | 🟡 | Execution excellence and implementation autonomy sound respectful | Engineers who are good at what they are told but disconnected from why |
| D | 🔴 | Product and business teams driving strategy sounds efficient | Strategy uninformed by the technical reality that will determine whether it is achievable |
39. Your Best Engineers Have Gone Quiet
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Silence from strong engineers is almost always a warning | Early intervention before the best people leave in spirit or in practice |
| B | 🟡 | Focus and preference for code over meetings is real | Convenient reframe that avoids the harder question |
| C | 🟡 | Team maturity and alignment sound positive | Alignment that is actually submission |
| D | 🔴 | Fewer objections sounds like improved governance | A team that has learned not to disagree with leaders who do not want to hear it |
40. An Engineer Says the Deadline Is Unrealistic
| Option | Score | Why it is attractive | What it tends to create |
|---|---|---|---|
| A | 🟢 | Engineers who raise deadline alarms are usually right | Credible timelines and teams that are not burned out shipping things that break |
| B | 🟡 | Alternative timeline with breakdown sounds constructive | Amber because the warning should be taken seriously before asking for proof |
| C | 🔴 | Commercial commitments sound binding | Teams that silently absorb impossible constraints and deliver broken software |
| D | 🟡 | Quantified risk sounds rigorous | Can become a bar set high enough that legitimate warnings are never escalated |
Interpretation
Mostly 🟢 means you approach technology leadership with the right instincts. You understand that engineering knowledge is a strategic resource, that quality and sustainability outlast delivery theatre, and that your role is to create conditions in which strong engineers can do their best work.
Mostly 🟡 means your instincts are not dangerous but they are shallow. You rely on process, optics, and familiar governance structures because they feel responsible. Under pressure, those defaults will pull you toward comfort rather than clarity. Watch for which categories your 🟡 answers cluster in because that is where your blind spots live.
Mostly 🔴 means you optimise for timelines, reporting, and the appearance of control. You likely see opinionated engineers as a management problem rather than an intellectual resource. The technology organisations you lead will deliver on time to specifications that were wrong, retain compliant engineers who stopped caring, and struggle to understand why customers leave.
The most damaging technology leaders are not the ones who know nothing. They are the ones who know enough to sound credible while making decisions that slowly hollow out the organisations they run.
Inspired by Why Andrew Baker Is the World’s Worst CTO