Good judgement is three things. Most people test for one.

Here is what people mean when they say someone has "good judgement":

1. They know what matters.
2. They figure things out without being told.
3. They pick the right work when nobody handed them a list.
4. They make decisions when I'm not in the room and I don't have to come back and unwind them.
5. They look at a vague situation and produce something useful.
6. They get it.

Those are six different things. Some are about decision-making under uncertainty. Some are about self-direction. Some are about prioritization. Some are about taste. A few are outcomes of having judgement, not the thing itself.

Ask three people on the same hiring committee what they meant by "good judgement," and you'll get three different answers. Sometimes those answers are compatible. Sometimes one person was vouching for a quick decider and another was vouching for someone who slows down, and both are using the same phrase to mean opposite things. Nobody noticed because nobody asked. It's vibe-hiring.

The bill for not asking comes due months later. If you can't establish a framework for what you mean by judgement, you can't screen for it. You can only evaluate success rate over time. By the time you realize you have a problem, you've invested a lot of energy in someone who was never going to be a good fit.

This matters more in some roles than others. For functions that operate inside an established flowchart, judgement is a nice-to-have. Someone with good judgement can follow the flowchart when it exists, and someone with bad judgement can function fine as long as it holds. The picture changes in early-stage organizations, on new teams inside established ones, or in any role where the work is uncertain, unclear, and gray-area by default. In those places there is no flowchart yet. Judgement is what produces one.

The three pillars

Good judgement, in practice, is the intersection of three things:

1. Prioritization: looking at a situation full of competing paths, separating needs from wants, and knowing what to do now vs later vs never.
2. Motivation: understanding why something matters, to whom, and being willing to drive it without someone standing over you. Feeling ownership and pride in the outcome.
3. Technical skill: the raw chops to actually execute on the choice once it's made, and a wide enough breadth to pattern-match into problems you haven't seen before.

A lot of people have two of these. Some only have one. People with genuinely good judgement have all three.

Hiring when there is no flowchart

When you're hiring into one of those "no flowchart yet" roles, the NASCAR-sticker resume of big logos and prestige brands can hide the open-ended-problem skill you are actually buying for. You're not hiring for the problems you know about today. You're hiring for the problems you haven't thought of yet. That requires someone who can prioritize across an open-ended problem space, stay motivated through the parts that don't have clear wins, and bring enough breadth (a jack-of-all-trades disposition) to grow into whatever the next quarter hands them.

That's what "good judgement" actually means. And once you can name the three pieces, the framework runs on more than just the next hire. Who on your current team is carrying the org forward, and on which pillar? Who's stuck, and on which? Which of your senior people would survive a re-interview against their own scorecard? The same definition that gets you out of vibe-hiring also gets you out of vibe-promoting and vibe-coaching. The phrase loses its grip the moment you can name what it was hiding.

Why these three, and why technical skill is bigger than it sounds

When I've tried surfacing this idea to people in the past, I'm usually met with counterpoints like "they also have to have good communication" or "all you need is empathy." Both objections collapse judgement into a single dimension: a technical skill the candidate either has or doesn't. Communication, empathy, and conflict navigation are all learnable competencies, which is exactly why they live inside the technical pillar, not alongside it.

When I say technical skill I don't mean "hands on the keyboard." I mean any learnable competency the role requires. What a lot of people collapse judgement to is technical skill alone. The framework here is about the meta-skills underneath, which is the part that determines whether a candidate eventually grows into the kind of operator who can handle unclear work.

For example, for a sales engineer: you are looking for someone who can translate complex technical concepts to a wide range of audiences, you also generally want someone who has customer empathy, and a big plus is always someone who can write code. For a designer it's visual design plus user research plus critique-giving. For a manager it's running 1:1s plus written feedback plus delivering hard performance conversations. Communication, empathy, conflict navigation. Those are skills, and skills can be learned with reps, coaching, feedback, etc. That's exactly what puts them in this pillar.

The three pillars are deliberately meta-skills. Prioritization and motivation aren't job-specific. They apply to engineers, salespeople, designers, and everyone alike. Technical skill is the bucket for everything that is job-specific. Pile up all the empathy in the world and you won't compensate for someone who can't prioritize where to put that empathy.

