In a perfect world, we'd enjoy teams bursting with natural leaders, self-driven individuals who can handle any situation under any degree of pressure, identify and prioritize the tasks, assign and delegate said tasks, encouraging and mentoring each other, until the team jells with profound efficiency.
In the real world, there are plenty of teams adept at software construction that produce amazing creations and are comprised of developers that possess absolutely zero interest in becoming leaders. Nor is it necessary.
In order to get to the bottom of this, you're going to need to know the secret ingredient:
Band-aids.
Gaining proficiency in a trade is a result of either:
What does this have to do with a 10x developer not being the same thing as a leader? Read on!
Conversely, the reason why people go awkwardly silent on a conference call...does not. Pluralistic Ignorance is in the lexicon of sociologists, not technologists (and likewise, I don't expect many sociologists to know what a Non-Clustered Index is!)
A programmer that is self-driven, motivated, passionate, and cares deeply about what they do is going to spend time becoming more proficient at their craft. And that is really what we're saying when we describe a 10x developer: they are a developer that demonstrates an expert ability at sussing out technological root causes and applying technological fixes, as compared to their peers.
But the root causes (and subsequent fixes) for sociological issues require a different school of thought, training, education, and practice to employ. It is an entirely different industry altogether. Sure, there's a little bit of crossover in the Venn Diagram where technology and sociology meet...
...but it is slim.
And let's not forget why some people got into technology in the first place: because their love was of technology and not of sociology.
The science of human interaction is (unlike code) one of the grayest areas of science, the most hotly debated when interpreted by academia (when their experiments can reproduced!) and perhaps the most difficult to apply solutions to (And if you disagree, perhaps we should invite a Psychiatrist and/or Psychologist into the conversation).
In other words: getting human interaction right is one of the most difficult, most complex skills to master.
Let's Review
Can we agree that a 10x developer demonstrates measurable proficiency at their craft?
And can we agree that one of the key attributes of measurable proficiency is expertise?
And can we also agree that the ability to identify root causes and assess appropriate solutions requires said expertise in their field?
And (deep breath) can we agree that technological problems and sociological problems are of two different sides to a Venn Diagram?
If we can agree, then I ask you...
Is it wrong to ask a technologist to explore the basics of human interaction, to become at least moderately literate at how best to be part of a team?
Not at all. Perfectly acceptable, in fact.
And by learning about/employing the bare minimum when it comes to human interaction...is this the key to transforming a mediocre developer into one that measurably outperforms their peers?
I don't see how it possibly could.
But when we ask for moderate literacy in sociology, that's what we're asking:
Hey. Socially awkward programmer over there. I know it might pain you to step outside your comfort zone, but we'd appreciate it if you knew the bare minimum when it comes to interacting with your fellow teammates.
How is that any different than going to a database administrator and asking:
Hey. Database guy. I don't know why the database is crashing every 15 minutes, but go ahead and reboot the server and let's carry on with the day.
I'm sorry to have to be the one to say this, but asking the least of your team is not going to get you 10x developers...or leaders.
"A 10x developer encourages everyone to participate equally."
First, let's get past the motivational-poster style platitude. It's touchy-feely, for sure, but the key issue is what's missing: the how. And by that, I mean the author's recommendations (ask people their opinions, invite discussion, communicate frequently, take notice whens someone dominates the conversation...) aren't valid.
And they aren't valid, because they aren't addressing the key problem:
**Why** isn't everyone participating equally?
In order to get to the root cause of this sociological issue, one must understand the nuances of human interaction (sociology!) A true solution to the problem would require a post all its own, but just to scratch the surface:
In the real world, there are plenty of teams adept at software construction that produce amazing creations and are comprised of developers that possess absolutely zero interest in becoming leaders. Nor is it necessary.
In order to get to the bottom of this, you're going to need to know the secret ingredient:
Band-aids.
The Life of Expertise
Let's start this rant by understanding what it means to be a 10x developer: a developer that is measurably proficient at what they do (for a greater breakdown of the 10x developer, read this related post).- increasing depth, or
- increasing breadth of knowledge.
When a developer increases their depth of knowledge, they are attempting to understand a focused area of their industry in a much greater capacity. A JavaScript developer learns even more JavaScript. A C# developer learns even more C#. A PHP developer switches to a different language.
(Kidding! I'm kidding! Some humor is allowed, right?)
With time, this down-the-rabbit-hole style of knowledge expansion results in the developer becoming a specialist.
By contrast, when a developer increases their breadth of knowledge, they attempt to expand their horizons by understanding the tangentially dependent pieces of their industry's bigger picture.
One web developer might begin to explore more of the web server installation/configuration piece of their work. Another web developer might teach themselves about the benefits of test-driven development. A third web developer might pursue a better understanding of when NoSQL is appropriate vs. SQL.
Expanding one's knowledge around the technology and processes that rely on (or are relied on by) the core trade of the programmer will eventually lead them to become a generalist.
Generalists and specialists, therefore, are a result of focused experience in their industry. And when generalists and specialists emerge, one of the most important skills they hone is the ability to understand the difference between band-aiding over a problem and applying a fix to a root cause. In other words: experts identify and treat the disease rather than its symptoms.
Generalists and specialists, therefore, are a result of focused experience in their industry. And when generalists and specialists emerge, one of the most important skills they hone is the ability to understand the difference between band-aiding over a problem and applying a fix to a root cause. In other words: experts identify and treat the disease rather than its symptoms.
What does this have to do with a 10x developer not being the same thing as a leader? Read on!
Apples To "Words That Rhyme With Orange"
Why code is slow, how to configure a web server, the value of TDD, and the differences between relational and non-relational databases are all questions that fall squarely into the technology industry.Conversely, the reason why people go awkwardly silent on a conference call...does not. Pluralistic Ignorance is in the lexicon of sociologists, not technologists (and likewise, I don't expect many sociologists to know what a Non-Clustered Index is!)
A programmer that is self-driven, motivated, passionate, and cares deeply about what they do is going to spend time becoming more proficient at their craft. And that is really what we're saying when we describe a 10x developer: they are a developer that demonstrates an expert ability at sussing out technological root causes and applying technological fixes, as compared to their peers.
But the root causes (and subsequent fixes) for sociological issues require a different school of thought, training, education, and practice to employ. It is an entirely different industry altogether. Sure, there's a little bit of crossover in the Venn Diagram where technology and sociology meet...
...but it is slim.
And let's not forget why some people got into technology in the first place: because their love was of technology and not of sociology.
The science of human interaction is (unlike code) one of the grayest areas of science, the most hotly debated when interpreted by academia (when their experiments can reproduced!) and perhaps the most difficult to apply solutions to (And if you disagree, perhaps we should invite a Psychiatrist and/or Psychologist into the conversation).
In other words: getting human interaction right is one of the most difficult, most complex skills to master.
Let's Review
Can we agree that a 10x developer demonstrates measurable proficiency at their craft?
And can we agree that one of the key attributes of measurable proficiency is expertise?
And can we also agree that the ability to identify root causes and assess appropriate solutions requires said expertise in their field?
And (deep breath) can we agree that technological problems and sociological problems are of two different sides to a Venn Diagram?
If we can agree, then I ask you...
Is it wrong to ask a technologist to explore the basics of human interaction, to become at least moderately literate at how best to be part of a team?
Not at all. Perfectly acceptable, in fact.
And by learning about/employing the bare minimum when it comes to human interaction...is this the key to transforming a mediocre developer into one that measurably outperforms their peers?
I don't see how it possibly could.
But when we ask for moderate literacy in sociology, that's what we're asking:
Hey. Socially awkward programmer over there. I know it might pain you to step outside your comfort zone, but we'd appreciate it if you knew the bare minimum when it comes to interacting with your fellow teammates.
How is that any different than going to a database administrator and asking:
Hey. Database guy. I don't know why the database is crashing every 15 minutes, but go ahead and reboot the server and let's carry on with the day.
I'm sorry to have to be the one to say this, but asking the least of your team is not going to get you 10x developers...or leaders.
Example: How to Be a What, Now?
In order to draw some clarity around this "bare minimum" position I take above, I'm going to have to quote a controversial "How to be a 10x developer" post. I would like to note for the record that before I begin to shred this, I think the post contains a lot of great advice that many of us would do well to consider. It's not a terrible post! But it is also not a 10x developer how-to post."A 10x developer encourages everyone to participate equally."
First, let's get past the motivational-poster style platitude. It's touchy-feely, for sure, but the key issue is what's missing: the how. And by that, I mean the author's recommendations (ask people their opinions, invite discussion, communicate frequently, take notice whens someone dominates the conversation...) aren't valid.
And they aren't valid, because they aren't addressing the key problem:
**Why** isn't everyone participating equally?
In order to get to the root cause of this sociological issue, one must understand the nuances of human interaction (sociology!) A true solution to the problem would require a post all its own, but just to scratch the surface:
- management by fear: do we know if there is a situation involving a boss not in this picture that is oppressive and has built a culture of fear around mistakes? That will shut a conversation down very quickly...yet isn't considered in this context.
- pluralistic ignorance: has any thought been put into combating the natural tendency for humans to resist contributing to the conversation, for fear of being singled out as foolish, when in fact, the entire group shares this same thought?
- introverts: what steps have been taken to consider those highly anxious folks who are measurably more comfortable (and productive!) when not forced to contribute their thoughts to a crowd -- for no reason other than to be seen as an "equal contributor." (this is why I detest "company cheers")
- bike-shedding: if it's possible this group actually succeeded in snuffing out bike-shedding -- people speaking on a subject they know little about in order to falsely convey a sense of authority or contribution, leading to wasteful debates on meaningless topics -- then I ask you: why would we want to reverse that progress?
Bonus points to you if you recognized all four of these terms and how they affect teams. But even more bonus points to you if you recognize that programmers aren't naturally thinking about things like these.
(By the way, if you think this isn't the bare minimum, let me just note for the record that entire books have been written on just each one of the four bullet points above. Sign-up below for some recommended reading!)
It is certainly a magical thing to stumble upon a measurably proficient developer that also demonstrates real leadership skills. But do not make the mistake they go hand-in-hand. Not all chefs are compelled to be plumbers. And not all technologists make it their life's work to be expert sociologists. Some of us love the pursuit of knowledge in an effort to improve our skills, and others find interest in learning about completely unrelated industries. But it is (say it with me) foolish and shortsighted to assume everybody become an expert at everything. And asking someone to do the bare minimum (in any industry) is the worst way to transform an average worker into an expert one.
(By the way, if you think this isn't the bare minimum, let me just note for the record that entire books have been written on just each one of the four bullet points above. Sign-up below for some recommended reading!)
It is certainly a magical thing to stumble upon a measurably proficient developer that also demonstrates real leadership skills. But do not make the mistake they go hand-in-hand. Not all chefs are compelled to be plumbers. And not all technologists make it their life's work to be expert sociologists. Some of us love the pursuit of knowledge in an effort to improve our skills, and others find interest in learning about completely unrelated industries. But it is (say it with me) foolish and shortsighted to assume everybody become an expert at everything. And asking someone to do the bare minimum (in any industry) is the worst way to transform an average worker into an expert one.
Summary
We all have our limits. Let's respect them.
- Measure a 10x developer by their turnaround time, and leave people management problems to those of us who choose to pursue proficiency in managing people.
- By all means, foster a culture of teamwork, making mistakes, growing, and supporting one another -- but know what you are asking (the sociological bare minimum) and come to terms with the fact that this will produce neither 10x developers nor leaders.
- Take comfort in the the knowledge that expert developers would rather not band-aid over people issues, just as great leaders would rather not band-aid over technological problems. Understand and respect people's choices on how they further career; don't burden them with another industries weight.