How Great Projects Attract Talent

A friend of mine just acquired a great developer for his machine learning startup. He didn’t even promise a big salary. It still worked.

This is why the developer joined:

This job seems challenging. Right now, I don’t know how I can solve this.
I would like to figure it out.

People love challenges, but that’s not all. There are certain things you can get right in a project to acquire and retain great talent.

I used these principles to hire 30+ developers for my companies. Nothing here is wizardry, just some simple steps everyone can replicate.

First: what does not work

Many projects are boring. And many people only work to receive the next paycheck. There are a couple of things companies do. They think perks and goodies work. For example:

I spoke to someone who built a warehouse. According to him, warehouse workers were really happy to receive t-shirts once in a while. Also they treated them with cookies and food around Christmas time.

That idea might be a nice detail, but it won’t move great talent.

In fact, if small details are sprinkled on top of failed recognition of hard work, it can backfire, as this TikToker pointed out:

Calling your employees “family” always leaves a bad taste. But what about the other details? For any other perk: The foundations need to be right before anything works.

Why doesn’t it work?

Because it’s only a bonus, not an integral factor of the developer’s satisfaction and, thus: retention.

You can actually think of this as a formula.

Each factor is between 0 and 10. DR as in developer retention.

DR = challenge * salary * people * autonomy + perks

You get the idea. If any factor is 0, the whole formula won’t be high. But if you get all the foundations right, the perks almost don’t matter.

A challenge

Some examples of challenges:

Scaling: The servers break under a load. It’s a complex problem. You touch one aspect and the whole system behaves differently when hit with thousands/millions of users.

Security: Building a system that’s hack-proof. How can you ensure it has a super small attach vector?

Time to market: Build up a new product in as little time as possible. Many devs love this.

Complexity: Building a system that serves many different stake holders, and does so securely. (Not many people get motivated by this, but some)

Beauty/UX: Build an app that people love to use. This only works if you have a great designer on your team.

Chores are not challenges

And a codebase can quickly become a chore if it’s not healthy. Developers hate it if something is not maintained well:

Your code coverage is my percentage to be interested in your offer

That’s a real response an acquaintance of mine gives to recruiters. Every time they try to poach him from his current job, he responds with this line.

Usually they don’t have the answer, if they even understand it.

Why is great test coverage important?

Good developers hate sloppiness. And having not enough tests only tells them about the culture:

• Micromanagement (devs don’t care about getting it right because they never have the time for it)
• No time for tests (Managers don’t have enough power over POs/product people)
• A buggy application (Your job will be fixing the software, not making something new)

Acceptable salary

This can be a touchy subject. My understanding of this is limited to where I hired, and I’m sure there are many better articles written about this (e.g. by Joel Spolsky)

Most importantly, for developers, it’s this: the salary should be so high that they don’t have to worry about life expenses.

Developers have a high status nowadays. If you look at the Maslow’s pyramid of basic needs, you’ll see that a highly paying job usually solves the first two layers of the pyramid. Your salary should always make sure these two layers are covered.

But I’ll give you another angle. Maybe you are a startup founder and budget is tight. You might want to hire a junior, and that’s totally fine (if you are aware of the drawbacks).

Especially if you work with juniors: you want them to focus on their craft. A junior who works another side job to make ends meet is not going to get the learning time they need.

Conclusion: best to pay people market rate. If you are reading this, you should already know the market rate. If not, feel free to jump on a call with me to share experience.

Working with smart people

Imagine the story “Lord of the rings” but every Hobbit is a coward, doesn’t help others, and tries to look good in front of Frodo. Nobody would like to read this story, right?

Same with software teams: it’s about comradery.

A team should provide a couple of things:

• You can learn from them
• They understand you
• Others have your back
• You don’t feel judged
• They appreciate your contribution

With developers, the first point is often neglected.

Too often young developers get to manage teams too early. Too much responsibility and too little learning.

The book “Rapid Development: Taming Wild Software Schedules” by Steve McConnell describes it well:

“Compared to the general population, developers are much more motivated by the possibility for growth, personal life, the opportunity for technical supervision, and interpersonal relations with their peers. Developers are much less motivated by status, interpersonal relationships with subordinates, responsibility, and recognition.”

Freedom + Autonomy = Having time to focus + explore

Research by project manager Rob Thomsett found this:

“Two large studies have found the most common personality type for software developers is ISTJ, a personality type that tends to be serious and quiet, practical, orderly, logical, and successful through concentration and thoroughness.”

Developers need time to concentrate

And that’s true, especially for introverts. My old co-founder of my first software company often said this:

I just want to code relaxedly

Back then, it didn’t make sense to me. Of course it didn’t, I’m an extrovert. It took me time to understand this. Now I let people do their work in quiet and don’t constantly ping them in our teamwork.

But there’s more:

Autonomy is a basic human need

Giving someone a situation that they have no control over is a recipe for burnout.

I experienced it myself. Once, I had to handle two projects. I put 4h into one project, and 4 into another daily. The burnout was not caused by the workload.

The burnout was caused by one project swallowing up all 4h in meetings. There was no time to do any real work.

I didn’t seel like I had any autonomy here. No control to influence the project.

Autonomy is paramount in people’s motivation, and it’s especially true for engineers. Dan Pink has a good TED talk on the topic:

If you want engagement: self-direction works better.

The video doesn’t show a thumbnail, but if you click it, it’ll work:

Conclusion: Your project cheat sheet

You’ll do well if you only do a few things:

• ✅ Have software that’s challenging
• ✅ Pay people well
• ✅ Pair them up with other smart people
• ✅ Have them solve problems on their own terms

Do you agree with this? Send me an email!