The bozo explosion

People who intuitively have all three pillars are often bad at teaching the skills to others. They may never have had to decompose them. So when they start hiring, they don't really know what they're looking for, and they hire people with two of the three. Those two-of-three hires also can't see what they're missing, so they hire people with one of the three. Talent erodes a layer at a time. This is the bozo explosion you see at a lot of companies.

You can spot the missing pillar in ineffective leaders you've worked with. Some are great at prioritization. Some are even great at motivating the people around them. But do they have the technical skill to win cross-functional buy-in, or to coach someone through a problem they have never personally navigated? They've learned the jargon for prioritization and took a class on motivation, but they don't understand the day-to-day work, so when something falls outside the flow chart, they fumble. Or you have the opposite: the A+ student who became teacher and couldn't figure out how to explain it to others, help them prioritize what to learn and motivate them to learn. Understanding a concept and understanding how to teach a concept are different skills. What made you have good judgement as an IC doesn't necessarily translate to good judgement as a manager.¹

What two-of-three looks like in practice

For an individual contributor, you want all three pillars within their domain.

Take a sales engineer with good judgement:

• Prioritization: they can look across multiple AEs' books of business and identify where things are most stuck.
• Motivation: nobody has to ask them to get involved. They proactively reach out: "these look like hairy problems, let's work on them together." Whether it's commission-driven or team-pride-driven doesn't matter; the self-starting behavior is what you're looking for.
• Technical skill: they can explain the product, design solutions aligned to customer goals, and pattern-match unfamiliar problems back into their core frameworks.²

Three common two-of-three failure modes:

Technical + motivation, no prioritization: the "everywhere" IC. Technically strong, highly proactive, wants to be involved, says yes to everything, included in every account. They're visibly burning out. They feel abused by the volume of requests, because the people piling work on them don't have the judgement to help them prioritize either. The work keeps stacking and they can't see a way out. These people are also often rewarded for this behavior: on the surface they look incredibly high output, and who doesn't love someone producing good output? But they don't get promoted. They don't get trusted with the big problems. They're needed and depended on for everything else, and that's how they get stuck. Most common early in careers, but later-career versions get tagged "junior" or even "immature." We tend to associate prioritization (knowing when to say no, where to put your energy) with seniority, so when someone who's been around long enough to "know better" still can't do it, the gap reads like something they should have closed years ago. That framing is also a trap: it leads managers to conflate seniority with prioritization ability, when the two can develop separately.

Prioritization + motivation, no technical skill: "shit floats." A lot of mid-level managers, or senior leaders where you go "the fuck did they just say?", fit in this bucket. Because we associate prioritization with "strategic," we assume these people will be good leaders. They can say all the right things but have no idea how to put it into practice, so they struggle with the skills that actually move work forward: cross-functional buy-in, accountability, feedback. This will also be a lot of ICs that you describe as "managing up well," but usually as an explanation for why they haven't been fired yet, not as a compliment.

Prioritization + technical skill, no motivation: burnout. People you really appreciate when they talk, but it's usually accompanied by a bad attitude. (If you're reading this and wondering "is he talking about me?" — probably.) If you're an IC and this resonates, try actually looking for a new job, not necessarily to take one, but as a diagnostic. The act of interviewing forces you to articulate what you'd actually prioritize if you were starting over, which can surface whether you already have it in your current role or not. You might realize you don't need to leave. Smart, collaborative teammates? Compensation? Inspiring leaders with a vision? You probably can't get all of them, but you should know what you're optimizing for. If you're a manager and this resonates, your team knows. They sense it and feel it. Same advice. Therapy is also an option.

Managers exist to fill in the gaps

Here's the claim that should shape how you hire and grow managers: a lot of the best senior coaching is prioritization and motivation delivered through technical advice.

When a junior engineer says a senior mentor "changed how I think about my work," trace what actually changed and it is often not the technical content itself. Usually, it was a credible person saying "this is the thing that matters; do that first" (prioritization) and "you're capable of solving this and it'll matter to people who matter to you" (motivation). The technical wrapper made it palatable. The wrapper isn't what landed.

