Multiverse Interview Question Bank — With Full Answers

Senior Engineering Manager, Enterprise Trust & Reliability

Interview: 16 September — peer + hiring manager

Everything is here. Each answer is written in first person, in STAR shape, drawn from your Leapsome reviews (2022–2025) and your own prep notes. Read them for shape and detail, then say them in your own words — don’t memorise verbatim.

Where you see [CHECK] — a detail I couldn’t confirm from your documents. Fill it in before the call.

The four Operating Principles you’re being judged against: Solve for customer value · Be decisive, even in ambiguity · Drivers, not passengers · AI to deliver outcomes Plus the BAM framework: Behaviour · Achievement · Mastery

1. Opening & narrative

“Tell me about yourself.”

I’m a software engineer turned engineering leader — about two decades in, the last eight or so in management. I was born in India, grew up in the UAE, and have been in the UK since 2009.

My career has run through three heavily regulated domains: financial data at FactSet, cyber insurance at CFC, and energy at Kaluza. The thread through all of them is bridging deep platform infrastructure with customer-facing delivery — making the unglamorous foundations dependable enough that the product teams on top can move fast.

At Kaluza I’ve led up to two teams at a time, and for a period acted as Head of Reliability. The work I’m proudest of is consolidating our heterogeneous multi-cloud billing platform into a single, observable, auditable one. That saved around £2.4 million a year, but the outcome that actually mattered commercially was that we went from weeks of cross-team engineering effort to deploy a platform instance for a new client, down to a few hours.

What draws me to this role is that it’s a first-of-its-kind mandate. I’ve founded functions rather than inherited them — the Infrastructure Platform team, Quality Engineering, and later Platform Engineering at Kaluza were all things I stood up. That’s the kind of work I do best.

Keep this to 90 seconds. Stop talking after the last line — let them pick the thread.

“Why are you looking to leave Kaluza?”

Two honest reasons.

The first is scope versus level. I’ve been managing two teams, running org-wide migration programmes, and founding communities of practice, but the managerial career path at Kaluza never really materialised — at one point I raised it and it was shelved. I’m not bitter about it, but I’ve learned I want a role where the scope and the level are set clearly from the outset rather than something I have to argue into existence.

The second is that the most energising work I’ve done has always been building something new. Kaluza’s been through a lot of contraction — hiring freezes, teams shrinking, engineers I rated leaving because there was nowhere for them to go. I want to be somewhere that’s growing, where hiring well and building a team is actually part of the job.

This role has both: a defined senior mandate, and open seats to fill.

Don’t editorialise beyond this. Avoid anything that sounds like blaming individuals.

“Why Multiverse? Why this role specifically?”

Two things, one about the company and one about the role.

On the company: the mission is upskilling people for the AI era, and it’s a company that has to be its own proof case. That’s an unusual alignment — the pressure to actually be AI-native internally isn’t marketing, it’s existential to the pitch. I find that genuinely interesting to work inside.

On the role: Enterprise Trust & Reliability is exactly the seam I’ve spent my career on. CTI is integration and API design under enterprise security scrutiny; S&O is incident practice, SLOs, observability, on-call health. I’ve run both sides — just never with them explicitly joined up as one function, which I think is the smart part of how you’ve organised it. Enterprise buyers do make or break deals on precisely those two questions: can you integrate with us cleanly, and will you stay up.

And it’s the first dedicated EM seat for it. I’d rather define the playbook than inherit someone else’s.

“Why management rather than staying hands-on?”

I’ve actually tested this. At one point I stepped back into an individual contributor role — partly because the management progression path where I was had stalled, and partly out of genuine curiosity about whether I’d miss the code.

What I learned was that I get far more satisfaction from large-scale outcomes than from shipping a feature myself. And the thing I find most rewarding is watching engineers I’ve coached get promoted or find the role that suits them — I’ve had several people move on to places they could thrive, sometimes out of my own team, and I count those as wins.

So I came back to management deliberately rather than drifting into it. I’m technical enough to steer a design review, challenge an estimate, and make a build-versus-buy call — but I don’t want to be the one writing the code, and I don’t see management as a stepping stone to something else. It is the job.

This directly answers the JD’s “Not for you if” section — worth landing clearly.

2. Be decisive, even in ambiguity

“Tell me about a time you had to execute a decision you strongly disagreed with.”

