Engineering manager: behavioural questions

Action: I reframed it as a business case, not a tooling wish.

• I put three numbers on one page: repeat audit findings, environment lead time, and how long we would take to rebuild after losing a region.
• I rejected a big-bang rebuild. I proposed an incremental programme: one environment per sprint, using about 15% of capacity, beside features.
• I asked the risk team to co-own the policy rules, so the audit fixes became automated guardrails, not promises.
• Two engineers who knew the wiki best led the templates. I cleared their other work and ran the sponsor demos with them.

Action: I turned a hidden fight into an open agreement.

• I proposed a visible capacity split to the product manager: 70% features, 20% health, 10% learning. We agreed it for one quarter as a trial.
• The team scored every debt item by "interest paid": incident minutes and toil hours per month. The top item cost about 30 hours of manual reconciliation a month.
• I added a health metric to the team dashboard, next to the feature burn-up, so progress was visible to everyone.
• I set a quarterly review with product. If health was green, we could lend some of the 20% back to features.

Action: I changed what I reviewed, not just how much.

• I stepped back from approving PRs. Peer review by two engineers became the rule.
• I set up weekly engineer-led design clinics, with a rotating chair. Decisions were written up as short ADRs with a named decision owner.
• I kept one on-call shift a month, so I still felt production pain and could ask sharp questions.
• I limited my input to designs and risks: security, cost and blast radius. I said "I'd ask about X" instead of "do X".

Action: I treated the people plan as part of the migration plan.

• I answered the question in writing: no role cuts from the migration. I had agreed that with my director first.
• I built a reskilling plan: a certification budget, two hours of learning time a week, and an SRE career path with clear levels.
• We ran paired migration waves. Each app moved with one ops engineer and one cloud engineer, so knowledge flowed both ways.
• We moved about 40 apps in 3 waves, simplest first, so early wins built confidence.

Action: I gave the problem to the team, with the data.

• I owned the overrun with finance first, and promised a plan in 2 weeks.
• We tagged every resource and put cost per service on the team dashboard.
• I added "cost impact" to the definition of done. Any change that moved spend by more than 5% had to say so.
• I asked the engineers to choose the fixes. They picked rightsizing, reserved capacity for steady loads, log-retention tiers, and token caching for repeated GenAI prompts.
• I rejected a feature freeze. It would have hidden the cause and hurt trust with product.

Action: I swapped a monthly argument for a written agreement.

• I showed the product lead what each miss cost: failed payment-status checks and support calls.
• We wrote an error-budget policy together. When the budget is burnt, reliability work comes first until we are back within SLO. My director signed it as the tie-breaker.
• The budget was already spent, so we ran two reliability sprints. We fixed the top 3 failure modes: a connection-pool limit, a slow dependency with no timeout, and a noisy deploy step.
• I rebalanced the on-call rotation across all 8 engineers, with paired shadowing first.

Action: I moved the conversation from estimates to evidence.

• I pulled 6 months of ticket history. Cycle time ranged from 2 to 40 days. The long tail came from big items and too many things in progress.
• The team agreed WIP limits: no more than 4 items in progress at once.
• We practised slicing work thinner, until most items finished in under 5 days.
• I replaced point estimates with probabilistic forecasts from our throughput: "85% likely by 14 March". I explained the method to stakeholders once, in 15 minutes.

Action: I offered an experiment, not a rule.

• I listened to the fears first. The main one was half-built features reaching customers.
• I proposed a 4-week time-boxed experiment. Small commits to main every day, with unfinished work hidden behind feature flags.
• The team chose the success measures: merge time, deploy frequency and change failure rate. They also agreed an opt-out: any failure measure worse after 2 weeks and we would stop.
• I asked the most sceptical engineer to design the flag clean-up rule. That turned a critic into a co-owner.

Action: I treated it as a decision to revisit, not a mistake to punish.

• In the team meeting I said first: "That was the right call for the date. I approved it. Now the context has changed."
• I ran a blameless re-decision session with three options: keep it and add change rules, split the schemas inside one database, or fully separate databases.
• We chose separate schemas with clear ownership as step one. The engineer who made the first call led the new design.
• I funded the decoupling in the roadmap with product, using the cost of the coordination: about 2 days per release.
• We wrote an ADR superseding the old one, linking both.

