Responsibilities, Roles and Respect
What it means to lead in software development (IMHO)
Developers and programmers are meticulous individuals, and developers sometimes stand out even among themselves.
We introduced you to 7 types of designers in our article 7 Personality Types of Designers Today. Developers have peculiar traits and habits of their own. This article looks at 7 types of developers today and their defining characteristics.
"The best programmers are not marginally better than merely good ones. They are an order of magnitude better, measured by whatever standard: conceptual creativity, speed, ingenuity of design or problem-solving ability."-Randall E. Stross
Stereotyping is generally not good practice. But we're not trying to squeeze individuals into categories. Rather, delineating these types can help you figure out where you stand and help you understand others.
1. The Self-Help Constructor
The self-help constructor does whatever it takes to get the job done with his experience and skill, no matter how limited.
For example, he may accomplish the job by finding open-source software and other free applications and tools. His best assets are his willingness to learn what he needs to complete the job and his ability to absorb the information like a sponge. He is resourceful, working with whatever is available to him.
Not every client will be impressed. Those who don't know any better will praise his work, but the self-help constructor does not develop applications or plug-ins himself.
He merely exploits existing tools to construct something seemingly new for clients. With the wide range of sophisticated tools available today, this is becoming easier, but much less impressive.
2. The Experienced Old Man
He may not be the hippest guy in this energetic and creative field, but the experienced old man brings something valuable to the table: a wealth of knowledge and experience.
He may appear outdated, unable to keep up with the latest tools and technology, but he is wise and knows the basics like the back of his hand.
His battle stories of bygone days will fascinate and thrill. He may not be the fastest or most technologically savvy, but slow and steady wins the race, and he delivers the goods as he always has.
He proves that the old-school style of coding may be antique but isn't extinct. He may not be your heaviest hitter, but in times of great need, you know you can count on the experienced old man to deliver.
3. The Hardcore Geek
Workaholic doesn't begin to describe the hardcore geek, this martyr of developers. He goes beyond the call of duty to deliver the product and takes great pride in his work.
He spends his lunch hour at his desk working frantically to finish the project ahead of time. When he allows himself a little free time, he reads books, journal articles and the like to improve himself. Very much an introvert, he feels most comfortable in the world of code and programming jargon.
The more code the hardcore geek writes, the more content he feels. As great as he is with code, he makes for a much better worker bee than a leader.
4. The Scholarly Know-It-All
The scholarly know-it-all is a walking encyclopedia on programming. He can spend hours passionately discussing the history of a programming language or dissecting imperfect code.
He is the poet of the programming world, whose code is a work of art that can be appreciated and analyzed. Recursion is his middle name, and he tweaks every block of code to perfection, regardless of timelines or readability.
He sets high standards for himself, and his work sometimes complicates matters: a task that should take only an hour to complete takes him a few months. Mind you, he's not incompetent. On the contrary, he is highly capable; but he makes work for himself by creating new tools and libraries and even reconstructing entirely new systems, all to meet his own standards.
He feels obliged to impart his knowledge to others and share his passion for the theory and technical intricacies of coding and programming. He tries his best to explain to clients why using state-of-the-art technology is so important. Every project is his precious child.
The scholarly know-it-all is great to have on your team, but be sure you can get him to spend his energy on the important details, rather than waste time satisfying his urge to delve into every nook and cranny.
5. The Ninja
The ninja is a man of few words and keeps to himself. While similar to the hardcore geek, he has more in his life than code and work.
He is an enigma: not outright friendly or forthcoming, but he works surprisingly well on a team. Everyone notices his tireless nature but can't figure out how he does everything so well and so quickly. There is much evidence of his work but little evidence that he did it. "Show don't tell" describes his modus operandi best.
Never outwardly frazzled (try as you might to throw him off), he resolves problems quickly and efficiently, regardless of time or place. The ninja's stealth sends chills down your spine, and he leaves you wondering how he managed to accomplish his feat.
A lone ranger, he gets the job done regardless of his status on the team or his relationship with other members. His motto? Don't have doubts; just resolve the problem quickly and efficiently. This no-nonsense attitude makes him an absolute joy to work with.
6. The Clever Ambassador
The clever ambassador is the face of the team. He is outspoken and the unofficial project manager. His knowledge of software development, project workflows and code theory is adequate, but he does very little of the actual programming or work.
He is quick to pick up leads and great at communicating with clients. He is the consummate ring-master, able to please both clients (the ferocious lions) and team members (the elephants that could easily trample him if they wanted).
In his supervisory role, the clever ambassador ensures that every project meets the requirements and satisfies the client. He is the go-between, representing the development team for the client and balancing client satisfaction with practicality.
Having to walk this tight rope, he often feels that he should be better compensated, despite never doing any heavy lifting (i.e. coding). He is the model who sits pretty in front of the camera selling the product, while the rest of the team (make-up artists, hair stylists, etc.) works behind the scenes, receiving lower payment for what amounts to the same work.
7. The Half-Cup Speedster
The half-cup speedster takes on multiple projects at once. He works much faster than most, but his amazing quantity is tarnished by its quality: his speed results from cutting corners and hacking core.
He feels that optimizing and checking code takes too long. His code is messy because he does not follow best practices and never makes use of object-oriented programming (OOP).
Amazingly, despite his code looking like a minefield, the product works just as intended. Cutting corners is generally not good practice, but in an impossible crunch, the half-cup speedster might be the person for the job.
Unfortunately, much like the handwriting of physicians, his code is practically indecipherable. Should someone need to fix a problem that surfaces later, they will surely encounter difficulties. You can't fix what you can't read or understand.
Written exclusively for Webdesigner Depot by Aidan Huang, a freelance developer, designer and ingenious blogger. He is one of the editors-in-chief at Onextrapixel. Follow him on Twitter @AidanOXP As we've seen, there are many types of developers in the field. Which do you most closely resemble? Have you met anyone who fits any of the categories mentioned here? Share your thoughts with us in the comments below...
I was a 10x engineer for 7 months and then I was a 0x engineer for a year and a half. You burn the candle at both ends. You end up with alcoholism and depression. You're talking about a very small subset of people. And they might end up in divorce and financial ruin. When people think you're a 10x engineer, they think you have skills that you don't. You invariably let people down.
- Anonymous
Any endeavor to track down the origin of "10x engineer" will end up at Exploratory Experimental Studies Comparing Online and Offline Programming Performanceby Sackman, Erickson and Grant. It was published in 1968. Computers were expensive and slow. Often, programs were written "offline," without the programmer ever touching the computer. Instead, programs were scheduled and run by an operations team to ensure effective resource utilization. Allowing direct interaction of the programmer with the computer was far too expensive. Still, another approach blossomed:
Time-sharing developed out of the realization that while any single user was inefficient, a large group of users together was not. This was due to the pattern of interaction: Typically an individual user entered bursts of information followed by long pauses; but a group of users working at the same time would mean that the pauses of one user would be filled by the activity of the others.- Wikipedia
At the time of this foundational study, a debate raged. Time-sharing allowed programmers more direct access to the computer, but required "expanded hardware and more extensive software." Exploratory Experimental Studies sought to explore the productivity benefits of such an approach despite the increased cost.
The research was conducted with a mere 21 individuals across two studies. Programmer performance in writing two types of program was measured - one, a program to find a route through a 20x20 cell maze; another, to interpret teletype-inserted, algebraic equations. In addition to testing productivity across "online" (direct access to the computer) vs "offline" conditions, the study found large individual variances in the performance of the tasks - "typically by an order of magnitude." As the authors state:
... one poor performer can consume as much time or cost as 5, 10 or 20 good ones. Validated techniques to detect and weed out these poor performers could result in vast savings in time, effort and cost.
And so the mythology of the 10x engineer was born.
The Mythology Grows
The research conducted in Exploratory Experimental Studies Comparing Online and Offline Programming Performance was deeply flawed, as the authors themselves acknowledge in the original paper:
Before drawing any conclusions from the results, consider the scope of the two studies. Each dealt with a small number of subjects - performance measures were marked by large error variance and wide-ranging individual differences, which made statistical inference difficult and risky. The subject skill range was considerable, from programmer trainees in one study to highly experienced research and development programmers in the other. The programming languages included one machine language and two subsets of JOVIAL, a higher order language.... The representativeness of [the problems tested] for programming tasks is unknown.
However, this didn't stop anyone from wildly extrapolating its results, selectively quoting from the paper and carelessly amplifying its tenuous "order of magnitude" message across the tech industry, even years later.
The Mythical Man Month was published in 1975 by Fred Brooks. In many ways, it is a memoir. The memoir of the development OS/360, a batch processing operating system developed by IBM. The book's theme, as many of you will recognize, is that adding manpower to a late software project makes it later.
Here is the epigraph of Chapter 3:
These studies revealed large individual differences between high and low performers, often by an order of magnitude.
Sackman, Erickson and Grant
The author expounds:
Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one.
The myth had now exited an uncertain adolescence, destined for greater things.
The Mythology Becomes Entrenched
In the decades since the original paper, additional studies have been added to the "10x engineer" canon. They, too, are rife with problems and, like the original study, have been heavily criticized. For example:
- Many studies look at highly problematic metrics, such as lines of code or time to find and correct specific bugs in a Fortran program. These metrics aren't neccessarily indicative of true value production or productivity.
- Much of the cited research was conducted in a very different time, in a very different context, leveraging very different technologies and facing very different problems than programmers of 2013.
- The research tends to focus on very specific programming tasks, but is generalized by the culture to overall competency and contribution.
- Many referenced studies were conducted across a relatively small sample size or with poorly controlled conditions that bring into question the accuracy of the results.
Unfortunately, these studies nonetheless get cited extensively in other texts, which themselves get cited in other work, and so and so on. You end up in a self-referential, naval-gazing miasma of bad research, faulty conclusions and acculturated mythologies. For example, let us look at Steve McConnell, who has written extensively on the 10x engineer. Despite leaning heavily on the original 1968 research and other problematic and highly suspect research, McConnell has been quoted everywhere from the vastly popular Coding Horror blog to recent, widely-circulated presentations on scaling engineering organizations.
While an exhaustive critique of all the research in this area is outside the scope of this post...
There is no conclusive body of scientific research to suggest that the 10x engineer is in fact a real phenomenon, much less one that provides us with a deep and actionable understanding of the factors, conditions and stipulations of their existence. Yet we continue to regurgitate the mythology, over and over again.
Why?
The Power of Memes
Perhaps we use "10x" engineer and other variations on the concept - " superlatives", " volatiles," "rockstars", "ninjas" - because they give us a pithy shorthand to describe the very real differences in contribution, value created, and competency in people we've worked with:
The Mythology, Poisoned
The problem is that, just the way the "culture fit" meme covers up many more complex and interrelated factors, so does the "10x" meme erase a number of factors related to situation, culture, experience level, motivation, opportunity for growth, and more. Here's what happens when we use a gross simplification of these complex factors instead of a critical, conscious approach:
- It keeps us from having to specifically define what we actually value in programmers, preventing us from critical reflection on what we need in our teams, companies and community.
Death of a Mythology
The technology industry is full of memes, mythologies and metaphors that give us tools to communicate, to structure the world, to enforce our values, to shape our work and construct the way we see ourselves and our industry. "10x engineer" is one of those mythologies.
By unpacking it, we both see our culture more clearly and are more equipped to intervene in it - asking questions about what we truly value in engineers, what we need in teams and companies to make them succeed, and how we can stop contributing to harmful team and individual dynamics.
For more perspectives on 10x engineers, please see the Twitter conversation that inspired this post. Thanks to everyone who contributed their thoughts and ideas to helping me write this!!
Service Desk Comparative Report
Gartner's recent magic quadrant for IT Service Support Management included no vendors as leaders or innovators. Learn why and how ITinvolve is delivering an innovative service desk solution that empowers IT staff through social collaboration and visualization to improve incident analysis and triage to speed incident resolution time.
Focus on building 10x teams, not on hiring 10x developers
There are a lot of posts out there about identifying and hiring 10x engineers. And a lot of discussion about whether or not these people even exist. At Spool, we've taken a very different approach. We focused on building a 10x team.
We believe that the effort spent trying to hire five 10x developers is better spent building one 10x team.
10x matters because of the Economics of Superstars
The "Economics of Superstars" observes that in some industries, marginally more talented people/groups generate exponentially more value [0]
The Economics of Superstars phenomenon requires a distribution channel to move a large volume of goods. For superstar athletes, television enables endorsements and merchandise sales. For software developers, the Internet enables scalable distribution of digital goods.
Finding a way to be 10x better than median can now generate exponentially more value for people who make digital goods.
In software, the superstar is the team, not the individual
In the Economics of Superstars, if an individual has tremendous control over the outcome (points scored in a basketball game), that individual is the beneficiary. So Kobe gets a big chunk of the value he generates for the team, stadium, and advertisers.
Software development, however, is more like rowing. It's a team sport that requires skill and synchronization. This applies at all scales. On a three-person boat, one person out of sync will stall your boat. As you get bigger, no single developer can impact your team's performance, so again synchronization is key.
Making your team as efficient as possible is what determines long-term success. [1]
A bunch of 10x people != A 10x team
Most hiring processes assume that if you find a great developer and put them on a great team, the individual and team will do well. Good teams try to nail down "culture fit" but this is usually only based on whether the candidate gets along with the team.
Throwing together a bunch of great developers who get along does not make for a 10x team.
How to Think About Building a 10x Team
Building a 10x team is a different task than trying to make an existing team 10x more efficient. The hardest part about building a 10x team is that who you need next is a moving target because it's a function of who is already on the team.
The following are the top three non-technical questions we (Spool) ask ourselves when considering a candidate:
- Does this person extend the team's one strategic advantage? Successful startups do NOT have world class design, engineering, sales, and marketing all at once. They tend to be phenomenal at one thing and competent at the rest. Eventually they upgrade talent for "the rest." For example, Zynga first nailed virality with crappy graphics, then later upgraded their art teams.
-
Is there enough shared culture? - Communication overhead will cripple most teams. Hiring people with a common culture is the simplest way to solve this problem. For example, alums of a university tend to use the same jargon, think similarly, know the same programming languages, etc.. They will communicate naturally and are free to focus on higher order problems. It's not a surprise that Paypal was mostly UIUC, for example. At Spool we've consciously hired mostly Stanford alums because Curtis and I are Stanford grads. Update: I apologize if I gave the impression that we don't value diversity. As you can read in the comments, we've gone out of our way to build a diverse team. But there are many things that don't impact your success early that you can short-circuit by picking people who have a similar enough background. Goldilocks Principle ftw
- Does this person make other people better? A friend once told me that the best hire he made was a mistake. Had he properly screened this candidate's technical ability, he wouldn't have hired the candidate. But it turned out this engineer was so driven that he immediately made everyone else on the team more driven. Just by hiring him, the team became more productive, which far outweighed that individual being an average engineer. It's sometimes worth trading off some technical ability to get a multiplier for your whole team.
What sorts of people make other people better?
When we were building Spool's founding team, we looked for people who were technically solid but especially good at making other people around them better. The following are the types of people we identified that do this. There are probably others.
- The Lead Engineer sets the technical standard. She will conduct the hardest interviews and will generally work technical magic. She will raise everyone's technical bar. This is usually what someone says when they mean 10x developer.
- The Hustler will bend the rules a little when need be, find loopholes in a system, find people you need to find, hack together systems to extract data, and set the standard for just getting things done. She challenges everyone's thinking about how to get things done.
- The Little Engine That Could refuses to lose. She manages to do great things through sheer determination. Sometimes she will tell you about this in an interview, but many times you will need to dig into someone's background to get a read on this. She makes everyone else more driven, focused, and makes them believe great things are possible.
- The Teacher soaks up and disseminates information. A teacher is constantly learning new technologies or synthesizing large amounts of information. She then distills the critical points and actively shares them with others. She makes everyone more productive almost immediately. This adds up tremendously over the years.
- The Anti-Pinochio is willing to call b.s. on anyone, including the CEO. She is great at spotting b.s. and willing to ask questions of anyone. This keeps a team honest and a company transparent. This is different from being an asshole or a heretic.
- The Energizer Bunny throws herself into a task fully and doesn't have an off switch. She gets everyone to give 100% and is so enthused that everyone else becomes enthused. She sets the bar for effort and make everyone want to work harder just so they don't disappoint her. This extends outside work too. She'll be the first person at the party, the last one to leave, and will make everyone have more fun every day. Happy, enthusiastic teams are productive teams.
- The Heart - this is the person on the team that everyone misses when she's not around. She'll bring cookies in for the office, she will remember birthdays, she will make people feel better when they're down, and she will make people do great things because she's just so lovable. People want to come to work to see this person everyday. Just having people look forward to showing up every day is a huge productivity boost.
These personalities all play off each other. For example, a Teacher loves working with an Energizer Bunny because there is someone around to soak up all of that knowledge she shares. Or a Hustler and Lead Engineer can combine to uncover a new distribution channel because they iterate fast and are ruthless. As a result of having these people, you get massive productivity gains from complementary personalities and abilities. Combine these with your favorite/appropriate software development methodologies and you've got a killer team.
I'm sure there are other people who have techniques for building 10x teams. And the dynamics of what makes for a great team are going to be different across industries and stages of company. If you're reading this and have thoughts, please do leave a comment. I'd love to incorporate it into our hiring practices.
Footnotes
Thanks to Curtis Spencer, Christine Tieu, Aditya Koolwal, Chandra Patni, Daniel Witte, Shazad Mohamed, Blake Scholl for reading drafts of this and providing input.
[0] - More on the Economics of SuperstarsFor example, Kobe Bryant is in the 99.999th percentile of ability, while the median NBA player is in the 99.99th percentile. For that small percentile improvement in ability, Kobe Bryant generates millions more in ticket sales, merchandise, concessions, and tv advertising for his team. This pattern repeats every where and is starting to appear with software development teams and startups. If you're good, you can be Facebook, Google, Dropbox, etc. If you're not, you can't get a series A to get off the ground.
[2] - "Crazy" offers from Google/Twitter/Facebook/etc. [1] Evidence building 10x teams matters more than finding 10x individuals
Historically, engineer/product manager/designer salaries have been relatively constrained (red line below). This is because we lacked an efficient distribution mechanism to take advantage of their special talents, so teams had to be very large to achieve scale and no individual could easily have massive impact.
But we are experiencing the beginnings of a world where the Economics of Superstars applies for small 10x teams because a small team can use Internet distribution as leverage. What is really interesting is that retention packages now are not about the individual. They are about keeping 10x teams together. The people who are really getting great retention bonuses are the people who make 10x teams possible. They are either the leaders in a product or engineering organization that know how to build 10x organizations, or they are the employees who make everyone around them better, or they are key employees whose departure would be seen as a signal that the team is no longer a 10x team. These packages are also a defensive move to prevent competitors from acquiring the building blocks that enable 10x teams. Losing key members of a team will result in other members leaving, and will enable the competitor to aggregate a team that operates like a 10x team. It's not about the individual; it's about team dynamics.
Another example from Google is how well they reward great teams and keep them together. Google's Founder Awards disproportionately reward the best teams internally for exceptional accomplishments.
[3] - More on Talent Acquisitions: Talent acquisitions are like record contracts It seems like we're moving to a world where a great team of developers can make $300k+/year each. But not by just walking in the front door - it really messes with team dynamics and manager-employee dynamics to hire people with those sorts of salaries. But rewarding a team and keeping great teams together is much easier to justify.
(This is The Beatles before they were The Beatles) Startups eliminate the guess work that a large organization has in identifying teams with 10x ability. The startup ecosystem is as close to a meritocracy as we have - no bureaucracy, no legal department, no recruiting pipeline, minimal funding required to get started, etc. If a five-person team manages to build something and get any traction, they've accomplished something tremendous.
Identifying startups with 10x teams, is like a scout going through YouTube to find the next great band. If you find raw talent and give it the right platform (publicity, marketing, new instruments), you can turn that talent into something huge. Industries that have recognized their industry operates under the economics of superstars take these bets regularly - think about the English Premiere League, NBA, music industry, film industry, publishing industry, etc. If a bet pays off, you get Ronaldinho or The Beatles. Would you have given the following talented band $1 million/year and have full rights to all of the revenue they generated?
Again, because software is complex and you need teams to execute, the value aggregates in the team, not the individual. You rarely see Google hiring random individuals for $2.5 million over 4 years. Google, Facebook, Twitter, Groupon, etc. are paying to keep teams together and working on the things they've developed expertise in. These acquirers understand that it's about finding 10x teams and giving them the resources of a bigger company. $10 million for four people over 4 years is worth it for many acquirers, because the incoming team has to be marginally better and the result will be exponential value generated for the acquiring company .