At Kaluza we had two versions of the billing platform live — a legacy one for our original client and a newer one for a second client — while simultaneously building a third, globalised version designed around a global core with regional localisations. The future version deliberately wasn’t backwards-compatible; whole domains were being rewritten.

Late in the process a request landed to keep the newer version’s features continuously testable for system integration testing. This meant significant extra work across multiple teams and directly disrupted delivery commitments on the version that actually mattered long-term. The driver was largely political — protecting us from a client’s contractors being able to characterise us as sloppy.

Several of us engineering managers put the case against it in writing: the cost, the delivery impact, the opportunity cost. We lost that argument.

What I did next is the part I’d want you to judge me on. I didn’t relay it to my team as “leadership is making us do this.” I explained the commercial reasoning honestly, including the political dimension, because engineers can smell it when you’re managing them with a half-story. We executed it properly.

I still think we were right on the merits. But a decision made and half-executed is worse than either option, and my job once the call was made was to make it work.

“Tell me about a significant call you made without waiting to be told.”

In 2024 I noticed something about our Kafka platform team that nobody had said out loud: Kaluza was structurally moving away from Kafka. A separate strategic initiative was changing how services communicated, and I went and spoke to the people leading it directly to understand the trajectory. What became clear was that within a year or so, the Kafka platform team wouldn’t need to be a team — it would need to be a liaison relationship with our vendor.

Meanwhile, we were still investing engineering capacity there.

So I wrote a proposal to merge the Kafka Platform team into the Infrastructure Platform team and form a single Platform Engineering function. It was an uncomfortable proposal to write for a few reasons. It meant going from two teams to one, which some people would read as a demotion for me. It risked the Kafka engineers feeling their work was being declared unimportant. And nobody had asked for it.

I wrote it anyway, and it was well received. It let us concentrate limited engineering capacity on the work that actually mattered and reduced work-in-progress across the board.

The thing I’d flag is that I made the call on the strength of conversations I went and sought out, not on a directive. If I’d waited for the org to notice, we’d have burned another six months of capacity.

This is your single best “decisive in ambiguity” story — it cost you something personally, which makes it credible.

“Tell me about a time you chose speed over getting it perfect.”

One of my teams was productionising our managed infrastructure platform, and the epic had been running for months with no end in sight. They were working in Kanban, and when I dug into it I realised the work was essentially done — the engineers had shifted into polishing mode and kept folding improvements back into the same epic. It was perfectionism, not incompleteness.

I ran a workshop to switch the team to Scrum temporarily. Not because Scrum is better — because sprint goals and a fixed boundary forced the scope conversation the team was avoiding. I challenged the acceptance criteria directly: what would make this shippable, versus what is nice to have.

We shipped the MVP by the end of that December. Once it was live and operational work started getting heavier, we moved back to Kanban, which suited the support-driven reality better.

The lesson I took is that “we’re not done yet” often means “nobody has defined done.” That’s a management problem, not an engineering one.

“How do you balance delivery pressure against technical health?”

I’ll give you a period where I got this badly wrong and what I changed.

Through 2024 my teams were under real pressure — a large migration programme, hiring frozen, and a general sense that everything was urgent. My instinct was to absorb the pressure and let the team keep working. That was a mistake, and I’ll come back to it if you want the failure story.

What I do now is more explicit. I radically prioritise and I say out loud what we are not doing. In practice that meant, during that period, focusing the team only on the highest-value migration work and consciously declining the noise — even work that had a legitimate case for it.

On technical health specifically, I’ve found the most effective lever isn’t arguing for “tech debt time” in the abstract. It’s making the cost visible. We put real effort into cost and resource visualisation — cloud cost transparency, log volume reduction, Kafka resource cleanup and retention policies, which alone saved us roughly £129,000 a year. Once the numbers are on a dashboard, the prioritisation conversation stops being a matter of opinion.

3. Solve for customer value

“Tell me about translating technical work into business value.”

The biggest one was consolidating Kaluza’s billing platform. We had a heterogeneous, multi-cloud microservice ecosystem that had grown organically — expensive, hard to observe, hard to audit, and painful to stand up for a new client.

I led the execution of consolidating that into a central managed platform. The headline number is around £2.4 million a year in operating expenditure saved.

But the number I actually care about is different. Before, standing up an environment for a new retailer took weeks of engineering effort pulled from teams across the business. After, we could deploy an instance of the platform in any region, for any client, in a few hours. For a company trying to win its second and third enterprise client while proving the product, that’s not a cost saving — it’s the difference between being able to say yes to a deal and not.

