There’s something of a mythology in the developer community around high performing employees who are seemingly able to output much more work than anyone else is in the same amount of time. The concept isn’t strictly limited to software development either as I’m sure anyone from any industry can regale you of a tale of someone who did the work of multiple people, whether through sheer intelligence or dedication to getting the job done. Whilst I have the utmost respect for people with this kind of capability I’ve recognised a disturbing trend among projects who contain people like this and, to the betterment of the wider world, I believe we have to stop seeking these mythical people out in order to exploit their talents for our own ends.
Long time readers might remember a post I wrote a couple years ago about how I tanked my university project due to my lack of any project management skills. A big part of this was my failure to recognise the fact that I had a 10x worker on my hands, someone who was able to do the vast majority of the work on the project without aid from anyone else. In the short term it was a great boon to the project, we made fast progress and we all felt like we were getting somewhere with the idea. However it didn’t take long for all the additional work that 10x person was doing to turn into a dependency, something which the whole team was relying on. My failure to recognise this (and to pitch in myself) was what led to the inevitable demise of that project but I’ve since learned that this is not an uncommon occurrence.
Typically the situation develops from the best of intentions with a high performing employee put on a task or project that’s in need of some immediate attention. For them it’s not too much trouble to solve and the short time frame in which it’s achieved means that they quickly establish themselves as someone that can get stuff done. What happens next depends on the person as once that reputation is established the stream of requests will only intensify. From what I can tell it goes one of two ways: either the 10x in question sets a hard limit (and sticks to it) or they continue to take everything on board, right up until breaking point.
For the former it’s not too much of a problem and indeed would go a long way to highlighting resourcing issues with a project. I firmly believe that whilst the occasional bouts of additional hours aren’t too detrimental long, sustained periods eventually lead to burnout and loss of productivity. So setting limits on how much work you do and staunchly refusing to take on additional tasks shows where additional resources need to be placed. This also requires you to be comfortable with things you’re personally involved with failing on occasion, something which a lot of people find hard to do.
Indeed the latter kind of 10x-er can’t let things fail, especially for anything that they’ve had direct input with. For tasks on the critical path this can be to the project’s benefit as you can rely on the fact that it will get completed no matter what else happens. However as more and more people start to go to this 10x person for help the breadth of things they’re involved with, and thus feel responsible for, broadens to the point where almost anything is within their purview. Thus a terrible feedback loop is established, one whereby they become critical to everything and feel compelled to continue working. This continues until they burn out or some forcible action is taken.
Whilst this is a two sided problem I do feel that we, as the regular workers of the world, can do a lot to ensure such people aren’t destroyed by the burden that we place on them. It can be so easy to fob a task off onto someone, especially when you know they’ll do it quicker and better than you could, however if you know that person is similarly being burdened by multiple other people it may be better for you to learn how to do that task yourself. Then hopefully that 10x worker can continue operating at that capacity without approaching those dangerous levels where burnout becomes all too common.
