Chapter 16: Worked Examples II: Leadership, Ambiguity, and Cross-Functional Work

Why this matters

These three categories are especially prone to a specific shared failure mode: candidates describing their environment and their team's accomplishments in detail while leaving their own individual contribution genuinely unclear — precisely the "we" problem from Chapter 8, showing up here in its three most common disguises.

Worked Example 4: Leadership

Question: "Tell me about a time you led a project or initiative."

Weak answer:

"I led the effort to migrate our monolith to microservices last year. It was a huge undertaking involving basically the whole engineering team, and we had a lot of planning meetings and had to coordinate across several teams. It took about six months, and in the end we successfully migrated everything and the new architecture has been working great."

What's wrong: "Led" is asserted but never demonstrated — no specific action attributed to the candidate personally is ever described; "we had a lot of planning meetings" is entirely passive, collective language. No specific decision, trade-off, or piece of influence is described. "Working great" is unmeasured.

Strong answer:

"I proposed and drove our migration from a monolith to microservices, starting with a written plan that specifically sequenced which of our twelve modules to extract first, based on which had the fewest cross-module dependencies — I wanted an early, low-risk win to build organizational confidence in the approach before tackling the harder, more tangled modules. I personally led the extraction of the first two modules myself to work out a repeatable process, then wrote a runbook and paired with three other engineers to extract the remaining modules using that process. When the payments team pushed back midway through, concerned about the migration's risk to their own roadmap, I met with their lead directly, walked through our rollback plan in detail, and agreed to a slower rollout timeline specifically for their dependent services to address the concern. The full migration completed in five months, one month ahead of the original estimate, with zero production incidents attributable to the migration itself, and two other teams have since adopted the same extraction runbook I wrote for their own service splits."

What makes it strong: Specific, individually-attributed decisions throughout ("I proposed," "I personally led," "I met with their lead directly") clearly distinguished from collective execution ("paired with three other engineers"). A concrete example of influence without unilateral authority (addressing the payments team's pushback through direct engagement, not by overriding their concern). Multiple specific, measurable results (timeline, incident count, and the runbook's adoption elsewhere as a durable, spreading impact).

Worked Example 5: Ambiguity

Question: "Tell me about a time you had to work with unclear or incomplete requirements."

Weak answer:

"Our product manager gave us a pretty vague spec for a new feature, so we had a lot of discussions to try to figure out what was actually needed, and eventually we landed on an approach that worked."

What's wrong: "We had a lot of discussions" describes a process without describing the candidate's specific contribution to it. No description of what was actually unclear, what specific approach was used to resolve the ambiguity, or what the eventual approach actually was.

Strong answer:

"Our product manager's spec for a new search feature said only 'let users find what they're looking for faster' — no definition of what 'faster' meant quantitatively, and no specific behavior spec for edge cases like empty results or typos. Rather than going back and forth over email trying to fully spec it upfront, I built a simple, rough prototype in about a day implementing my best guess at the core behavior, specifically so we'd have something concrete to react to instead of abstract discussion. I walked the product manager and two frequent users through it, and their reactions immediately surfaced two real requirements neither had thought to state explicitly — they wanted typo tolerance and wanted results ranked by recency for time-sensitive content specifically. I incorporated both, and we shipped the refined version within the same week I'd built the original rough prototype, rather than the two to three weeks a fuller upfront spec-and-review cycle would likely have taken."

What makes it strong: The specific unclear elements are named explicitly (no quantitative "faster" definition, no edge-case behavior). A specific strategy for resolving ambiguity is described (a rough prototype to make abstract discussion concrete) rather than a vague "we talked it through." A specific, measurable result (one week versus an estimated two-to-three) that also demonstrates why the chosen strategy for handling ambiguity was actually effective, not just that it eventually worked out.

Worked Example 6: Cross-Functional Work

Question: "Tell me about a time you worked closely with a team outside engineering."

Weak answer:

"I worked with our design team a lot on a recent feature. We had good communication and collaborated well throughout the project, and the end result was something both teams were happy with."

What's wrong: "Good communication" and "collaborated well" are assertions with zero supporting detail. No specific instance of an actual cross-functional tension, translation challenge, or joint decision is described — this could describe literally any project with no differentiating content at all.