That’s the framing I’d bring here. Reliability and integration work reads as internal engineering hygiene right up until you realise it’s what determines whether a procurement process ends in a signature.

“How do you make sure your team understands who actually uses their work?”

I learned this one the hard way, quite recently.

When I moved into the Energy Commerce domain, I asked what I thought was a basic question — how does the Billing platform actually consume what we build? And the team didn’t really know. Nobody had asked. That bothered me, because without it we were setting service level objectives based on what felt reasonable to us rather than what our consumers actually needed.

So I did two things. I used my own network of engineers over in Billing to establish a real picture of their demands, and worked with our Staff Engineer to turn that into a baseline for our SLOs. Then I went wider, pulling in people working closer to our international clients to understand consumption patterns there too.

The broader change I’m driving from it is shifting non-functional requirements left — making sure the team has the consumer context at the start of a piece of work rather than discovering it in an incident.

It was late to be learning this. But it’s never too late to find out how your customers actually use what you build.

Strong answer because it opens with a genuine admission. Don’t soften it.

“Tell me about a time a stakeholder asked for one thing but needed something else.”

At CFC we had a quoting API that was slow, and Connect — a client-facing platform — was about to go live. The CTO was pushing engineers hard to make the API faster.

The honest engineering assessment was that meaningful performance work was a multi-month project. We weren’t going to fix it before launch.

So I suggested something that got laughed at initially: rather than chase the raw number, make the loading experience better — show the user what was actually happening behind the scenes while they waited. Reframe it from a latency problem to a perceived-wait problem.

Once it sank in that the real fix was long-term, we implemented the better loading experience for launch and did the performance work properly on a sensible timeline.

What I’d take from it is that stakeholders are excellent editors and poor specifiers. They’ll tell you accurately that something feels wrong. They’re usually not right about the fix, and it’s our job to separate the symptom from the request.

“How do you think about compliance and reliability as customer value rather than overhead?”

I’d argue they’re the same thing in an enterprise sale, and I’ve been on the delivering end of that.

Concretely: I facilitated Kaluza’s first table-top disaster recovery exercise for the core billing pipeline and then set up a playbook to run it annually, because ISO 27001 required it. We passed the AWS Well-Architected Review. I led backup and recovery compliance during a resilience week, working across several teams so the organisation could coordinate it automatically going forward.

None of that is glamorous. But every one of those artefacts is something a prospective enterprise client’s security team will ask to see. The DR playbook isn’t a compliance tax — it’s an asset in a procurement conversation.

That’s part of what attracted me to how ETR is framed. You’ve explicitly connected the evidence base to revenue rather than treating it as a support function, and that matches how I’ve come to think about it.

4. Drivers, not passengers

“Tell me about something you drove that nobody asked you to.”

The clearest example is the migration programme at Kaluza.

We needed to migrate a large estate of services onto our central managed platform, working with an offshore partner. There was no programme manager and no delivery manager assigned. I wasn’t either of those things — I was an engineering manager with two teams.

What I did: prepared the training programme for the partner’s engineers and chose who’d travel to India to deliver it; planned and sequenced the migrations with my product manager through five phases; ran kick-off meetings with teams across Kaluza to set expectations and make sure people understood why the migration mattered rather than just that it was happening; ran retrospectives to keep feedback flowing; and followed up relentlessly.

We migrated a significant set of services — billing, energy contracts, smart metering, cost projections, and others.

The tell for how much I owned it is that other engineering managers at Kaluza started coming to me assuming I owned all migrations. That wasn’t formally true. It was just that I’d filled the gap and nobody had needed to fill it since.

“Give me a pattern, not just one example, of taking initiative.”

I think my honest pattern is that I notice a gap and start filling it before deciding whether it’s my job.

A few: I founded the Infrastructure Platform and Quality Engineering teams. Later I proposed and formed the Platform Engineering team. When the person running our internal tech-share forum left, I picked it up, then built a working group with a hosting rota so it didn’t depend on me. I founded a community of practice for engineering managers because we were all solving the same problems alone. I started a podcast-style interview series with senior engineering leaders to share what they’d learned.

I’ll give you the flip side too, because it’s relevant. My manager once wrote that I “take ownership of everything that comes my way” — and in my own review that same year I wrote that I tend to volunteer for things without checking what’s already on my plate. Those are the same trait. I’ve had to get more deliberate: I keep a physical task board of what’s genuinely in progress, precisely because my instinct to say yes isn’t self-regulating.

