Teks Kengesh: The Strategic Technical Advisor
Lecture 2

The Diagnostic Interview: Uncovering Hidden Needs

Teks Kengesh: The Strategic Technical Advisor

Transcript

SPEAKER_1: technical excellence is the entry ticket, not the game. So now the question is — how do you actually find out what the real problem is? SPEAKER_2: And that is the gap most advisors fall into. The stated problem and the actual problem may not be the same thing. You need a method, not just a mindset. SPEAKER_1: So what does that method look like? What is the structured approach here? SPEAKER_2: Think of it like a diagnostic interview in clinical practice. In mental health, the diagnostic interview is the primary method for gathering information needed to understand a patient's problems and formulate a treatment plan. The same logic applies when a client says 'we need to rewrite our entire platform.' SPEAKER_1: So the presenting complaint is rarely the diagnosis. SPEAKER_2: Right — it has to be tested. And structure matters enormously here. Research shows unstructured interviews alone have substantially lower reliability — different clinicians reach different conclusions from the same conversation. For a technical advisor, a free-form discovery call carries the same risk. SPEAKER_1: Can you give a concrete example of what structured questioning actually looks like in a discovery call? SPEAKER_2: Suppose a CTO says their deployment pipeline is broken. An unstructured advisor jumps to CI/CD tooling. A structured advisor asks: why is it broken, what breaks, when did it start, what changed before that, what does it cost per week. That sequence is the 5-Whys applied to a technical ecosystem. Each answer feeds the next question. SPEAKER_1: And you keep going until you hit something that isn't technical at all. SPEAKER_2: Exactly. The fifth answer might be 'two teams are deploying to the same environment without coordination.' At that point, the advisor may be working on organizational design, not tooling. That may be the hidden need — and the sequence helps surface it. SPEAKER_1: Now, what about the relationship side? A client who feels interrogated will shut down fast. SPEAKER_2: The key idea from clinical research is this: the quality of the relationship built during the diagnostic interview strongly influences how much sensitive or hidden information someone is willing to share. If the advisor feels like an auditor, the client performs. If they feel like a partner, the client reveals. SPEAKER_1: So how does an advisor signal that partnership early — especially around uncomfortable topics? SPEAKER_2: Two moves. Use semi-structured questioning: a fixed core sequence, but follow unexpected threads when they appear. Second — and this is striking — empirical work on clinical interviewing shows that when interviewers explicitly invite sensitive topics, people disclose more than expected. The barrier is usually the advisor's discomfort, not the client's resistance. SPEAKER_1: That is a real reversal. The advisor is the one avoiding the hard question. SPEAKER_2: And that avoidance is expensive. That is the risk exposure that justifies the entire engagement. SPEAKER_1: What about documenting all of this? A discovery call with great insight but no structured output is just a good conversation. SPEAKER_2: The clinical model is instructive. Good diagnostic practice means documenting not just the conclusion but the reasoning — key history elements, alternative explanations considered, and remaining uncertainties to monitor. For a technical advisor, that means: stated problem, inferred underlying problem, business impact, and open questions still unresolved. SPEAKER_1: And those open questions matter because an early read might be wrong. SPEAKER_2: That is the most important discipline in this whole process. Treat diagnostic impressions as hypotheses, not conclusions. A client who says 'our team is slow' might be describing a tooling problem, a process problem, or a morale problem. The takeaway for everyone building this skill: stay curious longer than feels comfortable. The solution you eventually propose will be one they already believe in — because they helped you build it.