This matters because of a common mistake: assuming the most technically proficient person on the team is the right one to grow everyone else. They can transfer technical skill: they've seen more, they pattern-match faster, that knowledge is real. But technical skill is the easiest of the three pillars to transfer and arguably the least important pillar to optimize for in a manager.

A manager's actual job is to identify, for each person on the team, which of the three pillars they have and which they don't, and then fill in the gap. Back to one of the above examples: an IC who is technically excellent, possibly sharper than you, deeply motivated, no prioritization. Your job is to sit down with their calendar, do the prioritization work with them, and teach them how to do it without you. If technical feedback is the top line thesis of the feedback you give, then you aren't helping them.

The hardest pillar to address is motivation. It's a pure people problem. If someone isn't motivated, all the prioritization frameworks and all the technical chops in the world won't save the output: they'll ship the cheapest patch they can get away with because they don't want to be there. A framework can't resolve this on its own: by the time you've diagnosed a motivation gap, the diagnostic part is over; what's left is the conversation itself, repeatedly, and sometimes a re-role or an exit.

Motivation isn't the same for everyone on your team. The "rah-rah" offsites will work for some and disappoint others. Deep-dive technical workshops will be motivating for some and feel like time-wasting confusion for others.

Motivation is where I'm weakest as a hiring manager. The pattern I've repeated: I'm energized by the hustle-and-grind orientation of sales, so I gravitate toward candidates who exhibit that same energy. What I've missed is that I was testing for my motivation, not theirs. Someone driven by deep craft, or by the collegial puzzle-solving of a team, or by ownership of something they can point to. Those are real motivations that produce excellent output. I've passed on people like that because I couldn't see how to support what they needed, and because their energy didn't mirror mine in the room. Early in building a team that's probably fine. Your first two hires should probably share your operating rhythm. After that it's a liability. You need people whose motivations are different from yours, because the work eventually requires it, and because the team that looks like a clone of the founder stops scaling the moment the founder leaves the room.

Using the framework to diagnose

When you're looking at your team and wondering why the work isn't getting done to the breadth or depth you want, run the checklist on the specific person, project, or org you're stuck on:

• Do they know how to prioritize, and do they understand what the priorities actually are?
• Are they motivated by the work, and do they feel ownership in the outcome?
• Do they have the technical skills the role requires?

If any answer is no, that's where your problem is. The framework works at the person level, the project level, and the org level: same three questions, different scope.

When I have a team member or a senior leader complaining about why things feel "slow," I often use some variation of these three questions and the root cause becomes clear. Generally, it's a mixture of all three, but there is almost always one that is a larger problem than others. Once the cause is established, then you can work on the plan.

Using the framework in interviews

Once you have the three pillars, your interview loop should explicitly target each one. It's especially important because not everyone who participates in the interview will have good judgement. You have to distill this down so that no matter who is doing each stage of the interview, you get all of the signal you need.

Motivation: the "hiring manager / culture fit" interview. You're testing motivation: are they motivated by the mission of the company? Are they self-motivated, or will you be giving pep talks every week? Are they motivated by compensation? By being on a team? Any of those can be fine. You just need to know which one, and whether you can support and foster that motivation.

Technical skill: the technical interview. This is the part most interview loops have practiced for. Here's a problem; can you do the thing.

Prioritization: the part most loops don't even try for. The standard technical interview is narrowly framed on purpose so that there's a clean right answer to evaluate. That setup actively prevents you from observing prioritization. The fix is pretty easy: during the technical interview, change or remove requirements on the fly. People with good judgement will look at what they've already done, look at the overall objective, and give you a clear rationale for what would change and why. People without it will say something like, "I don't think anything would change, I'd still do it all the same way." That answer tells you they see problems as black-and-white: there's one right approach, you either do it or you don't. Very academic. They will struggle in the gray areas where most early-stage work actually lives, because in those areas there often isn't one right answer, and the answer changes as you learn more.

In technical interviews, I find teams often focus on drilling into the why behind technical decisions. There can be some prioritization signals lurking in those questions, but you have to do a lot of interpreting to extrapolate those signals. Why did someone pick Python for their technical takehome? Probably because your job description mentioned Python and they want to demonstrate a technical proficiency in that requirement. You need to get your questions out of litigating technical decisions and more into assessing reasoning. How does this person manage many unknowns, where the path is untrodden, and the right answer is not readily apparent?

