How to make your organization attractive to engineering talent

by Jason Swett,

The battle for engineering talent

Virtually everywhere I’ve ever worked has always been desperate for good engineers. The bottleneck has never been “we don’t have enough money to hire as many engineers as we want”, the bottleneck is always on the supply-of-good-engineering-candidates side.

Good engineers of course tend to be not only employed but very well paid and well-taken-care-of in just about every way. It seems like most job ads I see these days tout unlimited PTO, catered meals, etc.—things that I never would have dreamed of when I got my first real programming job in 2005 but that are practically table stakes now.

In order to get a good engineer to leave his or her current well-paid and perked-to-the-max job, you have to offer that person something that’s somehow better.

Most employers completely fail at this though. They don’t offer something better, they offer something that’s basically the exact same. I’ll go into some more detail on what I mean.

The typical (boring) advertised perks

Many programmer job ads I see emphasize things like the following:

  • Competitive salary!
  • Unlimited PTO!
  • Fast growing company! Just raised $82 billion in funding!!!
  • Opportunity to disrupt the waste management industry!
  • Solve interesting technical problems!
  • Catered lunch! Free snacks! Kegerator onsite!
  • Ping pong table! Video game room!
  • Free education budget! Buy all the books and courses you want!

Most of these things are either table stakes in the modern engineering job market or not actually all that attractive.

Table stakes

Things that are table stakes are competitive salary (who would ever admit to offering a non-competitive salary?), unlimited PTO, and things like catered lunch and free snacks. Free food was a special perk at one time but in the engineering talent arms race so many places offer this that it’s not a particularly differentiating perk.

Uninteresting qualities

I’m going to speak for myself on these but I assume my opinions are representative of a lot of engineers.

Funding. I really don’t give a fuck if a company just raised $743 million in venture capital. It’s not like that translates to an above-market salary (and in the unlikely case that it does, say that rather than advertising the funding). I guess it’s nice to know that the company is apparently not on the verge of going out of business, but, “Will I lose my job because my employer goes out of business?” is very low on my list of concerns.

Industry. “Come disrupt the X industry!” is extremely unappealing. What are the chances that I give any fucks at all about whatever mundane industry the business happens to operate in? There are certain industries that I personally won’t work in (e.g. payday lending, network marketing, cat juggling) but that’s pretty much the extent of my caring. Factors like the people I work with, the technologies we use, the methodologies we use, etc., have way more bearing on what the job is like than the industry the job is in. I once worked for a startup in the solar power industry. For a brief time I was pumped to work in an industry I cared about, then I realized that once I got into the actual work it was still all just TPS reports. So much of engineering work is just mundane bugfixes on features I don’t really understand, being done for the benefit of people I’ll never meet. The domain/mission makes only a very tiny difference in what the day-to-day work is like or how fulfilling it is.

“Interesting” technical problems. I don’t buy the “solve interesting technical problems” perk. If I took everywhere I’ve ever worked (10+ full-time jobs and 30+ consulting clients) and made a line graph of the technical interestingness of their problems, the line would be more or less flat. The vast majority of business applications are just a giant ball of TPS reports and aren’t inherently interesting. What is interesting is if the dev team working on an application cares enough to try to make the codebase as convenient and enjoyable to work with as possible. The reason I absolutely love working with Ruby on Rails isn’t because I find CRUD applications “interesting”, it’s because Rails helps take a tedious, repetitive job and make it as convenient as it could imaginably be.

Small expenses covered. Offering a budget for free books and stuff only fools people who don’t take two seconds to think about what the offer really is. If an employer is paying me $150,000 a year, what do I care if they do or don’t cover the $182 a year I’ll spend on technical books? What does make a difference is if the employer will pay for their employees to e.g. go to conferences, and not only tolerate it but encourage it.

Perks of negative value

I’m again speaking for myself, but when I see that a company has a ping-pong table or video game room or whatever, that’s a red flag for me. I don’t want to fuck around and play games during the day and then have to stay late just to work an actual full day. I’m a professional. I like to work with discipline. I want to show up, do my work, and then leave. I don’t want to show up at 8am and leave at 6pm with a bunch of fuck-around time mixed in. I want to show up at 8am and leave at 3pm so I have a contiguous chunk of time to actually do something with myself outside of work. (I also personally don’t want to work a full 8-hour day or even ever go to an office, which is why I choose to be self-employed.)

Job qualities that engineers actually care about

I don’t care about your mission, I don’t care about free Mountain Dew, and I don’t want a ping-pong table anywhere near me while I’m trying to work. Here’s what I care about:

  • Permission and encouragement to do my job right
  • Working with and for smart people
  • Making a good career investment

I’ll address each one of these things individually.

Permission and encouragement to do my job right

There’s a horror story I love to tell about a time when I was forced by my boss to write code in isolation for three solid months without ever deploying anything to production. Because we did it this way instead of using the safer tactic of deploying to production frequently, the giant deployment we did at the end of the three months of course caused problems in production and needed to be rolled back.

As a developer there’s almost nothing worse than being forced to do shitty work. Unfortunately pressure to do shitty work is very common, practically the norm. Developers are always perceived as being “behind” and stakeholders are often pressuring them to cut corners in order to meet desired timelines. So if an employer says no, you have our explicit permission to do your job to the best of your knowledge, then that’s actually relatively unusual and special.

Working with and for smart people

