Assessing Task-Specific Competence

🧭 Assessing Task-Specific Competence

In the last unit, you saw that good leadership is tuned to the person and the specific task, and that the two classic failures, abandoning a novice or hovering over an expert, both start with a bad read. Now you will go under the hood of that read. Before you can choose the right amount of direction, you have to answer one deceptively simple question: how good is this person at this exact task, right now? This lesson is about answering it with evidence instead of guesswork.

By the end of this lesson, you will have learned to:

  • Judge competence as task-specific, gathering observable evidence instead of leaning on reputation.
  • Run an evidence-seeking check-in that tests experience, judgment, and ability.
  • Separate what a person has proven from what you're only assuming, and catch the halo effect before it fools you.

🔎 Look For Evidence on the Task

It’s natural to let reputation shape how you lead. When someone arrives with a strong track record and glowing references, you may think of them as "a safe pair of hands," so you assume they’ll excel at whatever you give them. But the reverse can happen too. Maybe someone stumbles once, and you keep them on a short leash long after they’ve improved. Both are shortcuts that ignore the crucial truth: competence is not a fixed personality trait; it is task-specific. A brilliant financial analyst may be genuinely new at facilitating a cross-team meeting. A confident presenter may have never built a data model in their life.

What you're actually after is observable evidence of skill and knowledge on the task in front of them. Observable means you could point to it: work they've produced, a decision they made and the reasoning behind it, a walk-through that showed real understanding. Reputation and polish feel like evidence, but they aren't.

The contrast looks like this:

Not observable (reputation, impressions)Observable (evidence you could point to)
"Everyone says she's great.""She built three variance reports last quarter and caught a data error nobody else spotted."
"His last manager called him a safe pair of hands.""He walked me through his approach and anticipated exactly where it would get tricky."
"She's polished and articulate in meetings.""She reconciled the first section by Wednesday so we could both see how it behaved."

The habit to build is to keep asking yourself "What have I actually seen this person do on work like this?" and to notice, without flinching, when the honest answer is "nothing yet."

🗣️ Run an Evidence-Seeking Check-In

When you don't yet have that evidence, you go looking for it rather than filling the gap with a guess. The tool for that is a short, friendly evidence-seeking check-in, and it follows a simple three-part framework: test experience, then judgment, then ability.

  1. Experience. Push past the headline. Instead of "Have you done variance reports?" (which invites a breezy yes), ask them to walk you through a specific past example in concrete detail.
  2. Judgment. Have them walk you through how they'd approach this task; someone who truly knows the work describes a sensible sequence and anticipates where it gets tricky.
  3. Ability. Ask for a small demonstration: a first section, a draft outline, one part reconciled, something concrete you can both look at before the stakes climb.

The Evidence-Seeking Check-In framework: reputation and impressions filtered through three tests, experience then judgment then ability, into observable evidence you can point to.

Let's see this framework in action!

  • Victoria: You've done variance reporting before. Let's start with experience: tell me about the last one you built end to end. What did it pull from?
  • Chris: The most recent one pulled from a clean export, so it was pretty straightforward.
  • Victoria: Good. Now the judgment part: walk me through how you'd approach this month's numbers in our system, step by step.
  • Chris: I'd start the same way, though honestly this system's a bit different. I haven't actually touched it yet.
  • Victoria: That's exactly what I needed to know. Let's test ability with a small piece: reconcile one section by Wednesday so we both see how it behaves.

Notice how the general claim stayed impressive but empty until specific questions turned it into checkable detail, and quietly surfaced the real gap. And notice the tone: curious, not accusatory. You're helping set someone up to succeed, not putting them on trial.

⚖️ Separate What's Proven From What You're Assuming

Once you've gathered what you can, write it down and be strict about sorting it into three piles:

  • Demonstrated capability: the concrete things you've now seen or heard real evidence for.
  • Evidence gaps: parts of the task where you still have no proof either way.
  • Assumptions: the spots where you're filling in the blanks, and where the halo effect quietly does its damage.

The halo effect is the mind's tendency to let one strong impression color everything else. Someone is polished, articulate, well-referenced, so your brain fills in "and therefore competent at this specific task." It feels like knowledge, but it's really a hunch wearing a nice suit. Naming your assumptions as assumptions is what keeps you honest. If the only thing propping up "she can run this report" is her reputation, write that down plainly, because that's the exact gap your next check-in or trial task needs to close.

Competence is a per-task fact you gather evidence for, never a personality trait you infer from someone's reputation. Next, you'll put this to work: first locking in the ideas by completing a short passage on evidence-based assessment, then running an evidence-seeking check-in live where the test is whether your questions stay specific enough to turn confident generalities into something verifiable, and finally writing a short competence read that separates what's proven from what you're still assuming.

Sign up

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal