Free — no signup required

The Five Stages of Skill Acquisition

4 min read

The Dreyfus Model defines five distinct stages of development. Critically, these stages are skill-specific, not person-specific. A Staff Engineer can be an Expert in distributed systems design and a Novice in Kubernetes networking. A junior developer can be Proficient in SQL and a Novice in CI/CD pipelines. Never conflate a person's overall seniority with their stage in any particular domain.

Stage 1: Novice — The Rule Follower

A Novice has no prior experience in the domain. They cannot distinguish relevant information from irrelevant information, so they need context-free rules that apply regardless of situation.

  • Characteristics: Wants to be told exactly what to do. "Just give me the command." Paralyzed by ambiguity. Cannot prioritize competing concerns.
  • Needs: Strict recipes, numbered checklists, and immediate feedback on whether they did it right.
  • Effective management: "Run kubectl rollout status deployment/api-server. If the output says successfully rolled out, you're done. If you see anything else, stop and message me immediately."

The Novice is not failing — they are operating correctly for their stage. The failure is the manager's if they assign open-ended tasks to someone who needs a recipe.

Stage 2: Advanced Beginner — The Troubleshooter

The Advanced Beginner has seen enough situations to start recognizing patterns. "I've seen this error before." They can handle minor deviations from the script but still struggle to separate the signal from the noise when things go wrong in unfamiliar ways.

  • Characteristics: Can follow guidelines, not just rules. Starts to notice situational context but cannot yet weigh it correctly. May fixate on the wrong problem.
  • Needs: Guidelines with some flexibility. Help prioritizing when multiple things are wrong simultaneously.
  • Effective management: "Here is the runbook. You can skip step 3 if the health check already passed. If you hit an error you haven't seen before, don't guess — escalate."

Stage 3: Competent — The Planner

The Competent engineer can troubleshoot independently and build a plan to solve a problem from scratch. This is the first stage where emotional investment appears: they feel genuine responsibility for outcomes. When they succeed, they feel proud. When they fail, they feel bad — not just inconvenienced.

  • Characteristics: Can decompose a problem into steps. Chooses a deliberate approach. Feels ownership. May be slower than an Expert because they are consciously reasoning through each decision.
  • Needs: Goals and autonomy to choose the method. Review of their plan before execution.
  • Effective management: "We need to migrate the billing database to the new schema with zero downtime. Write me a migration plan — what you'll do, in what order, and how you'll roll back if something goes wrong. I'll review it before you start."

The Competent stage is where many engineers plateau. They are productive and reliable, but they haven't yet developed the holistic pattern recognition that characterizes the next two stages.

Stage 4: Proficient — The Big Picture Thinker

The Proficient engineer sees the system as a whole. They can judge when a rule should be broken. They prioritize based on maximum impact rather than following a fixed sequence. They notice when something is "off" even before they can articulate why.

  • Characteristics: Holistic situational awareness. Can recognize when the standard approach won't work. Learns effectively from case studies and post-mortems. Prioritizes instinctively.
  • Needs: Complex, ambiguous problems. Exposure to diverse failure modes. High-level case studies.
  • Effective management: "The database is slow and it's affecting checkout. Fix it." No plan required — they'll figure out the right approach.

Stage 5: Expert — The Intuitive

The Expert operates primarily on tacit knowledge — knowledge so deeply internalized that it cannot be fully articulated. They don't consciously decide; they perceive the right action directly. If you ask an Expert why they restarted a specific pod, they might say "it felt sluggish" or "something about the memory pattern looked wrong." They are usually right, and they often cannot give you a better explanation than that.

  • Characteristics: Intuitive, pattern-driven decision-making. Generates new rules rather than following existing ones. May struggle to explain their reasoning to Novices. Operates fluidly across contexts.
  • Needs: Freedom, strategic-level problems, and the ability to shape the environment. Being forced to follow rigid checklists is actively harmful to their effectiveness.
  • Effective management: "What should our infrastructure strategy look like over the next two years? What are we getting wrong?" Then get out of the way.
Interview Tip

A common Staff Engineer interview question is: "How do you scale your own knowledge across a team?" The Dreyfus-aware answer is: recognize that Experts are the source of new rules and patterns, but they make poor direct teachers for Novices because they've forgotten the rules they internalized. The solution is structured knowledge transfer — having Experts work with Competent engineers who can translate tacit knowledge into explicit documentation.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free