Hiring Principles for Engineering Teams ✨

Three hiring strategy ideas for 2025.

Hi everyone! Last week’s article by Charity Majors is already the most popular Refactoring article of all time. You should check it out if you haven’t already: it’s a fantastic manifesto about what it means to create a great team.

One of the topics Charity touched on was hiring, which is exactly what we’ll discuss this week. I should rather say this month, because—brace yourselves—we are about to dive into a three-part series on what it means to hire well in 2025.

This will be a joint-effort by me, a lot of folks from the community, and my friend Dana Lawson, CTO of Netlify. We are going to cover:

1. ✨ Hiring principles for 2025 — that’s today’s piece.

2. 📋 How to write a great job post & onboard engineers well — Dana will jump in on this next week.

3. 📞 How to interview engineers in the age of AI — a deep article with plenty of examples and real-world stories from people in the community.

But why are we doing this? And why now?

There is a famous article by Intercom that says: shipping is your company’s heartbeat. So, if your company is like a body, with a heart — what is hiring in this picture? To me, hiring is probably nutrition. You bring in elements that contribute to your body’s functioning.

(and sometimes you evacuate them 💩)

Just like with real world nutrition, there are multiple diets that lead to different team compositions and sizes, and no real consensus on what’s best. Trending diets have also changed a lot in recent years, influenced by things like Covid, remote, the end of ZIRP, AI, the pushback on DEI, and more.

So, how should you compose your team today, in 2025?

Often times, things are just confusing: should you hire more engineers? Do you really need them? Seniors or juniors? What about managers? Plus a whole herd of elephants in the room: should you hire more women? Is that guy too old to fit your team? And more.

I don’t pretend to have a unifying framework for all of this, but I do have a small set of ideas that have served me well over time, and I will talk about them today. These are:

1. 🏁 Hiring as last resort — from hiring-first to hiring-last.

2. 🪴 Making everyone learn — match everyone’s work to their level of experience.

3. 🎨 Building a diverse team — taking the controversy head-on.

Let’s dive in 👇

---

🏁 Hiring as last resort

When is it the right time to expand your team? What are the signs? If you search online (or talk to people), you often find conflicting advice:

• ⬅️ You should hire early — before problems get too big.

• ➡️ You should hire late — to avoid premature scaling and burning money.

This dilemma is high-stakes, for two reasons:

• Hiring is extremely expensive — both in terms of compensation money, and the time your team needs to spend on it.

• Reverting is hard — firing sucks for everybody, so you want to optimize for doing that as little as possible.

Because of this, I believe in using hiring as a last resort. But last resort with respect to what? Well, it depends on why you are hiring in the first place.

In engineering teams you hire people for one of two reasons (or both): throughput and quality.

🔍 Hiring for quality

You hire for quality when you have a skill gap on something, and it clearly limits growth.

Whatever such skill is, before you hire you may ask yourself:

1. Can you learn it? — can your engineers acquire that skill? Smart people learn faster than we usually account for, and hiring takes a long time anyway.

2. Can you build a first version? — it is rare that you can only bring value with top-quality execution, and prototypes are also useful to educate your taste and better understand what you need.

Do not hire when you are still figuring out what to do. Hire when you have already rolled up your sleeves.

Often times, a combination of (1) and (2) is enough to satisfy (or delay) your need.

📈 Hiring for throughput

You hire for throughput when growth is slowed down by pure bandwidth.

In my experience this is trickier to judge than quality, because most factors that slow down your team do not get better with size — quite the opposite.

Bad developer experience, unclear priorities, confusing org structure, are all systemic diseases that you will not solve by throwing more people at them — you will arguably make them worse.

So, counterintuitively, the best time to hire is when your team is in great shape and firing on all cylinders. If that’s not the case right now, you should probably focus on fixing what doesn’t work first.

Finally, increasing headcount has diminishing returns: adding one engineer adds less than one FTE to your dev resources — and the larger your org, the larger this gap. That’s because the cost of coordination grows more than linearly with respect to your headcount, thanks to Metcalfe’s Law and a bunch of other laws that we don’t need to explain, because everybody has experienced that empirically in the workplace.