Experts see things others don't

Expertise is less about knowing more facts, and more about perceiving a situation differently.

That sounds philosophical. It is actually a practical claim about how people get good at engineering work, and about how technical leaders should develop themselves and other people.

The naive picture of competence is familiar. Experts know more. Experts think faster. Experts have better tools. All of those contain some truth. They are not the interesting part. The interesting part is that an expert and a novice can look at the same incident, the same design, the same roadmap risk, and literally not see the same situation. The expert’s perceptual system has been restructured by practice. Patterns that are invisible to the novice are obvious to the expert. Possibilities that the novice has to reason toward, the expert notices immediately.

Once you take that seriously, a lot of common development advice starts to look wrong. You cannot transfer expertise mainly by lecture. You cannot get someone to “just think harder.” And when you ask an expert mid-flight to justify every step, you are often pulling them out of the mode that makes them expert.

How skill actually develops

Stuart and Hubert Dreyfus studied adult skill acquisition across domains (pilots, chess players, nurses, surgeons) and described five stages that still hold up well.

Novice. Rule-following. Context-free. Needs supervision. “Mirror, signal, accelerate” even when the situation does not call for it.

Advanced beginner. Still mostly rules, but starting to recognise situations. A new engineer six months in: knows what a bug report is, has a rough feel for which bugs will be hard, still wants a check before deciding.

Competent. The big shift. The person plans, chooses, and owns the consequences. Mistakes feel personal. This is often the most anxious stage on the ladder, because accountability arrives before intuition has fully taken over. That anxiety is a feature of the stage, not a character flaw.

Proficient. Sees the whole situation at once. What matters is already salient. They still deliberate on what to do, but not on what is going on.

Expert. The response is part of what they perceive. They do not work through option lists the way a competent practitioner does. In their narrow domain, the world solicits the action.

Two properties matter more than memorising the labels.

First, stages are domain-specific. Stage 5 in React is not stage 5 in incident command or presenting to executives. Most people are expert in at most a couple of things across a career, and novice next door. Titles hide this.

Second, the transitions are qualitative. You do not become expert by being a faster competent person. You become expert by perceiving differently. That is why documentation and explanation help, and also why they are not enough.

Michael Polanyi’s phrase for the gap is tacit knowledge: we can know more than we can tell. A meaningful part of skilled judgment lives in the doing. Lecture transfers the explicit layer. It misses the layer that actually makes someone expert.

Attention is a gate on what you can see

There is a famous demo by Daniel Simons and Christopher Chabris. People are asked to count basketball passes in a short video. About half never notice a person in a gorilla suit walk through the middle of the scene, beat their chest, and leave. They were looking at the screen. They were motivated. The gorilla was large and central. They still did not see it.

The mechanism is called inattentional blindness. Attention gates perception. What you are not attending to, you do not see. Not “see and ignore.” Do not see.

This is uncomfortable in engineering cultures that treat missed signals as moral failures. In a post-mortem, “how did they miss that?” is often the wrong question. A better question is: what about the system of attention made this invisible? Which metrics, tickets, and meeting agendas were the team looking at instead?

That is a technical leadership lever. Leaders direct collective attention. Dashboards, review checklists, roadmap reviews, and incident templates are not neutral. They decide what the team is capable of perceiving. Issue 2’s point about incentives sits next to this: when a measure becomes the thing people are judged on, it also becomes what they can see.

Stress makes experts look like novices

Under stress, attention narrows. That can be adaptive in a fire. It is usually the wrong mode for leadership work: trade-offs, diagnosis, noticing weak signals, helping someone else learn.

Mark Staal’s review of stress and cognition makes the practical point: stressed people do not merely have less bandwidth. They perceive a narrower situation. Experts under enough pressure regress toward more deliberate, rule-like, novice-shaped processing. The pattern library is still there. Access to it gets worse.

So calm is not a soft preference. It is an input to competence. Psychological safety is not “being nice.” It is one of the conditions under which skilled perception stays available.

Trust is how you use experts well

This connects directly to last issue’s decision-making thread.

At proficient and expert stages, forcing real-time step-by-step justification often degrades performance. You are asking someone to translate tacit perception into explicit representation while they are still trying to act. Gary Klein’s work on expert intuition points the same way: in their trained domain, experts often generate one good candidate and simulate it, rather than comparing long option lists.

If you trust the person’s expertise in this domain, ask for the conclusion first: “What would you do?” Let articulation follow when you need a record, a teachable moment, or a decision that has to travel upstairs.

If you do not trust them yet, or the domain is new to them, do not pretend they are expert. Give rules, examples, tighter feedback, and less ambiguity. Matching support to stage beats matching support to title.

The same rule applies to yourself. In your expert domains, trust your trained perception more than business culture trained you to. Outside those domains, slow down and analyse. Domain-specificity is the whole game.

Growing competence on purpose

If expertise is perceptual change, then growth is exposure plus feedback in real situations, not more slides.

A few implications that hold up in practice:

• Work-based learning beats classroom-only learning for skilled work. Structured on-the-job experience, with reflection, outperforms explanation alone.
• Match the support to the stage in this domain. Novices need clarity and tight loops. Competent people need help planning and owning without being drowned in options. Proficient and expert people need novel problems, trust to act, and after-action learning rather than mid-flight interrogation.
• You cannot shortcut the perceptual shift. You can accelerate it with deliberate practice, good problems, and honest feedback. You cannot download it.

For technical leaders, the ROI is double. You get better at the work yourself. More importantly, you stop developing other people with the wrong model of what “getting better” means.

If you want a mirror, look at Mentorship and Decision Making in our Big Tech benchmarks for technical leadership roles. The interesting question is whether you are building other people’s capacity to see, or only transferring your conclusions.

Resources

• Patricia Benner, From Novice to Expert (1984): the most readable applied treatment of the Dreyfus stages
• Michael Polanyi, The Tacit Dimension (1966): “we can know more than we can tell”
• Christopher Chabris & Daniel Simons, The Invisible Gorilla (2010): inattentional blindness and what attention actually does
• K. Anders Ericsson & Robert Pool, Peak (2016): deliberate practice without the mythology
• Gary Klein, Sources of Power (1998): how expert intuition works in real decisions

This series

This is issue 3 of a 12-part fortnightly series exploring technical leadership. Up next: motivation, and what actually drives performance in yourself and others.

Want the next issues in your inbox? Join the series. Email only, no account required.