Sturgeon’s law says “ninety percent of everything is crap”. I’ve found this to be somewhat true of developers. Well over half of developers in my experience are not just bad but incompetent. (I don’t mean inside of each team, by the way. Organizations tend to be made up of either mostly good or mostly bad engineers.) For a good developer, working with bad developers is torture. It takes them 5 times as long to do everything, and then they still don’t get it right. I have to live with the consequences of their bad decisions. I have to clean up their messes, or more realistically, live with their messes. And I’m not talking about junior developers (who can be taught), I’m talking about developers who are unfixably stupid. (For example, a former boss of mine who made us do our maintenance work directly on the production server.) There are a lot of these hopelessly bad developers out there. People who have programmed for 20 years and can’t be bothered to crack open a book.

Working with smart developers on the other hand is a delight. Working with smart people makes me smarter. I can make them smarter too. The smarter we all get, the better we can get at our jobs. This translates to a continually more enjoyable and more rewarding work experience. And again, I don’t just mean working with experienced people is better. Working with smart junior developers is a joy as well.

This applies of course both to peers and bosses. Working for a sophisticated boss who just knows what’s up is so much better than working for a boss who doesn’t get it.

Making a good career investment

When I consider any particular job I’m not only thinking of that job but whatever will come next. Engineers change jobs frequently. I don’t think it’s typical or typically expected that an engineer will stay with a particular employer more than a handful of years. So for any prospective job I’ll ask myself: how good of a stepping stone will this job be to the next job? It’s of course not very pleasant for a prospective employer to imagine a prospective employee asking such a question, but I think it’s the reality. Nobody wants to work at a job where all their marketable skills atrophy to the point where they can’t work somewhere else if they want to.

Technologies and practices matter in this area. If I’m considering two different jobs and they seem about equally good but one place uses e.g. the latest version of React and the other place has a creaky old Ember codebase that’s two versions behind the latest release, there’s a good chance the former employer will look more attractive than the latter.

How to get on engineers’ radar screen and get them to seek you out

Most employers have to go out there and find candidates. They have to do outbound marketing. What’s better is if you can do inbound marketing for engineering talent, get engineers to come to you. It’s also helpful if you can increase your organization’s footprint online to the point where if an engineer sees one of your job ads, he or she has heard of your company before and has a favorable opinion of you.

There are a couple organizations that I think do a particularly good job of this: Basecamp and thoughtbot. Basecamp is such a famously desirable place to work that a job opening there has been compared to the issuance of a Wonka golden ticket.

Here are some things practiced by either one or both of Basecamp or thoughtbot:

  • Development of popular developer tools/libraries
  • Popular books written by people who work there
  • A popular engineering-focused blog
  • Appearances by employees in podcasts, magazine articles, etc.
  • Employees who are famous in the development community
  • A modern, professional-looking company website

All of these are within the capabilities of most engineering organizations, all of them would have a positive impact if done with the appropriate degree of commitment, and very few of them are practiced by the average engineer-employing business.

Some of these things are easier than others. Starting a podcast is really easy. I started a podcast myself, The Ruby Testing Podcast. It doesn’t take all that much time or effort. I get to associate myself with “famous” people like Michael Hartl and Ben Orenstein (and their “fame juice” flows to me a little bit just because they came on my show). All I have to do is ask questions.

Writing a book is among the most laborious but also the most effective. In 2014 I took a gig with Andela for WELL below my normal consulting rate at the time. The reason I was willing to do that is because their CTO at the time was Obie Fernandez, who wrote the Ruby on Rails “bible“. Without Obie, there’s no way I would have taken the gig. With Obie, there’s no way I would have turned it down. (Your organization can be associated with a popular book either by having one of your employees write it or by hiring someone who has already written a book. Neither is easy and I’m not sure which one is harder.)

I’ve personally been surprised by how easy it has been for me to make a name for myself in the development industry. A year ago I don’t think anyone knew who I was. As of today I have a popular podcast, a blog that gets pretty good traffic, and I’ve spoken at a handful of conferences. I spoke at RubyConf India in January 2019. Someone there mentioned he listened to my podcast. One guy wanted to take a selfie with me because he apparently considered me famous. Later this year I’m speaking at RailsConf. It’s not all that hard to win these profile-raising opportunities.

If you want to do something to build your organization’s footprint in the engineering community but you’re not sure what, I would recommend considering what’s easiest to maintain and what matches up with your strengths. If your CTO is a good writer but not comfortable speaking, a blog would probably be better than a podcast or conference speaking campaign, and a blog would probably be better than a book because it’s easier. If you find that you can sustain this you can always expand to other tactics later.

The takeaways

Here’s what I hope you take away from this article.

Offering the perks of working with smart people and having permission to do your job right are much rarer and more attractive than the typically-offered perks like free food and ping-pong tables.

You can attract engineering candidates to you by making your organization famous in the development community. A reliable (although not necessarily simple or easy) way to become famous in the development community is to provide value by teaching in the form of speaking and writing.

Relatively speaking, hardly any organizations do these things (podcasting, writing books, etc.), so if you do, you’ll automatically be ahead of your competitors due to the fact that you were the only one to show up.

2 thoughts on “How to make your organization attractive to engineering talent

  1. Pingback: Professional Development – 2019 – Week 9 – Geoff Mazeroff

  2. Julia Hayward

    This whole article resonated so much… Interesting that you mentioned free food. My current employer provides two hot meals a day, plus donuts and cookies at meetings. It’s a trap! With junk food available almost constantly, I put on nearly two stone in my first year there, and am now having to take quite drastic measures to get back into shape. The advantage to the employer is obvious – you arrive early to get free breakfast, you don’t leave the building at lunchtime, and you turn up on time to meetings to get the treats – but unless you have a lot of willpower it’s not going to do you a lot of good (and if you have willpower, the perk isn’t that helpful anyway)


Leave a Reply

Your email address will not be published. Required fields are marked *