The self-aware ending is what makes this land rather than sounding like a brag list.

“Tell me about taking on responsibility outside your formal remit.”

At CFC we had a project for the Finance department — tracking outstanding loss funds from carriers, which at the time was being managed in spreadsheets with genuinely complex manual reconciliation.

When we got to tasking, every engineer picked something in the API. Nobody would touch the UI — they were all backend developers and none of them were comfortable starting it. I escalated to my boss and we agreed we weren’t getting a frontend person any time soon.

So I took a stab at it myself. I laid out the component interaction design and built a basic prototype over about four days. It wasn’t great code, but it was enough to de-risk the unknown — once there was something to react to, other engineers were willing to join in, and Finance approved the direction.

I want to be clear that I don’t think building it myself was the ideal outcome. The right read is that the blocker was fear of an unfamiliar starting point, and my job was to remove that blocker by whatever means were available. In a bigger team I’d have solved it differently.

The wider project ended up improving the efficiency of financial reconciliation by around seven times.

5. AI to deliver outcomes

This is the principle your CV under-evidences. Volunteer at least one of these rather than waiting to be asked.

“How do you use AI tooling day to day?”

Three ways, in roughly increasing order of how much I think they matter.

First, on my own code. I had a side project — a tool that calculates out-of-hours on-call compensation from our paging system, which I’ll come back to. In 2025 I used VS Code with Copilot and Claude Sonnet 4.5 to extend it from a rough script into a properly published npm package, plus a companion health-check tool.

Second, for learning. When I moved into the Tariffs and Pricing and Energy Commerce domains, I had to build a mental model of an unfamiliar business domain fast. I used NotebookLM, and Copilot connected to our Confluence and Jira through the Atlassian MCP connector, to accelerate that — alongside conversations with our Staff Engineers, which did the heavier lifting.

Third, in how the team works. Small things — I’ve used Gemini to generate retro themes so retrospectives feel less like a chore, and I’ve been building example contribution guidelines and structured documentation showing how AI can keep documentation current as contractor teams rotate in and out.

I also signed up as an AI catalyst on our developer experience platform, specifically to go after developer bottlenecks — pull request contention, CI pipeline inefficiency.

“Tell me about a time you evaluated whether an AI tool was actually worth adopting.”

This is the one I’d point to, because I think the useful skill isn’t enthusiasm, it’s judgement about cost and value.

Kaluza was running an AI catalyst programme and there was a question about which tooling to standardise on. I’d been using Copilot integrated with Claude’s latest model on real work — building out that npm package end to end — so I had actual usage to reason from rather than a vendor demo.

My conclusion, which I took to the person leading the catalyst programme, was that Copilot with Claude’s model gave us very close to the value of a premium agentic coding tool, at a fraction of the cost. The marginal additional value didn’t justify the spend at our scale, at that time.

I want to be careful here — I’m not making a general claim about those tools, and that calculation would look different with a different team size, different budget, and given how fast this is moving, possibly different today. The point is that I made a specific recommendation, based on my own hands-on usage, that pointed away from the more expensive option.

I can tell AI-assisted speed from AI-shaped slop because I’ve generated both.

“How would you drive AI adoption across CTI and S&O — two quite different teams?”

I’d resist mandating it, because mandated tool adoption produces theatre.

What’s worked for me is finding the specific friction each team already complains about and showing that AI removes it. That’s why I went after pull request contention and CI pipeline inefficiency as an AI catalyst — not because they’re exciting, but because they’re the things engineers actually grumble about in retros.

The two teams here would need different entry points. For integrations work, the obvious candidates are test generation, contract and schema work, and keeping API documentation current — documentation rot is a real liability when your integrations are being audited in a security review. For reliability, it’s incident summarisation, runbook generation, and pulling signal out of observability data during an incident.

And I’d model it rather than just ask for it. My next step at Kaluza was going to be short video showcases of exploratory AI work to make it concrete for engineers who hadn’t tried it. Engineers adopt what they see working, not what they’re told to use.

I’d also want to be honest with you that my experience here is at the personal and team level, not org-wide transformation. That’s a step up in scope for me and I’d want to be deliberate about it.

That last line is a genuine strength, not a weakness — it demonstrates the calibration they say they want.

6. People management & coaching

“Tell me about developing someone who was struggling.”

I’ve got two, and they have the same root cause.

