The “10x engineer” is a lead in the cast of characters for prevailing Silicon Valley mythos. Get a team of them and you could create the next billion dollar company. When WhatsApp was acquired it had 450 million monthly users, but just 32 engineers. Facebook acquired only 13 engineers when it bought Instagram for a tidy one billion. HBO’s Silicon Valley follows a group of coders who work around the clock, fueled only by coffee and occasional genius.
For every leader that swears their team was saved by a 10x’er, another will say it’s bullshit. These naysayers will point out that even if a 10x’er writes more code than everyone else, it doesn’t help if the rest of the team has to rewrite it; or, it’s not helpful when a 10x’er is adamantly against writing in a particular language, like Java.
Former Pivot Parker Thompson is a partner at AngelList, where he advises startups on scaling their team and products. Using his pseudonym Twitter account, Startup L. Jackson, he has been a vocal advocate for 10x’ing your team over finding a 10x engineer.
11 Pivotal Lessons From @StartupLJackson
We sat down with Thompson to talk about the notion of 10x engineers, how to build a great engineering team and what the future holds for engineers.
Where do stealth start-ups run into problems?
PT: When you start a startup and you’re at the beginning, the existential crisis is not that you’ll build a good engineering team, it’s that no one wants what you’re making. When you’re trying to figure out if someone wants what you’re building, you really only need a very, very small team, generally speaking.
Once you realize you have something people want to buy, you then have to hire 30 engineers to really build upon the product as quickly as possible. It’s at this point there’s sort of the technical processes and communication processes that a company needs to address. Who do you hire? How do you organize them? What do you do on a day to day basis in terms of building out this product?
Some employers believe your engineering team’s success can be led by a “10x engineer,” rather than a whole team. What are your thoughts on this notion?
PT: These engineers look highly productive and make everyone else look like they suck, but it’s often actually the opposite in practice. They are the ones that end up committing a bunch of bad code in the middle of the night, perceiving themselves as the heroes. Meanwhile, the rest of the team has to clean up or work around their code, so it looks like they’re less productive. Oftentimes non-technical management, including CEOs, will reward this behavior, this dynamic. I think that’s actually a common failure pattern in startup businesses. Managers, and especially non-technical leaders can make sure they’re optimizing for team productivity by collecting data on team performance from all members of the team and rewarding team-oriented behavior.
Why is this dynamic problematic?
PT: Your unit of productivity is a team. You have these 30 people, you need to maximize their output across this broad set of people, and often these “10x people,” particularly those that perceive themselves as superstars, they’re actually counter to your business’ goals.
Why do you think that idea of the 10x developer is so romanticized in our culture and industry?
PT: Because managing engineering teams is incredibly hard. It’s much easier to think about hiring a few “10x” engineers than it is to think about designing processes that create 10x teams. Even the concept of management is considered uncool in startups, synonymous with big company bureaucracy.
I think as well that because so many companies succeed in spite of never getting great at building good process, there are a lot of veterans of successful startups who have learned bad lessons and take those to the next company.
How do you advise executive management to build a “10x team”?
PT: There are three roles in a product team: design, engineering and product management. It’s important to consider two questions before you grow your team: first, who is responsible for each distinct role and second, how are these people are going to communicate. This is critical for building a 10x team.
One mistake I often see is that management only values one of these roles, like engineering. It’s usually engineering versus product or design, and management is thinking, “We’re going to have engineers do product management.” But then they don’t acknowledge that actually takes additional time. They don’t have the engineers talk to customers or attend product meetings because, in their mind, “all they should be focused on is writing code.” Then these engineers are asked to make decisions that, because they’re not in these meetings or talking to customers, they’re more likely to make a bad choice about.
You can have a great engine and a bad rudder and the boat ends up in the wrong place very quickly.
Another problem, particularly as you scale, is around communication. If you have great product managers, great designers and great developers, but they’re not actually talking to one another — you end up with very inefficient development. Instead, you’re just iterating slowly because these teams don’t like each other. This is very much a problem that extreme programming and natural development was intended to solve in large organizations, but it exists within small teams, as well. It’s important to find a way to build in place of processes, which should be as lightweight as possible, but still allow you to have a functional team with divisions of labor.
You can have a great engine and a bad rudder and the boat ends up in the wrong place very quickly.
What values do you believe developers should have to be successful now and in the future?
PT: I think there are two types of engineers: gadget people and craftspeople. Gadget people always want to be using the latest thing and that can be a big tax on your company. They’re also people who are religious about technology, saying things like, “I’m a Ruby person,” or “I’m a Java person.” As opposed to a problem-oriented people, whose interest are more about the solutions than the technologies. These people are craftspeople interested in their particular skillset, whether be it engineering, product, or design, and are focused on honing their craft. If you take these people and you put them in a team of people like them, you tend to find solutions emerge. Generally speaking, if you have people that are good at collaboration, who are curious about the right ways to build code, that’s what’s important.
When you’re trying to hire quickly, what do you view as standing in the way of building talent pools in cities outside of San Francisco, Silicon Valley, and New York — or what some people call, “talent deserts?”
PT: The problem for startups, specifically, is that when you want to hire 1,000 people in three years, there are very few places that you can do that. That means that startups have to build their companies in places where talent already exists. That’s not just San Francisco or New York, but it’s also not Topeka, Kansas — not to pick on Topeka, Kansas. It’s not realistic to think that some of these companies that require thousands and thousands of specialized employees are going to just magically spring up in places where that talent doesn’t already exist.
Your Talent Drought is Your Fault
I’m optimistic that there’s going to be an diffusion of innovation outside of Silicon Valley and New York, but I think it will happen in these larger cities where there’s already tech talent, but there may just not be a culture of high-growth startups. I think that cultural problem is very solvable versus the talent problem.
What do you consider common sense about diversity in hiring?
PT: Most people would say, “Yeah, in principle I think diversity makes sense, but I don’t have time to prioritize it now.” If you don’t think about these things early on, then they are and will continue to be a problem. It behooves any business to think about their diversity strategy from day one.
Companies need to understand that if they wait too long to think about building inclusive teams, this becomes an intractable problem.
If you start off two white guys, each additional white guy you hire is going to make it harder to hire that first “diverse” candidate. They walk in and see your team, and you can’t blame someone for not wanting to be the first woman or minority employee in a monoculture that is implicitly exclusive of them. Companies need to understand that if they wait too long to think about building inclusive teams, this becomes an intractable problem.
As well, to make an analogy to code and the Pivotal Way, I think there’s an implicit assumption in engineering that writing good code takes too much time; startups need speed. In reality, you don’t have time to write bad code because it slows you down, and not just way out in the distant future. I think the same is true for hiring for diversity. You can’t afford to not think about it early, because these problems show up sooner than you might think, and this cultural debt only gets harder to pay down the longer you wait.
Practically speaking, I try to give companies two pieces of advice: get buy-in from your team that you need to build a diverse team to attract the best talent, and build a pipeline of diverse candidates so you’re seeing A+ people with diverse backgrounds for every role. I think if you do that, you’re not done, but you’ve set yourself up for success.
What’s the one thing you’d impart on leaders trying to build a 10x team?
PT: I think you’ve just got to understand what work needs to be done and properly assess your team. “Do we have good product management? Do we have good engineering? Do we have design? Who’s doing this work? Are we empowering them to be successful in the things that we’ve tasked them with, and then are we getting the team to work together well?” That broadly encompasses everything from communication to making sure we don’t have any assholes on the team that make it hard to work together. I don’t think it’s one thing, but those are sort of the questions that I think about.
This is the second part in a series, Developers at Work, exploring the changing role of developers in today’s workplace.
10x-ing Your Team: The End of Superstar Developer Culture was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
