Hiring

Hiring

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it.

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

---

How to Use This Skill

Identify the situation first:

• Structuring the interview or deciding on a work sample → See the Work Before You Hire
• Calibrating seniority level / case for hiring juniors → Why You Should Hire Juniors
• Worried about cultural bias affecting the evaluation → The Beer Test Bias
• Deciding between internal promotion and external hire for a management role → Internal vs. External
• New hire isn't meeting expectations — wondering if you should act → Setting Up New Hires for Objective Evaluation

---

Default Response Shape

When helping with hiring, turn the advice into a hiring artifact:

1. Hiring goal: what problem this role or hire must solve.
2. Bar / evidence: what evidence should prove the candidate can do it.
3. Process: interview loop, work sample, debrief, or 30/60/90 plan.
4. Bias check: where the decision may be distorted by similarity, urgency, or sunk cost.
5. Decision language: concise recommendation: hire, reject, calibrate, or gather more evidence.

For new-hire concerns, shift from candidate evaluation to objective 30/60/90 success criteria.

---

Setting Up New Hires for Objective Evaluation

The most common new manager mistake is tolerating underperformers because they're improving. The fix starts on day one.

Define success in advance. Before the person starts, write down concrete expectations:

• How long before they can complete a task in repo X without help?
• What type and size of tasks do you expect at 30 / 60 / 90 days?
• When should they be contributing to on-call? To technical design?
• For senior hires: what inputs and initiative do you expect from them?

Without this, you'll drift toward forgiveness. A small improvement will feel like success because you have no anchoring standard.

Use the "would I hire today?" checkpoint. At 30 days (and again at 60 and 90), ask yourself one question: "Knowing what I know now, would I hire this person?"

• If yes: tell them. It builds real commitment.
• If no: act. Every day you wait, you're doing more damage to the team — and to them.
• If "I need more time": be honest with yourself. You usually know by 30 days. 3 months is almost always enough.

Don't ask "am I better with or without them?" That question anchors on sunk cost — the training time, the relationship, the hassle of re-hiring. Ask the forward-looking question instead.

---

Why You Should Hire Juniors

Most companies have an excuse not to hire juniors — too small to mentor, growing too fast, infrastructure too complex. Most of it is bullshit.

Ambition, character, and brains have little to do with experience. Some developers become seniors in under 3 years. There are diminishing returns on experience: you can tell the difference between 1 year and 5 years; between 10 and 15, probably not.

5 reasons to hire a great junior for the next open position

1. Bigger candidate pool. When you need "full-stack with 5+ years Python and 3+ years React," you'll have fewer options and may end up compromising. Broader criteria means access to absolute top talent.

2. Fresh energy. Juniors want to learn and have a drive to prove themselves. Their motivation is contagious. Seniors on the team enjoy working with smart, motivated people — and get opportunities to mentor, which they might miss on an all-senior team.

3. Not restricted by what they know. They won't try to reuse the same technologies or patterns from previous companies. They approach problems without baggage.

4. More flexible. More open to new technologies and less picky about tasks. Doesn't mean assigning them only annoying bugs — but it gives you more flexibility.

5. Easier to develop. Great juniors want feedback and seek to improve. They want to know what you think about their work.

The internship advantage

Juniors often come through student or intern positions. This means you can judge their skill before offering a full-time role — a privilege you never have with senior hires.

The river, not the lake

Think of your team as a river instead of a lake. A lake stagnates — it cultivates mediocrity and complacency. A river is always running and changing, with great energy. A river depends on the flow of people: new blood, new leaders, elders ready for a new challenge. If you never hire juniors, your team stagnates.

Pay based on skills, not tenure

The point of hiring juniors is not to have rotating cheap labor. Paying juniors less initially makes sense — you're investing time and energy training them. But once great juniors prove themselves (often within a year), pay them based on their skills, not their years of experience. Otherwise they'll go get mid/senior roles at other companies, and rightly so.

When you do need a senior

Sometimes you need a specific level of expertise: building an iOS app for the first time, solving performance problems at scale, navigating a genuinely complex domain. For those cases, hire a senior. For most teams working on a standard SaaS product, the junior/senior ratio can be quite high.

---