Action: I set up mechanisms that pulled integration forward.

• We did contract-first design. The OpenAPI spec was agreed with consumers before we wrote code, and mocks were live in week 2.
• Each consumer wrote consumer-driven contract tests, run in our pipeline on every build.
• We held a weekly integration demo with real calls from consumer test apps, not slides.
• I formed a consumer advisory group, one engineer from each team, to review changes, and published a change calendar.

Action: I removed the wait, then escalated with numbers.

• We had a signed API spec. The team built a mock from the agreed contract and coded against it.
• We wrote contract tests to run against the real sandbox the day it arrived.
• I calculated the cost of delay per week: about 1,200 applications still going through manual checks, plus idle engineering time.
• I escalated through the vendor manager, not around them, with that number and a clear ask: a dedicated vendor engineer and a weekly date check.

Action: I put the other team's recovery ahead of our pride.

• We rolled back within 20 minutes of the fraud team's call.
• I posted in the incident channel: "This was our change. We're rolling back now." I owned it publicly in the review too.
• Two of my engineers helped the fraud team re-score the affected transactions that afternoon.
• I funded schema compatibility checks in CI. A breaking change to an event now fails the build.
• We created a consumer registry, so every event lists who reads it and who to tell.

Action: I ran the decision openly with the team, not over them.

• We agreed the criteria first: engineering capacity, 3-year run cost, time to first connector and differentiation.
• We compared three options: build it all, a managed integration platform, or reuse the bank's existing ESB.
• The ESB lacked SaaS connectors. Building meant owning 15 connectors forever, with no customer benefit.
• The one thing that was ours was the orchestration: onboarding flows with our own credit and KYC rules. We chose to build only that.

Action: I chose a guarded pilot over a ban or a free-for-all.

• I worked with security to switch to an enterprise-licensed assistant that doesn't train on our code, and asked people to stop using the public tools.
• We agreed simple rules: no secrets or customer data in prompts, and every AI-written change gets the same human review as any other code.
• I paired juniors with seniors on AI-assisted work, so they learned to question the output, not just accept it.
• I set a baseline, then tracked PR cycle time, change failure rate and a short developer survey for 8 weeks.

Action: I built the skill and the guardrails before the feature.

• I formed a 4-person learning guild with 4 hours a week, a shared reading list and small spikes.
• I brought risk and privacy in during week 1, not week 10. We agreed on masked transcripts and a model hosted within our approved cloud region.
• I set an "evaluation first" rule: no feature work until we had a golden test set of 150 calls with notes written by experienced staff.
• Staff review and edit every summary before saving it. The AI drafts; a person decides.
• I kept a skills matrix and gave two engineers clear stretch goals as AI leads.

Action: I reframed the question from roles to tasks.

• I said, "I can't give you a credible number today. In 8 weeks I can give you a measured one."
• With operations leads, I picked two specific tasks: classifying incoming correspondence, and drafting replies to address-change requests.
• We measured a baseline of handling time and error rate for 2 weeks before any AI was switched on.
• Every AI output had human oversight: staff approved or fixed it, and we logged every fix.
• I briefed the operations team myself and shared the results with them first.

Action: I ran it as a normal incident, not an AI mystery.

• I used the kill switch (a feature flag) within 6 minutes. Staff saw a banner pointing them to the policy site instead.
• I sent the business clear updates: what was wrong, which fee, and that a person should check any answer from the last 24 hours.
• The root cause: the search index rebuilt nightly, but the policy update landed after the run. The model faithfully used stale content.
• We added index freshness checks, source-document versioning with an effective date, and evaluation regression gates: every content change reruns the test questions before release.

Action: I changed what we tested and where we looked.

• I replaced puzzles with a 90-minute paid-time work sample: debug a small, broken cloud deployment and explain the fix.
• Every interviewer used the same questions and a written scoring rubric, and scored before discussing. This cut "gut feel" bias.
• I rewrote the advert around outcomes and removed a "10 years' experience" line nobody could justify.
• I started an internal apprenticeship: two people from adjacent support and testing teams joined on a 6-month paired plan.

Action: I started with a private, honest conversation.

