Director, VP, head-of and CTO interviews: strategy, organisation design, AI adoption, build versus buy, budgets and business cases, and the case studies, take-homes, presentations and executive panels these loops use.
44 published across 8 topics.
Turning a business goal into a technical strategy with real choices, a sequence and measures, and defending it to executives.
Treat executive conflict as information, not an attack. In the room, restate their strongest point, answer what your data covers, name what you will come back with and when. Afterwards, meet them privately, find whether it is a dispute about facts or priorities, and return to the CEO jointly. Never score points.
A modernisation business case for a CFO turns technical debt into what finance already manages: run cost, risk exposure and speed of change. Price the status quo from stated assumptions, offer options with costs, fund in gated tranches with measures, and let finance decide how the spend is treated.
Ask what slowed and against what baseline, then bring engineering metrics about the system: where capacity goes, DORA-style delivery and stability measures, flow, and business outcomes. Refuse lines of code, commit counts, cross-team story points and individual rankings, and give every trend its context.
Set decision criteria tied to business outcomes before scoring anything: the measured cost of the status quo, what each rewrite changes for customers, reversibility, capacity and any incremental route. Fund one rewrite properly rather than three partially, and tell the other teams first, in person, with the reasoning.
Define what entering means, then split the goal into a few engineering bets, each with a hypothesis, a leading indicator and a cost. Sequence the cheapest learning first, release capacity through gates, and agree kill criteria in advance that fire on early signals, not month-twelve revenue.
A two-year technology strategy needs a diagnosis of the business problem, a guiding policy with explicit choices, a few costed actions with owners, a stop list and measures. It is a strategy, not a roadmap, if it can refuse a funded proposal and still means something with every date deleted.
Team topology, managers of managers, splitting and merging teams, scaling an organisation from tens to hundreds.
In hypergrowth, interviewing breaks first, then onboarding, managers, ownership and informal communication. Size the hiring pipeline from stated assumptions, start growing managers now because they take longest, split ownership before teams multiply, and gate hiring pace on how fast people are absorbed.
A manager of managers delivers through other managers, so look for evidence of developing and removing managers, designing systems such as planning and hiring, and judgement at organisation scope. Hiring leaders well takes a competency map, org-scope stories probed for depth, a realistic case and future colleagues.
Fix ownership before span of control. Map every service to one owning team, cut teams around what they can ship alone, then size management to fit, adding a layer only if your own span demands it. Price the new manager roles, move people in waves, and involve HR early, as obligations vary by country.
In layoffs, decide what work stops before which roles go, apply criteria agreed with HR and legal because the process varies by country, and never start from names. Tell people individually and with dignity, then cut the roadmap to match the smaller team so those who stay do not carry the same work.
Shared service ownership means nobody is accountable, so the blame is a symptom of structure. Give one team ownership with matching authority, make the other department a customer with an interface and an SLO, write incident management and escalation down, and have both department heads visibly back the change.
Create a platform team when several stream-aligned teams keep solving the same undifferentiated problem and it measurably slows them. Stop it becoming a bottleneck by running it as a product with real users, making self-service the standard, keeping adoption voluntary, and measuring the waiting it removes.
Rolling AI tools and AI features out across an organisation, measuring what changed, and keeping quality and risk in check.
Bring AI impact evidence in three labelled strengths: what moved against a baseline, what you observed but did not measure, and what you cannot attribute. Put spend and risk beside it. Refuse a productivity percentage, a headcount equivalent or survey hours times salary, and say when real evidence arrives.
Write the AI usage policy around data classification, not tool names. Map each class of code and data to where it may go, approve tools only after legal and security confirm retention, training use, region and IP terms, give exceptions an owner and an expiry, and enforce with controls that assume people will paste.
Treat junior engineers as your future senior bench, not as cheap throughput. Size early-career hiring from the senior pipeline you will need, redesign the work so juniors still build judgement alongside AI coding assistants, hire for reading, debugging and review, and promote on diagnosis, not output.
Treat AI coding assistants as a practice change, not a licence purchase. Settle data policy and contract terms first, capture a baseline, pilot with contrasting teams, train people to review generated code, then expand in waves. Measure flow and stability against teams not yet switched on, not seat usage.
Require AI governance in proportion to risk. Apply risk tiering to what the output does, who sees it and whether errors reverse. Every tier needs a named owner, a tested kill switch and fallback, data rules and monitoring; higher tiers add pre-agreed evals, adversarial testing, human review and legal sign-off.
Build versus buy with a total-cost view, replacing a vendor, platform bets, and exit plans.
Compare total cost of ownership like for like. Buying still needs a platform team, building never ends at launch, and a later launch delays benefit. On illustrative figures for 300 engineers over three years, buying costs 1,595k against 2,775k to build, and building wins at steady state only above about 900 engineers.
Spend two weeks on facts: contract dates, notice clauses, real usage and switching cost. Cut usage you do not need, build an alternative you could execute, and negotiate term, caps and tiers, not just the headline. If you cannot switch in ninety days, buy time with a short renewal and start the exit work.
Write the vendor exit strategy before signing, while you have leverage. Insist on tested data export that includes configuration and history, a paid transition period, price and end-of-life notice, and real termination rights. Then build seams you own, and let legal and procurement shape the terms.
Not as first proposed. Approve a short discovery and a renegotiation, then a phased migration only if the full cost of owning every integration, including an on-call rota, connector upkeep and dual running, beats the renegotiated fee, or a non-cost reason such as roadmap control justifies paying more.
Decide by naming the risk you are buying down. Multi-cloud bought for resilience usually doubles serving capacity and team skills to cover a failure that multi-region already handles. Exit leverage and regulation are better served by one primary cloud, deliberate seams and a tested exit plan, priced side by side.
Headcount and cloud budgets, cost cuts that keep reliability, modernisation business cases and technical due diligence.
Before a mid-year budget cut, establish the base: twenty percent of the annual budget can be forty percent of what remains. Then cut by portfolio, not across the board. Freeze unfilled roles, stop whole initiatives and the spend they carry, protect commitments and reliability, and explain each choice.
Agree whether thirty percent means run-rate or this year's cloud spend, absolute or per unit. Then attribute the bill, phase the cuts as quick wins, structural fixes and commitments last, and guard every change with SLO burn and a protected list. Show both the run-rate and the in-year figure.
Headcount planning starts from measured run cost per product line, not last year's shares. Fund that first, allocate the rest by each line's posture, stage bets behind gates, and plan in effective capacity, because hiring lag and attrition mean new roles add far less than their number in year one.
Technical due diligence tests the deal thesis, not code quality. Check whether the product can do what the buyer is paying for, who holds the knowledge, which security, licence and debt liabilities come with it, and what integration costs. Turn every finding into a price, condition, plan or walk-away.
Show platform ROI against a counterfactual cost: what product teams would spend doing the work themselves, measured from non-adopters. Add measured time saved, discounted because hours are capacity not cash, and consolidated licences. Report reliability separately and state the limits.
Leading through a major incident, reporting to a board, and building reliability as an organisational habit.
In a major outage, incident leadership means not running the incident. Confirm a capable commander, ask three questions, then run everything around the response: a business channel with comms, support, legal and security, a fixed update cadence, the trade-offs only you can make, and a shield for responders.
Board reporting on an outage answers four questions: what customers and the business lost, why the system allowed it, what is already fixed, and whether the same class of failure exists elsewhere. Leave out names, the minute-by-minute timeline and unverified numbers, and own the outcome yourself.
Stop making reliability compete item by item. Agree SLOs and an error budget policy with product leadership in advance, hold a measured capacity floor for operational work, price incidents in business terms, and require a named executive to sign any decision to overspend the budget.
In a data breach, engineering owns containment that preserves evidence, a timestamped fact base on what was exposed, and recovery. Bring in legal, privacy, security, communications and executives within hours, because notification duties vary by jurisdiction and are legal decisions.
30-60-90 day plans, vision presentations, executive and board panels, bar-raiser rounds and reference checks.
A strong 30-60-90 day plan for a VP of Engineering spends the first month diagnosing why dates slip, the second fixing how commitments are made and landing one re-baselined milestone, and the third installing a planning system. Each phase ends in outcomes the CEO can check, not a list of meetings.
A board panel judges whether you can be trusted with the company's money, risk and reputation, not whether you can engineer. At this stage of a CTO interview, expect questions on the business model, technology risk in commercial terms, bad news and the CEO relationship. Answer with consequences first.
In a director-level bar raiser, the stories that work turn on a decision that changed how several teams were funded, staffed or organised, and they hold up five levels of 'why' deep. Team-level leadership stories fail because repeated probing bottoms out in execution, with no choice in it that only you could have made.
Executive reference checks are conversations, not HR confirmations: a search consultant or executive calls the people you name, and often others. Choose references who can verify the claims you made in the loop, brief them without scripting, and raise difficult chapters first so a back-channel call confirms your account.
Treat the executive title as a label and audit the scope behind it: reporting line, budget authority, headcount, decision rights and a seat in the leadership forum, read against how that kind of company levels. Negotiate a written charter and reporting line first, then a dated title review, then pay inside the band.
Build a vision presentation that argues from their starting point to a specific two-year destination: the answer on one slide, a diagnosis with sources marked, three choices with their costs, what you will not do, a phased sequence and measures. Then prepare the questions as hard as the slides.
Worked answers to the written and live cases senior loops set: vision memos, org redesigns, migration cases and scaling plans.
Post-merger integration in engineering starts with people, because the engineers who understand the stack you retire are the ones you need most and are likeliest to leave. Decide leadership and retention first, converge shared layers early by published criteria, and move customers last, in measured waves.
A monolith migration business case compares options in one unit finance can convert, shows the payback with stated assumptions, and names the number that would change the answer. Worked here, modularising in place pays back in about eighteen months; extracting services is a staged option decided on measured evidence.
A programme retrospective at executive level is a structured argument, not a highlight reel. State the problem with a baseline, show adoption from usage data, give quantified impact with what else could explain it, report cost against plan, and spend real time on what you got wrong and would decide differently.
A working-backwards press release for an internal platform describes the launch from the engineer's side, in plain language, and the FAQ then answers the hard questions on cost, adoption, scope and risk. The FAQ is where assessors look, and a strong one admits where the numbers do not yet justify the build.
Scaling a global capability centre tenfold is an ownership transfer first and a hiring plan second. Agree which products move with full decision rights, build the management layer ahead of the teams, size recruiting and interviewer load from stated assumptions, and report owned services, not headcount.
A strong written org design starts from an ownership map, cuts teams around product domains a team can ship alone, fixes span of control without moving the overload up a layer, and staffs every new manager seat by name or by hire. Worked below: 96 engineers, 8 overloaded managers becoming 15, moved over 16 weeks.
A strong technical vision memo opens with the recommendation, states an end state a non-engineer can picture, and backs it with a short diagnosis, explicit choices including what you will not do, a gated sequence, measures with baselines and the decisions you need. A full worked memo for a fictional company follows.