Hope the idea of the 10x Engineer ends soon.

Get shit done.

Don't be an asshole.

Share what you learn.

I'm with you, Eric. This is so sad:

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.

She really nails the argument with this statement:

It erases many of the essential team and cultural dynamics involved in true productivity.

Teams. Teams are more powerful and productive than any individual superstar.

I remember stories of the lone genius toiling away long into the night. Suddenly, he emerges from his laboratory, hair matted with sweat. He's found the solution to all our pain and suffering. Bah!

Good products take team effort. When it succeeds or fails it is the leaders who will take credit and be remembered. But anyone who has worked on anything meaningful knows that it is never just one person.

Furthermore, one person means a single point of failure.

One person means that the limitations of the product are the limitations of that person.

One person means that the project itself can end if anything happens to that one person.

It's taken me a long time to believe in the ability of teams to do something bigger than ourselves.

And now I believe there's no limit to what organizations of people can do if they work well together.

Shanley's whole post on the subject is worth reading, and takes about 7 minutes according to Medium:

https://medium.com/about-work/6aedba30ecfe

I understand and agree there is value in teams (small teams).  

I'm not sure I fully understand what 10x myths are being railed against here--is it a general point about the prospect of any individual's talent being overvalued, or is it a more specific insight into an egalitarian culture of engineers writing code in software professions?

The article provides the history. If you haven't read "Mythical Man Month" or other similar kinds of books about the productivity of software engineers then I can see how there might be a disconnect for you. The notion is that some software devs are so good at coding they are akin to gods among most mere engineer mortals. They are always 10x more productive than the average computer engineer. Unfortunately, the generalization fails to control for context. I'm sure you can imagine a situation where a certain engineer can thrive and be exceptionally productive and another where that same engineer will not. The myth is an ideal abstraction. An ubermensch who thrives no matter the environment. I wonder if the idea is more common for professions that deal with abstractions?

Thanks James. No I haven't read "Mythical Man Month" or similar books, but your post is very helpful and clarifies.  I have done a few software projects and worked with software engineers but I'm not one and not overly familiar with the culture.

The idea of ubermensch is certainly common to many professions and I wouldn't suggest only limited to abstract ones.  The challenge is not prevalence but the ability to use such conceits to good effect systemically (e.g. hiring, deployment, etc.).  Ubermensch-dom often fails for the same reason you cite above--lack of applicable contexualization.  

That said, it can be a valuable role done well and productively.

I have used sustaining myths professionally and consistently invoked the ubermensch role to great productive advantage in previous work, which at the highest frequency was creating innovation environments for civil engineers and poor people to build huge things all could touch and measure (i.e. community wide clean water distribution and sewage collection systems in poor and rural areas).  

The myths I animated focused on the qualities of an ubermensch and then spun into the presupposition that anybody could be one and achieve great things (i.e. 10x productivity) simply by acting with those key qualities during the life of the project.  After invoking the myth and engaging several ubermensches we'd get amazing results of increased quality while gaining project cost and time savings and with monotonous regularity.  Hundreds of thousands of poor people better off, hundreds of projects completed and hundreds of millions of dollars and decades saved. 

Fun work.

I think we're roughly digging in the same dirt Rob, but I had a little difficulty pushing through your comment.  I'll do my best to be equally dense and challenging :-).

I agree to a first approximation anyone can become your 'ubermensch', or even if they can't there's no point in not aiming at it anyway assuming you actually WANT to do it.  It's the fastest way to know if you really love it or not.

The 10x thing is management pulp garbage.  I appreciated the artful ripping in the article.  It needs doing, and needs more doing.  The truth is WAY MORE COMPLICATED and can not be described or simplified in any usefully predictive way (let alone memeified).  It's mostly only comprehensible and manageable in the specifics by those swimming in the specifics, with expertise in the specifics.