The first: a new hire, mid-probation, was stalling — tasks taking much longer than they should. Rather than treat it as a performance problem, I had a direct feedback conversation to find out what was actually going on. It turned out he wanted to work in Scala, and there was very little Scala in our team. So I was straight with him: here’s what this role actually is, here are the goals I need you to hit in your first three months — and I promised that if he did, I’d help him find a Scala role. He hit them. By his fifth month an opportunity opened and he moved into it. He’s thriving.

The second was nearly identical in shape — an engineer making slow progress on priorities but visibly energised by things that weren’t priorities. A candid conversation surfaced that his real interest was security engineering. I went to the security team, found a gap he could grow into, and encouraged him to try a secondment before committing rather than making an irreversible jump. He’s been an asset to the company since.

Both times I lost a good engineer from my team. Both times it was the right call. Underperformance is very often a motivation mismatch wearing a performance costume, and the fastest diagnostic is just asking.

“Tell me about delivering feedback someone didn’t want to hear.”

I had an engineer who was technically strong and wanted to progress to tech lead, but whose way of engaging with the team carried a real cost — enough that it was showing up in stand-ups and reviews and creating a tax on everyone around him.

This wasn’t a case for a performance improvement plan. It was a case for coaching, and it took sustained effort over a long period — I leaned heavily on coaching books and on radical candour techniques to have conversations that were direct without being punitive. I gave him the feedback he needed to hear and didn’t want to hear, repeatedly, and then made sure he got actual opportunities to practise the people skills we’d discussed.

He gave me feedback in return that I kept trying the same approach with him and should try something new. That was fair, and I took it.

It didn’t resolve quickly or cleanly. He improved — my manager noticed the difference independently when he stepped up on a critical piece of migration work. But I’d be overselling it if I said I fixed it. Some of it was the pandemic and remote work genuinely damaging how people like him built relationships.

“How do you approach succession planning?”

The real test of this for me was parental leave — twice.

Before the first period, I deliberately divided my responsibilities between two senior people rather than leaving a vacuum, and that gave me a much clearer view of how broad the engineering manager role actually is when you have to itemise it for someone else. Before the second, I planned it further ahead: aligning two colleagues to share the migration follow-up work — onboarding, hiring, challenging estimates, unblocking the partner teams.

I also created a tech lead role specifically for the migration programme and gave it to an engineer who I thought was ready for more than he was being given. He exceeded what I expected of him, and his promotion came through the following year.

Here’s the honest part though. The first time I did this, I got it wrong in an important way — I covered the delivery responsibilities but not the protective ones. Nobody was holding the line against work flowing into the team while I was out. I’ll go into that if you want the failure question, but it’s the reason I now think about succession as covering two distinct jobs, not one.

“How do you handle a high performer who’s toxic to the team?”

I’ll be straight with you: I haven’t had a textbook “brilliant jerk” — someone whose output was so high that it genuinely tempted me to tolerate the damage. So I don’t want to invent one.

What I have had is the adjacent situation — engineers whose technical contribution was strong and whose effect on the team was a net drag. My approach has been coaching first, sustained and direct, with real opportunities to practise; and where that hasn’t worked, a team move. I’ve done that once, with a graduate and a senior engineer whose conflict I couldn’t resolve between them — I went to senior management and we moved one of them.

My actual position on the underlying question is that the maths isn’t close. One person’s elevated output almost never exceeds the aggregate drag they create across a team of six or seven, and the engineers watching you tolerate it learn exactly what your standards really are. I’ve written before that I’d rather have a hole in the team than the wrong person in it, and I’ve hired on that basis.

What I’d add is that I’d want to move faster than I historically have. My instinct is to keep coaching past the point of useful return.

“Tell me about advocating for someone’s promotion.”

I had a site reliability engineer who the squad badly needed at tech lead level, and who deserved it. The promotion process at Kaluza was genuinely opaque and difficult — it required building an evidence case that the system itself didn’t help you gather.

I did the work and got it through. What stuck with me was the feedback from two of my other reports about it. One of them said, unprompted, that getting him promoted was my biggest achievement that period, and specifically noted that the path is “opaque, difficult and takes a lot of effort.” Another said it gave him confidence that I had my engineers’ interests at heart “even if it means a loss for his team” — because the promotion took that engineer onward.

The reason I mention their reaction rather than just the outcome is that promotions are watched. What the rest of the team learns from one person’s promotion — about whether effort is rewarded and whether their manager will fight for them — is worth more than the individual result.