Strong answer:

"I worked with our design team on a checkout redesign where the initial design called for real-time inventory validation on every keystroke as a user filled out a shipping form, to immediately flag out-of-stock items. Technically, this would have meant a database query on every keystroke across potentially thousands of concurrent users, which I knew would create real load and latency problems at our scale. Rather than just telling design 'no, that's not feasible,' I asked to understand the actual user problem they were solving — it turned out the core goal was preventing users from completing a full checkout flow only to discover an item was unavailable, which is a real, valid concern, but didn't actually require keystroke-level validation to solve. I proposed validating once, when the cart is first loaded on the checkout page, plus a lightweight recheck immediately before payment submission — which fully addressed their underlying goal at a small fraction of the database load. The designer initially pushed back, worried this felt less 'real-time' and polished, so I built a quick working prototype of both approaches so we could compare the actual felt experience side by side rather than debating it abstractly. She agreed the two-check approach felt just as responsive in practice. We shipped it, and it handled our subsequent Black Friday traffic with no inventory-related incidents."

What makes it strong: A specific, real technical-versus-design tension, not a generic "we collaborated well" claim. Specific evidence of genuine cross-functional translation — investigating the underlying user goal rather than just asserting technical infeasibility, which is the actual, specific skill a Cross-functional question is trying to surface. A concrete resolution technique (a comparative prototype) suited to bridging a genuinely different professional perspective. A measurable, real-world-validated result (surviving Black Friday traffic).

Common mistakes (across all three categories)

1. Asserting a role ("I led," "we collaborated well") without ever describing a specific action that demonstrates it — the claim and the evidence are two different things, and only the evidence actually persuades.
2. Describing collective process (meetings, discussions) without isolating the candidate's own specific contribution to it — exactly the "we" problem from Chapter 8, appearing here specifically in Leadership and Cross-functional stories.
3. Not naming the actual, specific substance of the ambiguity or cross-functional tension, leaving the story generic enough that it provides no real differentiating signal.
4. Describing influence as simply "convincing" someone without describing the actual technique used (data, a prototype, addressing an underlying concern directly) — the technique itself is usually the most evaluative part of these stories.

Checklist: applying these worked patterns to your own stories

1. For a Leadership story, identify at least two or three specific, individually-attributed decisions or actions, distinct from the team's collective execution.
2. For an Ambiguity story, name the specific unclear element explicitly, and describe a specific strategy (not just "discussion") used to resolve it.
3. For a Cross-functional story, name the specific tension or translation challenge explicitly, and describe the specific technique used to bridge it — not just an assertion of good collaboration.
4. Across all three, distinguish your own specific actions from the team's collective activity as precisely and explicitly as possible.

Additional sample questions on these themes

1. "Tell me about a time you had to rally a team around a decision they initially resisted." A strong answer names the specific resistance and the specific persuasion technique used — data, a pilot, direct one-on-one engagement — not just "eventually they came around."
2. "Describe a time you had to make progress on a project with a poorly defined scope." A strong answer names the specific missing definition and a specific strategy (like Worked Example 5's prototype-to-clarify approach) for making progress despite it.
3. "Tell me about a time you had to translate a technical concept for a sales or marketing team." A strong answer describes the specific translation technique used, tailored to that audience's actual goals, not just "I explained it simply."
4. "Tell me about a time you had to lead without any formal authority." A strong answer names the specific influence technique used and the specific outcome — this is one of the clearest tests of genuine leadership capacity, since formal authority isn't available as a fallback.
5. "Describe a project where the goalposts moved significantly partway through." A strong answer names the specific change and the specific adaptation made, distinguishing genuine flexibility from simply absorbing the change passively.

Chapter summary / cheat sheet

• Leadership: name specific, individually-attributed decisions distinct from the team's collective execution — "I led" is a claim, not evidence.
• Ambiguity: name the specific unclear element explicitly, and describe a specific strategy for making progress despite it, not just "we discussed it."
• Cross-functional: name the specific tension or translation challenge, and describe the specific bridging technique used — genuine collaboration skill shows up in the technique, not in an assertion of good communication.
• All three categories share the same underlying risk: describing environment and collective activity while leaving individual contribution genuinely unclear — actively guard against this in every retelling.

---