• I asked what had changed and whether anything outside work was affecting them. It wasn't. They admitted they felt lost in the new stack.
• With my HR partner, I wrote down clear expectations with examples: changes pass review in two rounds, and they handle one on-call shift alone.
• I agreed a learning plan with protected time, and paired them with a patient senior engineer twice a week.
• We held fortnightly check-ins with specific feedback, written up and shared with them after each one.
• I used their batch knowledge where it was valuable, in planning the legacy data migration.

Action: I made progress and purpose visible.

• I put a burn-down of legacy interfaces on the team wall and dashboard: 64 down to zero.
• Each time a legacy component was retired, we held a short "switch-off" celebration. The engineer who did it pressed the final button.
• I rotated people off the grindiest reconciliation work every 6 weeks, and gave each person a small improvement project of their choice.
• I invited a lending officer to show how the old system's delays hurt customers, linking the work to customer outcomes.

Action: I offered a time-boxed stretch with support.

• I proposed "lead for a quarter" on a new card-dispute API, with an easy way back and no stigma if they chose it.
• I coached weekly for 30 minutes, using their real situations, not theory.
• I delegated real design decisions to them, including the error-handling model. I gave input but didn't overrule.
• They ran the fortnightly stakeholder demos. I attended the first two, then stepped out.
• I reframed "politics" as helping others decide well, which matched how they already thought.

Action: I changed the meeting design, not just the message.

• Designs went out as written pre-reads 2 days ahead.
• Each review started with 10 minutes of silent commenting in the document, so the loudest voice didn't anchor the room.
• We used round-robin input, remote people first.
• Decisions were recorded with dissent, so disagreeing was normal and visible.
• I modelled it: I asked for critique of my own proposals, and thanked people for it in public.

Action:

• In a private 1:1, I gave specific feedback: three real review comments and the wait times, framed around impact, not character.
• I listened. They felt quality was slipping and that they were the last line of defence. That was a real concern.
• I reframed the role as "coach, not gatekeeper": quality comes from raising others, not catching everything yourself.
• We agreed clear expectations: reviews within 1 working day, comments labelled must, should or nit, and always explain the "why".
• I gave them a teaching role: a fortnightly payments-domain session, plus a month of paired reviews with juniors.

Action:

• I met each of them privately first. The events lead worried about coupling and scale; the API lead worried about debugging and consistency for the broker portal.
• I ran an "argue the other side" session, where each presented the other's option at its best. The tension dropped straight away.
• Before scoring, we agreed weighted criteria: latency, consistency, operational complexity, team skills and future consumers.
• We scored together. Events won for downstream fan-out; the sync API won for the portal's real-time query. The outcome was a hybrid: a query API plus events for status changes.
• I wrote it up in a decision record, including the dissenting view and a trigger to revisit.

Action:

• I recruited 5 volunteers from the squads through an open call that explained the mission, picking a mix of infrastructure, security and app skills. They brought trust from their old squads.
• We wrote a team charter: our purpose, our customers and what we would NOT do.
• I treated the golden path as a product: interviews with 8 squads, a backlog ranked by pain, and a quarterly satisfaction score from our internal customers.
• We shipped a thin first version (service template, pipeline and observability defaults) with 2 friendly squads as design partners.
• We ran office hours and wrote docs, with no mandates, and published adoption and lead-time data openly.

Action:

• My own team instrumented one end-to-end flow first, with a neighbouring team that volunteered.
• I started a weekly 20-minute "trace of the week" show-and-tell. Each one showed a real slow hop in someone's flow, such as a 1.8-second config lookup on every request.
• I always gave shared credit to the team that fixed it, and never shamed anyone.
• I made it cheap: a shared library and a 1-page guide, so setup took under an hour.
• I tracked adoption publicly and asked early adopters to demo their wins.

Action:

• I designed incident replay onboarding: three past incidents replayed in a sandbox with the original alerts, logs and timeline.
• New joiners worked through them in pairs: diagnose, find the service, propose the fix, then compare with what really happened.
• I chose incidents that covered the key flows: a poison message, an expired certificate and a timeout cascade.
• A senior engineer ran a 1-hour debrief on each one, explaining the architecture behind the failure.
• Week 2 ended with a small, real production change, made with a buddy.

Action:

• We agreed a goal, and fortnightly 45-minute sessions for 12 months.
• We paired on turning recurring tickets into ADR-style problem statements: context, problem, options and consequences.
• I added stretch assignments step by step: draft one ADR with my review, then present at design review, then lead one.
• I gave them visibility: they presented their analysis of the top 5 error categories to the architecture forum.
• I stepped back as they grew, from co-writing to only reviewing.

Action: I made the trade-off visible instead of hiding it.

• I scored each initiative on cost of delay per month (revenue, risk and regulatory exposure) with the product owners.
• I ran one session with all 6 sponsors and showed the ranking. I proposed to explicitly stop 2 initiatives, rather than slow all 6.
• I protected the top 2 outcomes: a regulatory reporting change and a digital loan top-up feature.
• I funded two weeks to automate toil: manual environment builds and release checklists ate about 15% of the team's time.
• The stopped work was parked with a written restart note, so nothing was lost.

Action: I took the noise away from the people fixing the problem.

• I asked executives to route all questions through me, and sent hourly updates in plain language: impact, progress, next update time.
• At hour 7 I set up a rest handover: a fresh shift took over with a written state of play, and I sent shift A home, including two people who wanted to stay.
• I organised food and taxis, and gave the next day off in lieu.
• Three days later I facilitated a blameless review with a full timeline. I asked "what made this easy to get wrong?"
• I put the top 5 actions into the next two sprints, with owners, and reported their progress to the executives.

Action:

• I opened a bridge and assigned roles: an ops lead to fix, and a comms lead to post updates every 15 minutes to the service desk and executives. I stayed off the keyboard.
• We found one malformed poison message that failed to deserialise. The consumer retried it forever and blocked the partition.
• I chose mitigation over root cause: move the message to the dead-letter queue and let the consumer drain. I ruled out restarting consumers (it wouldn't help) and manually skipping the offset (we'd lose traceability).
• The backlog drained in order, and we confirmed recovery with a synthetic payment.
• Within 48 hours I ran a blameless review: timeline, contributing factors, and 5 actions with owners and dates.

Action:

• I built a forecast with finance and product: about 3.2 times a normal day at the peak hour.
• I ran a game day in a prod-like environment, replaying shaped traffic at 1x, 2x and 3.5x.
• At about 70% of the expected peak, autoscaling stopped. We'd hit a cloud vCPU quota ceiling and a database connection limit that nobody had re-checked after the migration.
• I raised quota increases with the provider, tuned connection pooling and pre-scaled the day before. I considered freezing statement downloads, but it wasn't needed once the limits were fixed.
• I re-ran the game day to 3.5x, passed, and wrote a peak-day runbook with a named decision-maker.

Action:

• During the incident, I proposed switching retries off through config, which let the partner recover.
• The first line of my postmortem said: "I approved the retry policy, and it amplified the outage." I didn't hedge.
• I studied established guidance: exponential backoff with jitter (Marc Brooker, AWS Architecture Blog) and retry budgets (Google SRE book).
• With my tech lead, I wrote a resilience standard: capped exponential backoff with full jitter, a circuit breaker, a per-client retry budget (retries under about 10% of calls) and timeouts shorter than the caller's.
• I gave two teams sprint capacity to apply it, and we added a chaos test that injects partner failures.

Action:

• I ran an alert audit: 6 weeks of pages, each tagged actionable, duplicate or noise. About 75% were noise.
• I set a rule: every alert needs an owner, a runbook link and a clear action. Otherwise it is deleted or becomes a ticket.
• I introduced burn-rate alerting on SLOs for the 5 customer-facing flows. It replaced dozens of CPU and queue-depth alerts.
• I added a weekly 30-minute on-call review: for each page, fix the cause or fix the alert.
• I agreed time off in lieu after overnight pages with management.

Action: I made the decision shared, not imposed.

• I showed the real cost: 8 months of time logs, security patches and the features we hadn't built.
• I asked the team to write the decision criteria first: security, developer experience, run cost and roadmap fit. Then we scored both options together.
• The standard won on 3 of 4. I said plainly that I would retire our tool, and I recorded the dissent on developer experience.
• I recognised the original builders publicly at an all-hands, and helped them propose their best feature upstream to the platform team.
• The builders led the migration plan, in waves, with the noisiest services moving last.