I’ve also had the reverse, where a promotion freeze meant an engineer expected an increase that didn’t materialise, and it read to him as me not backing him when actually the decision was above me. I handled the communication badly and he told me so in a review. That’s on me.

7. Conflict

“Tell me about resolving conflict between two team members.”

Two engineers in my team had friction that was showing up publicly — in stand-ups and in code and design reviews. What made it urgent for me wasn’t their discomfort; it was that we had a graduate in the team learning what “normal” looked like from watching them.

I had a good relationship with both, so I took it to one-to-ones separately rather than forcing a joint conversation. With each, I got their account, then asked what-if questions from the other person’s perspective and left them space to sit with it rather than pushing them to a conclusion in the room.

The framing I used with both was that disagreement isn’t the problem — we want technical disagreement — but that how they were doing it was teaching the graduate something I didn’t want taught. Making it about the junior engineer rather than about them personally gave them both a way to change without losing face.

It settled. Not into friendship, but into something professional and productive.

“Tell me about a conflict you couldn’t resolve.”

A graduate and a senior engineer on my team. The graduate was, frankly, overconfident — very invested in best practices and applying design principles heavily and early. The senior engineer was pragmatic and kept finding himself on the receiving end of criticism from someone with a fraction of his experience.

I worked with each individually to understand where it was coming from. It didn’t land. They couldn’t sort it out between themselves and I couldn’t get them there either.

So I went to senior management and asked for a team move. That’s what happened.

I don’t regard it as a failure, though I’d have preferred to resolve it. Some pairings just don’t work, and continuing to burn management time and team goodwill on a conflict that isn’t converging is a worse outcome than moving someone. What I would do differently is get there faster. I spent longer hoping it would improve than the evidence justified.

8. Failure & self-awareness

Expect this. The BAM framework has a coachability dimension and they will push. Lead with the first one — it’s strong precisely because it cost you something.

“Tell me about a time you failed as a manager.”

2024. This is the one I’d give you.

I was away for around four to five months across two periods of parental leave. Before going, I divided my responsibilities between two colleagues — but I covered the delivery responsibilities and not the protective ones. There was nobody whose job it was to keep the team aligned, hold morale, and push back on work flowing in.

Meanwhile there was enormous pressure to accelerate the migration programme. The team absorbed a heavy support load and constant reprioritisation with nobody shielding them.

I lost two engineers. People do leave tech companies after short tenures, but I don’t think these two would have if I’d championed the vision better and protected them. One of them told me on the way out that I can be demanding. That was hard to hear and it was accurate.

The compounding failure was that my absence meant I couldn’t properly assess the people who were struggling. I was relying on feedback from a team that was burnt out, which isn’t reliable feedback.

What changed: I now escalate much earlier and much louder. My instinct had been to absorb pressure and protect upward — to not be the manager complaining about capacity. What I should have been doing was going to senior leadership and the C-suite and saying plainly that this team is amber, and here is what happens if we don’t hire. I gave up too easily on a “no” about hiring. I don’t do that now.

Do not soften this. The specificity — two engineers, the direct quote — is what makes it credible.

“What’s a piece of feedback that genuinely stung?”

The one that comes up most consistently is about authority. Across more than one review cycle, my managers have told me a version of the same thing: that I usually know what the right thing to do is, but I don’t convey it with enough authority. One suggested I record meetings I run and watch them back.

It stung because I’d thought of my style — consultative, asking questions, leaders speak last — as a strength. And it is, mostly. But I’d been letting it slide into not stating a view clearly when a view was what the room needed.

A related one from a peer that I found harder: he’d observed me coaching someone publicly — I’d commented on how their confidence seemed to drop with each sentence — and he told me it probably caused embarrassment and achieved the opposite of what I intended. He was right. Coaching in public is a different act from coaching in private, however well-meant.

What I did with it: I’m much more deliberate about separating “I’m asking the team” from “I’ve decided,” and I keep developmental feedback in one-to-ones. I wouldn’t claim it’s fully solved. It’s the thing I’m actively working on.

“Tell me about a hiring mistake.”

I’ll answer this honestly rather than forcing a fit: I don’t have a story about hiring someone who was clearly wrong within sixty days.

The related mistake I did make, at some scale, was about capacity rather than individuals. We brought in an offshore partner for a large migration programme, and when delivery was slower than expected, the prevailing view across the organisation was that it was a skills problem with the partner’s engineers.

