The Talent Machine

I wrote down my hiring playbook and it turned out to be massive. I decided to split it in the following 3 chapters:

• The Talent Machine: A predictable recruiting playbook for technical roles.

• Building the pipeline: A sales-driven process for hiring – Coming on November 10th

• Hiring Scaling: Hire hundreds of engineers without dying – Coming on November 14th

The room is packed. Mostly men in their 30s, wearing swag t-shirts and jeans. I'm on stage giving it all, explaining how I helped build a unicorn in Spain, an unusual creature for the local fauna.

I never rehearse my talks. Like a large language model, I generate one token at a time, hoping each will lead to something the audience wants to hear. When it works, it's magic and I feel like a genius. When it doesn't, I look like a complete idiot. A successful idiot, though, since I'm the one standing on stage.

This time around, they nod, laugh, and even clap at the end. I delivered. "Any questions?" I ask. My hands get a bit sweaty but it’s always the same question, and I’m ready for it:

"How do you hire engineers? It's so hard."

Hiring Engineers is a sales job

The best engineers don’t apply for jobs.
They join people who make them believe. So stop waiting, and go sell.

No one – I made it up

There are two ways to approach hiring:

• Buying talent.

• Selling positions.

They sound similar but they are actually the opposite. Companies with a buying mindset typically throw money at the problem. They hire a team of recruiters, pay for job board postings, and optimize for filtering.

In contrast, companies with a selling mindset spend time defining roles as products and positioning them in the market. They proactively look for candidates and engage them in what is, essentially, just a sales process. The emphasis shifts from weeding out “bad” candidates to convincing great ones.

For the rest of this article, I will outline my sales-based recruiting playbook, the one I used to scale a team to 150 engineers in 3 years with only one recruiter. What follows might not all apply to you, but you might learn a thing or two.

Product and Positioning

To find a unique position, you must ignore conventional logic. Conventional logic says you find your concept inside yourself or inside the product. Not true. What you must do is look inside the prospect’s mind.

Al Ries – Positioning: The battle for your mind

The first thing you need to decide is what product you can sell to candidates. This "product" is the overlap between what you need and what candidates want . Essentially, you're defining your value proposition as an employer and it will drive everything else you do.

Ask yourself some key questions about the opportunity you're offering:

• Depth vs. Breadth: Is your engineering work deep (specialized, fewer engineers needed) or shallow (broad, many generalists needed)?

• Location: Where is your team based? Is it in a tech hub or a more remote location?

• Remote Work: What is your stance on remote or hybrid work?

• Diversity & Inclusion: How do you approach building a diverse and inclusive team?

• Work Culture: Do you prioritize work-life balance, or are you a fast-paced mission-driven culture?

• Mission & Impact: Do you have a powerful mission or compelling problem that will inspire candidates?

• Technology Stack: What does your tech stack look like? Modern and exciting, or stable and boring (be honest)?

• Reputation: Are you a known leader in your market?

• Founder/Team: Who are the people behind the company and why are they exciting to work with?

• Compensation: How much can you realistically pay (both salary and other benefits)?

Each of these questions helps define the market you're addressing and sets realistic expectations for your talent pool. Be brutally honest here about what you can offer and where you fall short. If your product is a B2B tool for accountants on a COBOL codebase and you're based in Tbilisi (not exactly a tech magnet), you might need to offer remote work or other perks to expand your reach. On the other hand, if you're curing cancer, working a 4-day week or pay the highest salaries, you can probably get away with murder (figuratively speaking).

As tempting as it is, don’t chase the largest talent pool for the sake of it. Everyone else already does. Instead, look for under-served pockets of talent, groups that match your company’s values or needs but aren’t being courted aggressively.

For example, you could default to mainstream stacks like JavaScript or Python because they have the most developers. But that also means more companies looking for the same candidates. Choosing a more niche technology (say Elixir or Clojure) can narrow the pool but also the competition. You’ll find engineers who are more passionate, loyal, and easier to hire because fewer companies are after them.

At Factorial, the company I founded, I applied the same idea. Most startups were obsessed with hiring 20-something engineers who’d stay late playing ping-pong and drinking beers. I was in my 30s, starting a family, and didn’t want that lifestyle anymore, so I turned it into a hiring advantage. I targeted experienced engineers in their 30s and 40s who wanted stability, flexibility, and purpose. All my messaging, from the cold emails to the interviews would revolve about that positioning, and it paid off: we attracted senior talent early and built a mature, highly productive team very fast.

Once you understand what you can sell and who your market is, write it all down in a Employee Handbook. This is a public doc you’ll share with candidates. It should clearly articulate everything about working at your company. The goal is for the right people to read it and think, "Yeah, this company is for me." Conversely, if someone reads it and thinks "Nope, not my vibe", that's actually good: you've just saved everyone’s time by filtering out a poor fit early.

Compensation

One of the most important parts of positioning your "product" is pricing it correctly. And correctly means setting compensation such that you can attract the talent you need without running out of money.

Engineers will likely be one of the biggest expenses for your company, so you must understand how many engineers you actually need and how much you can afford to pay them. If you're a bootstrapped company, you will know. But if you're VC-funded, be careful: $5M in the bank might look like infinite runway, but at $150k per engineer, that's only 11 engineers for 3 years.

Once you are confident with the numbers, I highly recommend publishing the salary ranges for each role in your Employee Handbook. In fact, I go a step further: Fixed salaries per level, not ranges. Create a dual-track ladder (one for individual contributors, one for managers) with clear levels and a fixed salary at each level, alongside a rubric of what each level means.

