Over the past 9 years, we’ve seen a massive increase in the number of startups here in NYC. Every major tech company has an office here, the Google office alone has thousands of engineers. We’ve also seen an increase in the supply of engineers. Between students realizing the value of a tech degree, people changing careers, and bootcamps rapidly churning out graduates, the mix of types of people who write software has changed. Most of the people I knew writing software in 2007 had tech or tech-adjacent (math, physics) degrees. My team when I left Rent the Runway had a significant number of developers who had moved into tech from other areas, some without degrees at all.
All of this is to say, playing to 2007 nerd stereotypes is not always a good way to build a team here in NYC. What DO engineers want? I believe that you have 3 axes with which to twiddle. Depending on your company, you can lean more on one to cover problems with the others, but you have to find your balance.
Money. Joel hides this at the bottom of his piece. It is correct to say that engineers don’t care about money above all else, but far too many people delude themselves into thinking that this means that you can lag industry standard salaries and build a good team on the basis of some other factor.
Salaries have gone way up in the past 10 years. People know that they can get paid a certain amount of money, and if you try to hire people who can easily make 50% more somewhere else, they are almost certainly not going to accept your offer. Figure out what the market spread is. The top will be companies like Google, Facebook, some financial companies. The bottom might be non-profits or extremely early startups with significant equity grants. Even a startup with 10–20 people is going to struggle to hire without paying close to market rate. Engineers are expensive. New engineers are expensive. Senior engineers are really expensive. They know their value. You have to pay them.
You are building a company. You are not going to have a perfect, smooth ride. Things will go well, things will go poorly. Very few teams have a straight shot to greatness that is so clear it can cover all management woes. When you don’t pay people well enough, you contribute to undermining their resilience in the face of problems at work. Think of it as the baseline of Maslow’s Hierarchy. Money does not solve all problems for most people, but lack of money exacerbates all irritations.
Purpose. You’re building a company. You want to inspire people to work for you, so you sell them on the mission of the company, the product they’ll be working on. You have to do this because you are not building a company with a bunch of insanely hard tech problems. If you are, you can lean on that to hire people, but to be real, these days most of us are not. The days when everyone had hard technical scaling problems have ended. Scaling is not the same bold new frontier that it was even 5 years ago. Sure, there are always technical challenges to be found in organizations, but for many companies those technical challenges revolve around matching technology with the product and business. This means you have to work harder to sell the learning opportunities.
Leadership undermines their teams when they refuse to let engineers into the non-technical decision-making processes. In Joel’s article he talks about developers wanting to be allowed to make decisions within their own realm of expertise, which is certainly a bare minimum. I would encourage you to go further than that. If you are building a product-focused business, where the challenges are less purely technical and more about engaging a customer, your engineers need to feel connection to that business. They need to feel like they understand it, like they can have ideas about it. This is why I’m such an advocate for cross-functional product development teams. Put engineering, product management, marketing, operations together as a group and let them work as a team to solve problems. Don’t just throw work over the wall to engineering and expect them to implement it.
Respect. The undercurrent that I like least in Joel’s piece is the undercurrent that engineers need to be coddled and pampered. Giving them “toys” instead of “tools,” keeping them out of the politics. There are plenty of engineers who want to be given hard work to do and left alone, in their private offices, to think and code. But there are increasingly more engineers who want to build businesses, and they want to be treated like adults in the process.
Our engineering teams are not overgrown children. They are not idiot-savants who can produce software but must be given sufficient cookies to do so. They are highly paid professionals. Let’s treat them that way. You should expect your engineers to show up for your business. Respect is not pampering, it is not treating the team like the stars of the show. Rather, respect is challenging the team to show up and grow up. Respect is giving them clear, achievable goals and holding them accountable. My experience has been that most great engineers want to work somewhere that inspires them to achieve. Many of us stop at the idea of “hard technical problem” when we think about inspiring our engineering teams, but challenging them to partner with people who have different perspectives is another way you can help them grow.
Respect that engineers are smart individuals who often have more to add to your business than just their coding talents, and teach them to respect that the other parts of the business have equally valuable skills and perspectives. Engineers don’t need to feel like the company royalty to be inspired to do good work, but they do need the opportunity to be treated like a partner.
These days, you have a lot of competition for talent, but you also have a lot of talent to choose from. Understand your company’s positioning. If you can’t pay top of market, you will have to rely on a balance of finding undeveloped talent and giving engineers other reasons to want to work for your company. For most of us, that means giving them a voice beyond the purely technical, and challenging them to see and understand perspectives outside of engineering.
Post a Comment
Note: Only a member of this blog may post a comment.