The other trap people fall into: they ask "tell me about a time where you juggled many things at once and how you picked what to work on." Every org has a default answer for that. Sales: "I prioritized the account with the highest revenue." Success: "I prioritized the account with the highest revenue." Product: "I prioritized the feature with the most revenue tied to it through our customer feedback process." These are questions that are easily pattern-matched and the "right" answer can be regurgitated and leaves you with no clear signal on how the candidate would perform in practice.

Your hiring scorecard should break down explicitly into the three pillars. For each one, ask the question, then watch for these signals (these are obviously not all of the questions you could ask, just some starter ones):

Motivation

The question: "Tell me about a time you took on something nobody asked you to do."

Good answer: specific incident, the thing they noticed, why it stuck with them, what shipped, what they learned. The reason they reached for it is internal: curiosity, ownership, the work felt undone, they couldn't unsee it.

Bad answer: vague gestures at being "a self-starter," or a story where their manager actually did ask, just informally. The reason they reached for it is external: recognition, promotion, dodging something else.

Red flag: they can't think of one.

Prioritization

I almost always test for this as a key part of the technical interview.

The question: "In your take-home assignment, we gave you a handful of requirements and I like what you were able to pull together. If the instructions had explicitly required X, how would that have changed your approach?"

Good answer: they can articulate how that requirement interacts with the other known requirements, and how the new requirement would have forced them to pay more attention in certain areas than others. They will also make assumptions that allow them to do a soft cost-benefit analysis to understand what they would change.

Bad answer: treats your constraint change as a minor edit ("I'd still do most of it the same way"). They see priorities as a to-do list, not a set of tradeoffs under uncertainty. Bad answers will also often have hard time with "well it depends... on these other competing factors that are also unknown." They may also just word vomit a dozen things they'd add, and they likely aren't bad ideas, but they'll come with no sense of an order.

Red flag: they word vomit a dozen things they'd like to do. If it doesn't come with any sense of order (and if you have to prompt them to order it... that's cheating), then they weren't naturally thinking about prioritization.

Technical

The question: "Talk me through the flowchart of how you got to that answer."

The problem itself doesn't matter much. The signal is in the explanation. You're testing whether they can articulate why the chosen path is right, what they considered and rejected, and what they'd do if a key assumption turned out to be wrong. Landing the right answer is secondary. Articulating the path is primary.

Good answer: out-loud thinking, named tradeoffs, references to similar problems they've handled, comfort saying "I don't know — here's how I'd find out."

Bad answer: silent until they have an answer, no acknowledgment of tradeoffs, defensive when you push on alternatives. Or: textbook recitation with no judgment about which textbook applies here.

Red flag: they get to an answer and can't reconstruct how they got there.

The short version

Good judgement is three things: prioritization (knowing what to do now vs. later vs. never), motivation (driving work without being asked, feeling ownership in the outcome), and technical skill (every learnable competency the role requires: domain chops, communication, empathy, all of it).

Most people have two. The failure modes are consistent: technical + motivation, no prioritization: the "everywhere" IC, always yes, visibly burning out, never promoted. Prioritization + motivation, no technical skill: says the right things, can't actually move work. Prioritization + technical, no motivation: brilliant and checked out.

Talent erodes a pillar at a time. People with all three often struggle to teach what they've never had to decompose, so they hire two-of-three. Two-of-three often hires one-of-three. That's the bozo explosion.

The manager's job is gap diagnosis. For each person: which pillars do they have, and which are missing? Then fill the gap. A lot of senior coaching that lands is prioritization and motivation delivered through technical advice.

Your interview loop probably only tests one pillar. Technical is covered. Motivation gets a culture-fit screen. Prioritization needs its own signal.

None of this makes hiring easy. But it makes it honest. If you can name which pillar is missing, you know what you're actually solving for: whether that's the next hire, a coaching conversation, or some clarity on the manager you're trying to become. "I just don't think they have the judgement" is where the work starts. Three pillars, three questions. Now you have to answer them.