Thinking big: level calibration, anti-patterns and a worked answer

This is the competency where a candidate's level is revealed most sharply, because a mid-scoped answer to an org-scoped question is immediately visible.

This lesson starts with that failure and what to do if you do not have a staff-scoped story. Then it covers the two anti-patterns that sink strategy stories — a plan nobody adopted, and a plan nobody lost from — and finishes with a full staff-level answer and its drilling.

The mid-scoped answer to an org-scoped question

The question is "tell me about a time you had to think beyond your immediate team." The candidate is interviewing for staff. The answer:

"We had a lot of duplicated code between our service and the notifications service, so I proposed we extract a shared library. I wrote it, and the other team adopted it, and it saved both teams from maintaining two copies of the retry logic."

That is a fine story and it answers a different question. Scope: two services. Horizon: weeks. Business connection: none stated. Exclusion: none. It reads as senior, at best, and it was offered in answer to an org-scoped question, which makes the gap conspicuous rather than neutral.

The interviewer will usually give one more chance — "anything at a larger scale?" — and the candidate who has nothing should say so rather than stretching the same story.

If you do not have a staff-scoped story

Two honest options, both better than inflating.

Answer at your real scope and name it. "The largest-scope thing I've done is two teams, so let me give you that, and then I can tell you how I'd approach the org-level version of it." Then actually do the second part. Reasoning well about a hypothetical is worth real credit and is clearly labelled as hypothetical.

Offer the adjacent evidence. Sometimes the org-scoped thinking exists without the authority: a document you wrote that was not adopted, a case you made that lost. Tell it as what it was, including the loss, and spend the reflection on why it did not land. Handling questions you have no story for covers this move in general.

Anti-patterns

Having a large-scope story is necessary, not sufficient. Two anti-patterns sink stories that are genuinely org-scoped.

Anti-pattern 1 — the grand plan that never shipped

"I wrote a three-year technical strategy for how our platform should evolve. It covered the service boundaries, the data architecture, and a migration sequence. I presented it to the leadership team and it was well received. Not much of it has happened yet — priorities shifted — but I still think it was the right direction."

The write-up:

"Think Big — no evidence. Substantial document, no adoption. Asked what changed as a result: 'people refer to it'. Asked which specific objections they addressed before presenting: none — presented to leadership first. This reads as a vision exercise rather than as strategic leadership. Would want to see one thing that actually moved."

The tell is "presented to leadership" as the first move. Strategy that lands is negotiated with the people who have to do the work before it is presented to the people who fund it.

Anti-pattern 2 — the strategy with no trade-offs

"The plan was to consolidate all four data pipelines onto one platform, improve reliability, reduce cost, and speed up delivery for every team."

Four benefits, no cost, no exclusion, and nobody who lost anything. Real strategies hurt somebody — a team gives up ownership, a project gets cancelled, someone's preferred technology loses. A proposal with no losers was either not adopted or was not a strategy.

Interviewers probe this directly: "who was worse off?" If there is no answer, the story collapses.

A worked example

Here is the customer-data story from the previous lesson's examples, told in full at staff scope.

The follow-ups

Interviewer: Three of five teams. What about the other two, and how honest is "by choice"?

Tariq: The two remaining are the analytics-adjacent team, which was out of scope deliberately and will need a different answer, and one product team that has a genuine latency requirement the service doesn't meet yet — sub-ten-millisecond reads on a hot path. They're not blocked on willingness, they're blocked on the service not being good enough, and I'd rather say that than dress it up.

On "by choice": the compliance-critical team was mandated, and I should be clear that mandate came from the director, not from me. The other two chose it, and I'd say one of those was a genuine choice and one was social — they went after their peer team did and it had gone fine. I'd count that as one and a half.

Interviewer: Who was worse off?

Tariq: Three groups. The clean-data-model team, who spent six weeks for no direct benefit — that cost is real and it never got paid back to them. The platform team, who inherited on-call for a service they didn't design, which I'd now say I handled badly; I got the ownership transfer right and the handover wrong, and they carried about two months of pages for a system they were still learning. And my own team, who lost the interesting piece of work at month four having built it.

Interviewer: You made a commitment that you'd stop if the latency requirements weren't met. Did you have the authority to make that commitment?

Tariq: Not formally, no, and I've thought about whether that was reckless. What I actually said was that I would recommend stopping and would not push it through over their objection, which is a commitment I could keep. The written version says "I will not advocate for this if it doesn't meet your latency bar."

That distinction mattered later, because the sub-ten-millisecond team I mentioned is exactly that case. When it turned out we couldn't meet their bar, I said so in the review rather than arguing that they should relax it. That cost me a migration and it's the reason the other teams believed the rest of what I said.

Interviewer: What would have made you abandon this entirely?

Tariq: Two things I named at the time, and one I should have.

First: if legal's count had come back as one deal rather than three, or if the deals had stalled for unrelated reasons, the whole business case evaporates and this is a hygiene project competing against features. I asked for the count before I did anything else, for that reason.

Second: if two or more of the five tech leads had been genuinely opposed rather than reluctant. A cross-team migration with two active opponents takes years and produces a half-migrated system, which is worse than either end state. My threshold was that I needed three supportive and none actively opposed.

The one I should have named: a competing solution. About four months in, a vendor product came up in a leadership discussion that would have covered maybe seventy percent of this. I hadn't looked at buying at all, which was a gap — I'd framed it as an engineering problem from the start. We evaluated it, it didn't fit our data model well enough, and we continued. But I got to that evaluation because someone else raised it, not because I'd considered it.

Interviewer: Was that a bias?

Tariq: Yes, and a predictable one. I'd spent three weeks building support for a thing I'd designed. By the time buying came up I had sunk cost and social cost in the build. I don't think the answer changed, but I can't claim I evaluated it cleanly, and now I put a "what would we buy instead" section in anything I propose that's more than a quarter of work.

What the write-up said

"Think Big — strong hire, staff level. Aggregated a signal (3 stalled deals) from outside engineering that nobody was counting, and connected it to a growth rate to produce a dated forecast. Explicit, defended exclusion of analytics with the cost of inclusion stated — strongest staff signal in the interview. Persuasion sequenced deliberately: individual conversations with the five leads before any formal document, director last. Changed the proposal in response to the most important objection and made a costly, keepable commitment that they later honoured at their own expense. Gave up ownership for adoption reasons. Honest and unprompted about mandated vs voluntary adoption, about who was worse off (including their own team), and about a real evaluation bias (never considered buying). Handover to the platform team was handled poorly by their own account. Also strong evidence for Earns Trust."

The moment that made this a staff-level answer was not the outcome. It was the exclusion, and the fact that Tariq could say what including analytics would have cost.