But wait, wasn’t the Employee Handbook public? Yes! Having a public document that you can share publicly massively increases your chances of hiring top talent. Candidates will often find a public salary table more fair, even if your numbers are a bit lower than what they could get elsewhere, simply because it's transparent and applies to everyone. Engineers, raised in open-source culture, thrive on transparency and clarity. If you are not clear, or hide information, they will assume you are just bullshitting.

Fixed salaries (no negotiation, no ranges) are a bit unconventional, but in my experience it’s a net positive:

• No Negotiation Dance: Ranges invite negotiation, and many engineers dislike the salary negotiation process. They feel dirty talking about money, like a mercenary instead of a craftsman. By offering a fixed number, you spare candidates the stress and uncertainty.

• Internal Equity: Ranges create pay disparities among peers that can breed resentment. If two engineers perform the same role but one managed to haggle for $5K more, you'll eventually have tension (especially as teams grow and people talk).

• Perceived Fairness: A single number feels less arbitrary than a range. Candidates know exactly where they stand and what the offer is, which many find refreshingly predictable and fair.

• Simplicity: It streamlines the process. You can discuss comp very early and easily (more on that later) since there's a single figure on the table.

Downsides? Sure, a fixed scheme means you might lose a great candidate who has a higher expectation for that level, since you’re not negotiating. That lack of flexibility can seem like a disadvantage. However, I view it differently: if your fixed salaries are truly too low to close good candidates, the answer is not ad-hoc negotiation, it's to raise your salary bands for everyone. In other words, if you’re consistently losing hires due to comp, adjust the fixed numbers upward for that role. But if you’ve done your homework on market rates and you're paying enough (you should!), then money usually won’t be the problem. By removing room for negotiation, you also remove excuses like "we have to pay more to close this hire," which forces everyone to focus on the non-monetary value your company offers.

The “trimodal” nature of software Engineering Salaries

Software engineering compensation has splintered into three distinct tiers in many markets.

Tier 1 represents local companies or startups paying local-market rates, Tier 2 includes well-funded or mid-size companies paying above local averages, and Tier 3 is Big Tech and top-tier firms paying globally competitive packages.

Gergely Orosz – The Pragmatic Engineer

A few years ago, Gergely Orosz famously described how software engineer salaries in Europe had split into a trimodal distribution. They are no longer one bell curve, but three separate peaks for three categories of companies.

• Tier 1: Companies that pay around local market average (often non-tech companies or smaller startups). In the Netherlands, this was something like €50-75K for a senior.

• Tier 2: Companies that pay above local average, competing for talent in-region (e.g. well-funded scale-ups, certain mid-sized tech companies). Senior engineer comp might be €75-125K in that.

• Tier 3: Big Tech and international firms that pay globally competitive rates, often 2-3x what Tier 1 offers (senior packages €125-250K+ in Europe). These are the Googles, Facebooks, Ubers, high-frequency trading firms, etc., who benchmark pay worldwide.

Why does this matter in our context? It’s useful for calibrating your hiring strategy. If you're a Tier 3 company (printing money or have SoftBank on your board), you can chase top 1% (p99) talent with huge offers. But most of us are not in that position. And frankly, if you’re targeting the top 10% (p90) engineers, it doesn’t really matter whether they come from a Tier 1 or Tier 2 company. In my anecdotal experience (don’t be offended, this is just my observation), Tier 3 companies do have some of the absolute best engineers, but on average have the same talent density as the other Tiers. Their sheer size and attractive brand mean they hire a lot of people, not all of whom are geniuses.

So unless you’re able to back a truck of cash up to someone's house, your chances of poaching top talent from Google/Facebook/etc. are rather slim. You’re better off finding excellent engineers in Tier 1 and Tier 2 companies who are perhaps undervalued or looking for a change. Many of the most skilled engineers I’ve hired were “undiscovered” talent at lesser-known companies. Be open-minded and look where no one else is looking. Always be searching for alpha in the hiring market.

Employee lifecycle

Lastly, you need to write down what the employee lifecycle looks like. That's, what happens during the hiring process, the onboarding and promotions. A person willing to join your company needs to know what to expect and will love the transparency effort.

Lastly, as part of your product, you should document the employee lifecycle at your company. From start, to finish. A person considering joining you wants to know what to expect and they will love the transparency effort.

In your Employee Handbook, cover topics such as:

• Hiring process: How many interviews will there be, and who conducts them? What skills or qualities are you evaluating at each step?

• Post-interview: What happens after the interviews? How quickly can candidates expect feedback or a decision?

• Onboarding: What does the first week/30 days/90 days look like for a new hire? What support do you provide to get them up to speed?

• Career progression: How do promotions work at your company? What are the expectations for each level or title, and how can one progress? (This often ties into that dual-track framework you created for salaries.)

• Cadence and culture: What is the rhythm of work? For example, describe the typical company cadence: yearly planning, quarterly goals, monthly all-hands, weekly team rituals, daily stand-ups, etc. Give candidates a sense of the day-to-day and the overall tempo.

Writing all this out for the first time can feel overwhelming. Don’t worry. It doesn’t have to be perfect. The Employee Handbook is a living document and you'll update it as you learn and grow. But trust me, the upfront effort is worth it. All these details and clarity will save you so much time in the long run. Hiring (and then potentially losing people due to wrong expectations) is far more time-consuming and costly than writing a document.

Look for inspiration and read how other companies are doing things. Steal, copy, modify, twist and shout. And do it again, until you find your message and voice.

Here are some examples and resources:

• List of public career frameworks

• List of company handbooks

That’s all for today. The next article is massive, and it explains in excruciating detail the whole recruiting pipeline. Please subscribe to get updates on your email!