Course Content

Developing others: anti-patterns and worked answers for engineers and managers

Two anti-patterns account for most zero scores in this competency, and the first is told as generosity.

This lesson covers both, then works through the competency in two variants: the individual contributor version, where Lena describes mentoring one engineer, and the manager version, where Nadia answers the underperformance question. Same competency, different question, and both are scored on the same things.

The competency is the change in another person, so a story whose only subject is you cannot score on it.

Anti-pattern 1 — I did their work

"There was a junior engineer struggling with a piece of the migration. It was blocking us, so I took it over and finished it over a weekend, and then walked them through what I'd done afterwards so they'd learn from it."

Told as generosity, scored as the opposite:

"Developing Others — negative. Candidate removed a learning opportunity under time pressure and framed a retrospective walkthrough as teaching. Asked what the engineer was able to do afterwards that they couldn't before: no answer. Delivery instinct is fine; this is not a development story."

Anti-pattern 2 — mentorship with no measurable outcome

"I mentored a couple of people through our formal mentorship programme. We met monthly and talked about their careers, and I think they found it valuable."

Plural, low-intensity, no diagnosis, and no outcome. The killer follow-up is "what could they do at the end that they couldn't at the start?" and there is no answer.

A worked example: the individual contributor version

Worked example — "Tell me about someone you mentored" (individual contributor)

Lena, invented, a staff engineer interviewing at another company. About three minutes, then the drilling.

Lena: "Jia joined our team at Pelago as a mid-level engineer about two years ago, with solid experience — three years, good code, fast. Their goal was to move to senior, and their manager and I both thought they were closer than they felt.

The problem was specific. Every design document Jia wrote came back from review heavily rewritten, usually by me or by one other senior engineer, and then implemented roughly as rewritten. That had happened four or five times. From Jia's side it looked like their designs weren't good enough. From the outside it looked like they couldn't operate independently at the next level, which was blocking the promotion.

My first intervention was wrong, and it's worth saying. I assumed it was a knowledge gap and sent them reading — a couple of internal design docs I thought were good, and a book chapter on distributed systems. It did nothing, because it was never a knowledge problem. Jia knew the material better than half the people reviewing them.

What was actually happening: their designs answered 'how' in a lot of detail and never stated 'why' or what the alternatives were. So a reviewer reading it had no way to evaluate whether the design was right — the only available action was to substitute their own judgement, which comes out as a rewrite. It was a framing problem and it read as a competence problem.

So the intervention changed. Three things.

First, I stopped rewriting. Completely. In review I only asked questions, and mostly one question: 'what else did you consider and why not that?' That was uncomfortable for about six weeks because designs went out with things in them I'd have done differently, and two of those were fine and one was a genuine mistake we caught in implementation.

Second, we paired on one document end to end — ninety minutes a week for about six weeks — where I made Jia write the alternatives section first, before the design. Not the design and then a justification. The alternatives first.

Third, I asked Jia to review two of my designs, with a specific brief: tell me what I haven't justified.

The cost was real. That ninety minutes came out of an ingestion rewrite I owned, which slipped about three weeks. I'd make that trade again without thinking about it.

Where Jia is now: promoted to senior about nine months after we started, and they run the design review for that team, which is the thing I used to do. Two months ago they reviewed a design of mine and told me I'd asserted a latency requirement without saying where it came from, which was correct and which I'd have caught in nobody else's document.

Reflection: I'd been the person rewriting their designs for four cycles before I asked why it kept happening. The rewrites felt like help. Each one individually was cheaper than the conversation, and cumulatively they were the thing causing the problem."

The follow-ups

Interviewer: How did you work out it was a framing problem rather than a skill problem?

Lena: Two things, one of which was luck. The luck was that I read a design Jia had written for something outside work — a side project write-up they shared in a channel — and it had exactly the reasoning that was missing from the work documents. Same person, same subject matter, completely different quality of argument. That told me the capability was there.

The non-luck part was that I went back through the four documents and looked at what my own rewrites had actually changed. In three of the four, the technical decision I'd landed on was the same one Jia had proposed. I'd rewritten the framing and kept the design. That was uncomfortable to notice.

Interviewer: You said you stopped rewriting and one design went out with a genuine mistake in it. Talk me through that.

Lena: It was a decision to poll a downstream service every thirty seconds where an event subscription was available. Jia's design considered both and chose polling because it was simpler to reason about, which is a defensible argument, and I disagreed with it. In the old model I'd have changed it in review.

What I did instead was ask what the load would be at ten times current volume, in the review, in front of the team. Jia hadn't calculated it. They came back the next day having done the arithmetic and changed it to a subscription themselves.

So it didn't ship broken, and I want to be honest that I got somewhat lucky there — the question happened to expose the specific weakness. If it had shipped, we'd have had a performance problem in about two quarters, and I'd have judged the cost worth it, but that's easy to say when it didn't happen.

Interviewer: Would you have let it ship?

Lena: Not that one, no. My rule was that I'd stop rewriting, not that I'd stop caring — if the question hadn't worked I'd have said plainly that I thought it was wrong and why. The difference is that the decision would still have been theirs to make with my objection on the record, rather than mine to make silently by editing their document.

Interviewer: What about the people you mentored who it didn't work with?

Lena: There's one clear case. Another engineer on the same team asked for the same arrangement about six months later, and I said yes and ran the same playbook — the pairing, the alternatives-first thing — and it went nowhere for about three months.

What I got wrong was applying Jia's intervention to a different problem. This person's issue wasn't framing, it was that they didn't want to write designs at all; they wanted to be given specified work and do it very well, which they did. I spent three months trying to develop them toward a role they hadn't actually asked for, because I'd assumed the goal was the same.

We stopped, and the useful conversation was the one where I asked what they actually wanted and got an answer I hadn't expected. They're a very strong senior engineer now on a platform team, doing deep work, and writing about one design document a year.

The manager variant

The same competency, asked of a manager candidate, gets a different question: "how do you handle an underperforming team member?" An invented answer from Nadia, an engineering manager:

Nadia: "One case, and it ends with the person leaving, so I'll be upfront about that.

Six-person team. One engineer, eighteen months in the role, whose output had dropped noticeably over about two quarters — from a solid contributor to about a third of the throughput of their peers, with quality problems appearing in review.

The first thing I did was assume it wasn't about capability, because it had changed rather than always been true. I asked directly in a one-to-one: 'Your work has changed over the last few months and I want to understand why before I form a view. What's going on?' The answer was partly personal circumstances and partly that they'd been moved onto a part of the system they had no interest in during a reorganisation nobody had discussed with them.

So I tried two things over three months. I moved them back onto the area they'd been strong in — which cost the team, because someone else had to take the part they'd been on. And we set three specific, written, observable goals with a date, because I've learned that 'improve' without a written definition is unfair to everyone.

The area move helped and the goals were not met. Two of three, partially, in three months. At that point I had a direct conversation: 'Two of these three haven't moved, and I need to tell you plainly that this isn't sustainable in this role. I think the honest question is whether this is the right role, not whether you can try harder.'

They came back a week later and said they'd been thinking the same thing. We agreed a three-month transition, I supported an internal move that didn't work out, and they left with six weeks' notice and a reference I was happy to give. They're doing something adjacent now and by all accounts doing it well.

What I'd do differently: I should have started the written goals in month one, not month three. I spent the first two months hoping the area change would be enough, and that delay made the eventual conversation more of a surprise than it should have been. Nobody should be surprised by a performance conversation."

What the write-ups said

"Develops Others (Lena) — strong hire. Single named person, sustained cadence, named opportunity cost. Volunteered a failed first intervention and the evidence that corrected it, including an uncomfortable finding about their own reviews. Changed their own behaviour (stopped rewriting) at real risk and could reason about where the limit of that rule was. Outcome belongs to the mentee and includes the relationship inverting. Volunteered an unsuccessful case unprompted and diagnosed it as their own error of assumption rather than the other person's."

"Develops Others (Nadia) — hire. Direct, specific, written goals; sought cause before forming a judgement; tried a structural change before a performance process. Honest ending. Named the delay in starting documentation as their own error and articulated the principle ('nobody should be surprised'). Would want to probe how the rest of the team experienced the workload shift."