I wasn’t convinced. So I ran a deliberate test: we hired two local contractors and split the migration effort between them and the partner, as a like-for-like comparison. The result showed it clearly wasn’t the partner. The bottleneck was the lack of capacity and involvement from our own retail engineering teams — the migration needed their domain context and they didn’t have the headroom to give it.

My mistake was accepting the framing for as long as I did before testing it. I’d spent months managing a partner-performance problem that wasn’t a partner-performance problem.

The general lesson I took: when everyone agrees on the cause of a delivery problem and nobody has measured it, that’s the thing to go and measure.

Ending on a testable-hypothesis approach turns a gap into a strength.

9. Influence, scale & technical judgement

“Tell me about driving change across teams where you had no authority.”

The clearest one is trunk-based development and feature toggles at CFC.

I’d seen this work at FactSet after we’d tried several other approaches. At CFC, engineers were regularly in merge hell — partly because a lot of them were unfamiliar with Git fundamentals. So I started at the bottom: I designed and ran hands-on Git workshops, getting people creating repos, pushing, deliberately generating conflicts and resolving them. That reduced the confusion, and it also gave me the credibility to make the bigger argument.

Then I pushed for trunk-based development with feature toggles to decouple deployment from release. I gave several internal talks on it. It took a long time — far longer than I expected — because it asks people to change a workflow they’re comfortable with in exchange for benefits they can’t yet feel.

It eventually became standard practice. The thing that actually moved it wasn’t the talks; it was that once feature toggles were in, testing got easier because you could compare old and new behaviour by flipping a flag, and merging to main stopped requiring coordination. People adopted it when it made their day better, not when I explained why it was correct.

“You’re not hands-on in this role, but you need to be technical. How do you evaluate a technical proposal?”

By interrogating the reasoning rather than the conclusion.

Concretely, I ask my tech leads for a proposal document or a decision log — what options were considered, what the trade-offs were, what methodology got you to this choice. Then I spend my time with them on the why rather than the what. That does two things: it gives me enough of a model to ask better questions next time, and it forces the team to articulate reasoning they might otherwise have left implicit.

I’ve deliberately learned enough of the underlying technology — Kubernetes and the surrounding ecosystem, in my case — to scope and descope work credibly and to know when an estimate smells wrong. Not enough to write the code, and I don’t try. Where I’ve had highly capable tech leads, delving deeper into the implementation would have been a poor use of my time and, frankly, unwelcome.

A worked example: our Kafka team was firmly committed to one vendor and I pushed them, over several conversations, to seriously evaluate an alternative — I probably tested their patience. The conclusion we reached together was that the alternative was genuinely better, but that migrating would cost at least another year across the platform team and every team using it, at a moment when we were trying to win clients. So we didn’t. That’s the right kind of outcome: a decision made with the trade-off surfaced rather than assumed.

“How do you balance being in the detail versus thinking strategically?”

Badly, historically — and I’d rather tell you that than claim I’ve cracked it.

I wrote in one of my own reviews that the majority of my day went to execution and my actual thinking time was after hours. That’s not sustainable and it’s not what I’m paid for at this level.

What’s genuinely improved it: I keep a physical task board of what’s actually in progress, because my problem isn’t prioritisation in the abstract, it’s that I say yes too readily and lose track of the total. And I’ve got much better at delegating things I’d previously have held — when an engineer proposes a solution to a ways-of-working problem, they get to lead implementing it, which is better for them and takes it off me.

I’ve also learned to use the quieter periods deliberately. When I’m not firefighting, that’s when I do the domain learning and the thinking, rather than filling the space with more execution.

I’d describe it as improved rather than solved. Managing two teams with different technical domains — which is what this role is — is exactly the situation where holding context across both is the hardest part of the job.

10. Role-specific: CTI + S&O

“What would your first 90 days look like?”

I’d want to validate all of this once I’m inside, but here’s my starting hypothesis.

Weeks 1–4, mostly listening, with two specific artefacts I’d want early. For S&O: the current incident load, the severity model, how the on-call rota actually feels to the people on it, and whether our SLOs reflect what consumers need or what we find convenient to measure. For CTI: a map of who owns which integration and where the undocumented knowledge sits — because that’s usually where enterprise trust breaks first, and it’s the thing that a security review exposes.

Weeks 4–8, the people. One-to-ones with all seven engineers, understanding where each wants to go, and working out with the tech leads where the real technical direction disagreements are. I’d also want to get the hiring loop moving, because open seats left open get harder to fill, not easier.

