Consultative Discovery for Engineering Leaders, A Playbook

TL;DR — Skip the requirements doc and run actual discovery. Ask about outcomes, not features. Document the stuff nobody wrote down, because that is where the real constraints live.

The biggest mistake I see senior engineers make when they get handed a new initiative is to start sketching the system before they understand the request. The PM hands over a doc, the engineer reads it twice, and then a Mermaid diagram appears on Confluence within the hour. Six weeks later we discover the doc was wrong about the success metric, the stakeholder who actually pays for the work was never consulted, and the team is now defending a design against requirements that have quietly mutated.

Consultative discovery is the antidote. It is the practice salespeople have been doing for forty years, dressed up in engineering clothes. The premise is simple. Before you propose a solution, you do the work to understand the problem, the business it sits inside, and the political environment that will either fund or kill your design. This is not optional work, and it is not a soft skill. It is the highest-leverage thing a senior engineer or staff-plus can do in the first two weeks of any non-trivial initiative.

I have been running this playbook for the last several years across infra migrations, RAG rollouts, agentic AI builds in 2024, and a couple of platform engineering greenfield projects. The questions change. The structure does not. Here is the version I use today.

The four-quadrant discovery model

Most discovery failures come from missing one of four quadrants. I keep a literal 2x2 on a Notion page for every initiative and refuse to write a design doc until each cell has at least three entries.

Engineers are great at the bottom-right cell and bad at the top-right. Product folks are great at the top-left and oblivious to the bottom-left. Your job as the senior is to fill in all four. If you cannot name the sponsor’s bonus structure by the end of week one, you have not done discovery, you have done a meeting.

The discovery questionnaire

I run this as a 45-minute structured interview, not a survey. Ship the questions ahead of time so people think. Take notes in plain text. No slides.

## Outcomes
1. If this initiative succeeds, what number changes, and by how much?
2. What is the date that number is measured?
3. Whose forecast or OKR is tied to that number?
4. What is the cost of doing nothing for one more quarter?

## Constraints
5. What did the last attempt cost, and why did it stop?
6. What is the headcount we can hire against this in the next 6 months?
7. Which auditors, regulators, or customers have approval rights?
8. What is the existing system we cannot replace before Q3 next year?

## Politics
9. Who will be quietly unhappy if this works?
10. Who has tried something similar and what did they pitch?
11. Which VP wants to be the one to announce this externally?
12. Where are the existing budgets that this work might displace?

## Reality
13. Walk me through the worst outage of the last 12 months in this area.
14. What is the manual workaround support uses today?
15. Which dashboards do you check first when something is wrong?
16. What is the one thing you have always wanted to fix but nobody funds?

Question 9 is the one that usually breaks the meeting open. People are not used to being asked who loses when a project ships. Once you have the answer, half your stakeholder map is done.

Run discovery in waves, not as a single workshop

The all-day kickoff workshop is a project management ritual. It produces sticky notes and a vague sense of consensus that evaporates by Tuesday. Real discovery is a sequence.

Wave 1, days 1 to 3. Sponsor and PM only. You are figuring out what the actual ask is and whether it survives a 45-minute conversation. About 30% of initiatives die here, and that is a feature, not a bug.

Wave 2, days 4 to 8. Adjacent teams. Security, SRE, data platform, the team whose service you are about to depend on. This is where you find the “oh, by the way” constraints. A 2024 example from my notes. A team wanted to ship a vector search feature and discovered in wave 2 that legal had already committed to a customer that all embeddings would be deletable within 24 hours of a GDPR request, which killed three of the four candidate vector databases on the shortlist.

Wave 3, days 9 to 12. The skeptics. Find the engineer who left the last attempt at this. Find the staff engineer in the next org over who has strong opinions about your problem space. Buy them coffee. Take notes. Do not argue. You are not there to win, you are there to harvest constraints other people forgot about.

Wave 4, days 13 to 14. Synthesis. Now you write the discovery memo. Not the design. The discovery memo answers the question “what are we actually solving and what cannot change.” The design comes after.

For more on how this connects to writing decision documents, see Translating Business Impact into Architecture Decisions.

The discovery memo template

# Discovery Memo, <initiative>

## Problem in one sentence
<one sentence, includes the metric>

## Why now
<the trigger, usually a forecast or competitive threat>

## Who pays for it
<budget owner, dollar amount if known>

## Hard constraints
- Compliance: <e.g., SOC2, GDPR Article 17>
- Legacy: <systems we cannot replace before <date>>
- Headcount: <available FTEs>
- Time: <drop-dead date and what triggers it>

## Soft constraints (worth knowing, can be negotiated)
- <list>

## Stakeholder map
| Name | Role | Position | Lever |
| --- | --- | --- | --- |
| ... | ... | sponsor/skeptic/blocker | what they want |

## Out of scope (and why)
- <list>

## Open questions blocking design
- <list>

That last section is the one teams skip. Open questions blocking design is the list of things that, if answered wrong, force a redesign. Surface them now or pay 10x later. The 10x is not rhetorical. I have watched a six-month integration project rewrite its event schema in month five because nobody asked in week one whether the partner’s webhook payloads were idempotent. The Apache InLong project has a good public retrospective on exactly this pattern if you want a worked example.

Common Pitfalls

Treating discovery as information gathering. It is not. Discovery is hypothesis testing. You go in with a guess about the real problem and try to falsify it. If you finish wave 2 with the same hypothesis you started with, you were not listening hard enough.

Asking what people want. Almost never useful. People want what they have seen before. Ask about outcomes, frictions, and the manual work they currently do. The solution falls out of the friction list.

Letting the sponsor define success. Sponsors define the metric that pays for the work, which is necessary but not sufficient. The on-call engineer defines the metric that determines whether the system survives the first quarter in production. Both need to be in the memo.

Skipping politics. The fastest way to ship a technically perfect system into a wall is to ignore the VP whose org loses headcount when yours wins. Politics is a constraint. Treat it like one.

Confusing discovery with design review. Discovery happens before any ADR. If you find yourself defending a design in wave 2, you have already lost the plot. Close the laptop, go back to the questionnaire.

Writing the memo alone. The memo is a forcing function for consensus. Circulate drafts, especially with the skeptics. The goal is for the eventual design review to find zero surprises in the constraints section.

Wrapping Up

Consultative discovery is one of those skills that compounds. The first time you run it, it feels slow and political and like work that should be somebody else’s job. The fourth or fifth time, you start spotting the kind of initiative that dies in wave 1 within the first ten minutes of the kickoff call, and you save your team an entire quarter of misdirected work. That is the senior engineer’s contribution to leverage. Not better code, better choices about which code to write.

The playbook is not glamorous. It is questionnaires, memos, and uncomfortable coffees with people who think your project is a bad idea. But in a year where every team is being asked to ship agentic features on a budget that has not grown, the teams that win are the ones who picked the right thing to build before they started building. Discovery is how you do that.

If you want a complementary read on what comes next, the Stripe engineering blog has a good piece on technical decision-making that pairs well with the memo template above. Take what works, discard the rest. The shape of the practice matters more than the wording.