I often reflect on the correlation (or lack thereof) of tech engineering with building architecture.  Of course, I've never been a building architect and don't know any very well, but it does seem: there is one all stomping ego (or a small cell) at the top of the project with creative control and responsibility for managing the complexity and managing the complexity of the complexity.  Then there's a massive army beneath (all managing subcomplexities, etc, etc, etc).  Just like your projects.

It seems tech engineering must inevitably move towards the building architecture model.  Many can design and build a deck, fewer a house, and almost nobody the Shanghai New Expo Center.

Well, it usually takes me a little time to be less dense and challenging, but I live in a mental forest with lots of trees.  My rustic apologies.  

If we agree "anyone can become your 'ubermensch', or even if they can't there's no point in not aiming at it anyway assuming you actually WANT to do it." then can we say the above article and posts presuppose some or all the following five assumptions:

1. The ubermensch engineer capable of 10x productivity on projects is a myth;

2. management pulp and media hacks advance this myth on spuriously derived historical facts that were never proven to produce a 10x productivity result in real life, just in a few narrow, observational studies;

3. engineering projects are too specific to generalize any value add played by individual talent (at any x multiplier of results) or see individual talent as a driver of greater productivity on a project;

4. reality is too complicated to refine general principles about talent management that could apply across different projects, whether in different or the same domain;

5. engineering and architecture projects are driven by top down egos that must rule over large hierarchies of subordinate workers?

Even though I've never been an engineer or software coder, I can argue from experience as a project director that different assumptions work better, especially wherever I've led engineers and software coders; or, that most of these assumptions are false when applied outside of engineer coding projects.  I say false only because I've found more helpful assumptions regarding activating team talent for 10x or more increased productivity on projects.  

My first assumption is that talent is best ascribed and valued by key dispositional qualities outside of any narrow range of technical expertise presumed as greater than minimum requirements, i.e. simply being an average coder is good enough with the right dispositions and being an elegant coder without them doesn't assure project productivity or ultimate success.  But this is not to say that the 10x talent by performance is a myth, more so that it can be activated by key dispositions, good project design and compressed pacing.

And so armed with only a few key principles I've come to believe different assumptions about talent, at all levels, being activated by dispositions and well-designed projects (vs projects being inertial tasks with linked dependencies awaiting some talented few individuals to drive their connections into a coherent whole).  

So I start from different presumptions in framing task challenges when designing projects, and act as if the following are always true:

a. 10x talent, or high-performance talent, is possible for professionals and amateurs alike (especially outside the above narrow context of software coding);

b. you can seed, distribute and activate 10x talent at all subordinate levels of project execution, and less so by team ego boosting or by isolated vesting of talent in the lead god role;

c. almost anybody can adopt key dispositions and act like a 10x myth of talent in a team setting for the life of a project (and by that context I simply mean deliver greater objectively measurable and verifiable productivity than they would have otherwise achieved).  After projects complete most amateur individuals revert back to being a non-10x performer, others might not.

I've had to design projects in many domains to work with existing talent available. l always focused on achieving total project outcomes, not virtuosity in any individual role. I didn't want anyone to care more about an individual's performance against a personal best or some random peer baseline--but wanted them to all hold themselves accountable to total project baselines being improved first.  And when total project quality, costs and cycle time to completion improved, it was amazing how many individual 10x performances we got.  And I've done a hundreds of projects, digging out tons of talent in local surroundings where I couldn't import outside experts to do the job or had enough money to pay everyone to do it--and we always were able to spin 10x gold every time out of whatever base metals we found lying around--and not just on civil engineering infrastructure projects.  Often this meant first-time, volunteer amateurs with applicable skills consistently outperformed the performance of paid experts and veteran professionals across all metrics--cycle time to completion, money spent and total inspected project quality.

Of course I got to shape the amateur talent by framing project outcomes in terms of the collective will, e.g. getting clean drinking water into their poor community at 60% of estimated costs and in 1/3 the time.  It's amazing how fast people will spin themselves into gold when a widely shared and highly desired outcome is on the line.  

And you're thirsty.

Basically: yah :-).

The article link is one of the reasons I love PandaWhale. 6am every morning I get to check for the new best of...   :)