Weeks 8–12, start setting the standard. Delivery rhythm, how design review works across two quite different domains, and an honest baseline on the AI-native operating rhythm — what are engineers actually using, versus what we say we use.

The thing I’d resist is arriving with a playbook. I’ve inherited enough situations to know the first version of my plan is usually wrong in at least one important way.

“How would you split your attention across two teams with different domains?”

I’ve done exactly this for several years, so I’ll tell you what I learned rather than what I’d hope.

The failure mode is trying to hold equal technical depth in both. I can’t, and trying to produces a manager who is shallowly annoying in two domains rather than useful in either. In my case I had a genuinely deeper understanding of one team’s domain than the other, and I was upfront about that.

What works is leaning hard on the tech leads for depth, and concentrating my own attention on the things that are actually mine: the interfaces between the teams, the prioritisation calls, the people, and the standard. An engineer on one of my teams once gave me the feedback that my questions sometimes lacked context because I was stretched — and his suggestion was to route more through the tech leads as support. That was good advice and I took it.

The other thing I’d flag: the context-switching cost is real and it lands on the team as much as on me. So I try to protect block time per team rather than interleaving constantly.

“How do you make on-call sustainable?”

This is something I’ve actually moved the needle on, and the mechanism was confidence rather than compensation.

I had engineers who weren’t signed up for out-of-hours on-call, which meant the rota rested on too few people. The instinct is to treat that as a willingness problem. It isn’t — it’s a fear problem. People don’t want to be woken at 3am to face something they don’t know how to handle.

So I built a workshop format to walk teams through setting themselves up for out-of-hours success. I deliberately had our Reliability Operations Manager review it and run it rather than me, because there’s a psychological safety issue in the line manager running the session where people are meant to admit what they’re afraid of. We ran it in two parts: preparation, then prioritising incident scenarios for game days.

Every engineer in that team signed up for the out-of-hours rota afterwards. All six.

I then pushed for game days — theoretical disaster scenarios worked through on paper, with the intent of automating toward chaos engineering over time — as a repeatable framework, and ran the first table-top DR exercise for our core billing pipeline with an annual playbook for ISO 27001.

I’d also say: I’ve been on the rota myself, including filling in on a team I wasn’t close to day-to-day. I don’t think you can own on-call health credibly from outside it.

“How would you approach hiring for these open seats?”

Slowly enough to get it right, and with a clear bar.

My position is that I’d rather have a hole in the team than the wrong person in it. I’ve written that in my own objectives. Hiring under pressure with a compromised bar creates a problem that takes years to fix and damages everyone already there.

Practically, I’ve done a lot of screening — including interviewing partner and contractor engineers, writing job descriptions, and choosing who should be on the interview panel, which I think matters more than people credit. I’m also conscious of bias in hiring: I pushed our People team to run inclusive-interviewer training when it had stalled, and got around nine people through the first session. I’d want to interview through a structured, consistent process rather than vibes.

On your specific process — I understand you use a high-agency question bank and a live AI build stage. I’d want to understand the signal you’re trying to get from the build stage specifically, because designing a live exercise that distinguishes genuine AI-assisted capability from someone who can prompt fluently but can’t evaluate the output is a hard design problem, and it’s one I’d find interesting to work on.

11. Questions to ask them

Pick three or four. Have them written down.

For the hiring manager:

• What does success look like at six months for the first person in this seat — is there something specific that’s currently broken or slow that I’d be expected to have fixed?
• How will “solve for customer value” be measured for ETR concretely? Is there already a procurement or reliability metric the function is held to, or is defining that part of this mandate?
• How much latitude does an EM here have to make a decisive call that affects another team’s roadmap, versus needing consensus first?
• What’s the current state of the S&O on-call rota — how many people, how often, and how does it feel to them?

For the peer:

• What’s the thing about working here that surprised you — good or bad — that you wouldn’t have got from the job description?
• Where do CTI and S&O currently rub against each other, if at all?
• How does AI tooling actually show up in your week? I’m interested in the gap between what’s adopted and what’s talked about.

On process:

• What are the remaining stages, and roughly what timeline should I expect?

Quick reference card

The five stories that carry the most weight. If you remember nothing else:

Two things to volunteer if they don’t ask: the AI cost-judgement story, and your view on what you’d look at first in CTI and S&O.

One thing to be careful about: when asked about the “Senior” title or levelling, frame it forward (“I want scope and level aligned from day one”) — never as a grievance about Kaluza.