The Most Underrated Engineering Skill
Senior engineers carry an enormous body of knowledge that is never written down anywhere. Failure modes that took a decade to accumulate, judgment calls that cannot be derived from first principles, shortcuts that are safe versus shortcuts that are not — this tacit knowledge is the real intellectual capital of an engineering organization, and most of it disappears when a senior engineer retires or changes companies.
As a junior or mid-career engineer, your access to this knowledge is almost entirely determined by your ability to ask questions well. This is a learnable skill, and it matters far more than most engineers realize. The difference between an engineer who extracts maximum knowledge from senior colleagues and one who extracts minimal knowledge from the same conversations is largely a question of how they structure their questions and interactions.
Why Most Questions Fail to Transfer Knowledge
The typical pattern when a less-experienced engineer approaches a senior for knowledge: the junior asks a yes/no question or a narrow problem-solving question (“Should I use this tolerance here?” or “This part isn’t fitting — what’s wrong?”), the senior answers the specific question, and the junior leaves with a solution but without the underlying reasoning.
This transaction is useful but inefficient. The solution to the specific problem is transferred, but the judgment framework that produced the solution — which would help the junior solve twenty future problems independently — is not.
Effective knowledge transfer happens when questions are designed to surface reasoning, not just answers. The techniques for doing this are straightforward once you understand why the default approach fails.
Five Question Patterns That Extract Deeper Knowledge
1. The Reasoning Follow-Through
After receiving an answer, ask: “What is the reasoning behind that?” or “What would make you choose differently?” This turns a solution transfer into a judgment transfer. The senior engineer may have answered reflexively based on experience — asking for the reasoning forces them to articulate principles that they normally apply tacitly.
2. The Historical Failure Question
“Has this approach caused problems in the past, or is there a failure mode I should watch for?” This is the most efficient question in engineering knowledge transfer. Senior engineers carry an extensive mental catalog of things that went wrong. They rarely volunteer this information unless asked — not from reluctance, but because the failure modes are so well-internalized that they no longer surface to conscious attention. Asking explicitly unlocks this catalog.
3. The Adjacent Domain Question
“Is there a related area where this reasoning does not apply, or where I would need to think differently?” This surfaces the boundaries of the principle being discussed — where the senior’s answer is generalizable versus where it is specific to this context. Understanding the limits of a principle is as important as understanding the principle itself.
4. The Experience Anchor
“Have you seen a situation where this was done particularly well, or particularly badly?” This invites a story. Stories transfer knowledge in a fundamentally different way than abstract principles — they come with context, consequences, and emotional salience that makes them memorable and retrievable. Senior engineers often have vivid stories about specific incidents that they rarely share unless asked.
5. The Documented Reference
“Is there something written down about this, or a drawing or project I could look at to understand it better?” This extends the knowledge transfer beyond the conversation itself. Senior engineers often know of internal examples — past projects, design decisions, test reports — that would take weeks to discover independently. A single reference pointed out by a senior engineer can be worth hours of independent searching.
Preparation: How to Make the Most of a Senior Engineer’s Time
The quality of knowledge transfer depends significantly on how you prepare for the conversation. Senior engineers are typically busy, and conversations that start with “I don’t understand this — can you explain it?” extract less knowledge than conversations where you have clearly defined what you already know and exactly where your understanding breaks down.
| Preparation Step | Why It Matters | What to Do |
|---|---|---|
| Define what you already know | Prevents re-explaining basics; shows respect for their time | Write a one-paragraph summary of your current understanding |
| Identify the specific gap | Focuses the conversation on high-value content | Write the exact question where your understanding stops |
| Attempt a preliminary answer | Surfaces your reasoning for correction; often partially correct | Draft your best current answer and bring it to the conversation |
| Prepare follow-up questions in advance | Prevents forgetting important questions during the conversation | Write 3-5 questions before the meeting |
| Bring relevant documents | Grounds the conversation in specifics rather than generalities | Drawing, specification, or problem description in hand |
Recording and Using What You Learn
The conversation is only the beginning of knowledge transfer. What you do with the information after the conversation determines whether it becomes part of your engineering judgment or fades within a few weeks.
The most effective practice is to write a brief note immediately after the conversation — not a verbatim transcript, but a structured summary of the key principles, the reasoning behind them, and any examples or failure modes discussed. This does not need to be elaborate: three to five sentences capturing the core insight is sufficient. The act of writing it forces you to articulate what you actually understood, surfaces gaps, and creates a retrievable reference.
Over several years of practice, this personal knowledge base becomes one of your most valuable engineering resources — a record of hard-won judgment transferred from people who no longer work alongside you.
Relationship Management: Frequency and Reciprocity
Effective knowledge-seeking requires an ongoing relationship, not a series of isolated transactions. Senior engineers who are asked good questions, whose reasoning is genuinely engaged with, and who see their knowledge produce visible results in the work of junior colleagues, are generous with their time and attention. Senior engineers who feel their time is consumed by underprepared questions or by colleagues who take solutions without understanding them become less available.
Reciprocity matters even when the knowledge asymmetry is large. Junior engineers typically bring current technical literacy — familiarity with new tools, updated standards, contemporary literature — that has genuine value to senior engineers whose deep expertise was developed in an earlier technology context. Acknowledging this and offering to share relevant knowledge you have creates a mutual exchange rather than a one-directional drain.
FAQ
Q: I am afraid of looking incompetent when I ask questions. How do I manage this?
The most competent engineers ask the most questions — a pattern that is visible to any senior engineer with experience in mentoring. What signals incompetence is not asking questions; it is asking unprepared questions that reveal no prior effort. Preparation is the answer: arrive with documented evidence of what you have already tried or looked up, and your question becomes evidence of systematic thinking, not ignorance.
Q: The senior engineer in my group is not approachable and seems annoyed by questions. What do I do?
Some senior engineers are genuinely not good knowledge sources regardless of their technical depth — temperament and communication style matter. Identify alternative sources: retired engineers who consult occasionally, engineers in adjacent departments with overlapping experience, professional associations, and documented project records. Simultaneously, consider whether the “unapproachable” characterization is actually about unprepared questions or timing — some engineers who seem unavailable in general become very engaged when approached with a specific, well-framed technical question.
Q: How do I ask questions about sensitive topics — past failures, design decisions that seem questionable — without creating friction?
Frame these questions around learning rather than judgment: “I noticed this design choice — I want to understand the reasoning so I can make similar decisions well” is fundamentally different from “Why was this done this way?” even when they are asking about the same thing. The first invites explanation; the second can feel like an accusation. Most engineers respond generously to genuine curiosity expressed respectfully.
コメント