Stop Ignoring Your High Performers
hbr.org
hbr.org
Over time the risk of them leaving builds and others are reluctant to take on their mantle (complex code, assumed overtime, whatever). I've never been able to hire a high performer with the remit of 'please take over this complex and custom system your predecessor built and walked away from' - such people want to build that stuff themselves and someone else has already had the fun.
Businesses want reliability and predictability, your high performance is probably better spent on your hobbies, or your own (ownership >= 10%) businesses.
High is relative to other team members so I suspect this is true no matter the baseline skill.
I have a different theory. I think the real reason is that writing code is easier than reading. Literally, it's psychologically more comfortable to write code than to read it.
Downside is those devs forget that in 3-6 months of not working on that part will have the same feelings.
I work on the same system for 10 years now, I moved to a more dev ops position and don't write that much code, when I pick up some ticket I am really amazed to find out code that I am working on changing for the ticket is something I wrote a year or two years ago and I have no memories of writing that because I was doing thousands other tasks in different places of the system.
From experience I'd say that there are at least three (usually overlapping) reasons:
- There are often valid technical reasons to rewrite at least parts of the codebase. Most companies tend towards a "don't fix it if it isn't broken" policy, which tends to lead to most components being in a "not far from broken due to poor maintenance" state. It is reasonable to want to fix those up before they cause an outage. An ounce of prevention saves a pound of cure and all that.
- Making new things is more "fun" in one way or another, even if it is just because trying to grok the spaghetti code of another is "not fun".
- The dev in question has (usually correctly) identified that the way to get more of what they want, be it money or power or fun colleagues or interesting projects, is to be involved in building new things. It's no secret that humans often ascribe more value to those who make new things even if it's not justified.
Unless the environment becomes such that these three get mitigated, devs will always want to rewrite things as they are heavily incentivized to do so.
I see lots of really good Devs who love the details and making sure they are communicated well, writing code that is understandable and time on ensuring regular maintenance and upgrades are carried out or better still automated, but most importantly spreading that knowledge around the team.
It does sound like you have considered these things, just your definition of high performers seems like it could do with a rethink.
That’s one of the benefits of a higher job level. You get to claim credit for shipping everything you had a hand in even when your contribution was often little more than organizational presence. Which is to say, being the “face” of the project to upper management.
Let me read between the lines here and assume the worst, then please correct me and tell me it doesn't apply to you.
A left. High performer candidate B didn't want to pick up A's stuff. Let's say it was over-engineered or over-complex or whatever. You ended up hiring C, and C was not a high performer. In fact, a wild guess: you hired two C's at the price of one A.
Perhaps your preference was to hire two "everyone is replaceable" C's all along? That's not to say that some projects are not more suited to low performers. But the engineering management style can tip the scales no matter what.
Someone who doesn’t want to take over someone else’s code deep dive and understand it first is not high performer in my understanding.
Efficient debugging and understanding systems other wrote or created is basic requirement for high performing dev in my opinion.
There's a fundamental difference between being able to rip apart a ball of mud and rebuild something sane out of it and being excited to do that for a pittance.
A high output team player is gold and we want as many as possible. A high output singleton will likely have sacrificed some element of quality or maintainability or thoroughness or likely even their own personal lives to reach that output, for the projects they enjoy doing.
That output is unlikely to translate into a new, less interesting project and if the work or system is now structured to require that level of output then few would want to take up the position.
The over used canoe metaphor is useful, you want people to pull at the same speed. I also enjoy the 'always be leaving your job' approach that guides people away from building themselves into the system.
- You choose to write grammar school textbooks just so you can hire cheaper writers.
- Or worse, you're required to write grad school textbooks but you still hire cheaper replaceable writers.
We are conflating skill with performance, but the 10x theory (IIRC) is that they are correlated, or at least can be given the proper motivation.
Team players are always better than singletons, so let's assume there's no correlation there (which may be a stretch, sure.)
I work with more graduates of Russian than I do Software Engineering.
One of my more gratifying mentorship experiences was having one of the devs I advised come back to me years later and tell me how much my teaching him to recognize this phenomenon helped his career.
In general you could think of all software development as a heap of hacks. It gets taller and taller and taller until it falls over. What you are describing is someone who makes the heap a lot closer to falling over. The ideal of a 10x engineer is someone who makes the heap more stable, someone whose architectural contributions make it possible to have a higher heap and allow others to do more/better work. Over the long term a 10x engineer's product is the capacity for more growth.
Mentorship is certainly one way to get a longer lever to stand on -- a way of making investments in the future, but even feature dev can fit the bill: https://thedailywtf.com/articles/the-cool-cam
Are you hiring right now, cos this sounds like fun?
(modulo the likelihood that our definitions of high performance differ).
Oh hell yes. This exactly matches my experience. To the point where I actually consider high performers a detriment to the overall effort. I have been the most happy with mediocre, cooperative people in the team.
The only real incentive to become a 10x developer, at least for me, is to use my time for other things. Otherwise, stepping outside the mold just upsets people in the corporate world.
It'd be nice to hear from the counter example here, the 10x developers in meritocratic nests. Mostly so we know where they are.
The second thing is that I never said no to more money. It's a job, your boss and colleagues are people who work with you. Occasionally they can become friends but not automatically and not most of the time.
Primary skill is somewhere around understanding politics and grokking how to please the person evaluating / promoting you. If its about rating from others then same applies to them. Rarely is that directly relevant to quality of engineering output itself.
This goes often very directly against innate desire of engineers to do some good creative work so we often struggle to get appreciated, but that's how it is. That's why various degree of sociopathy present naturally helps with above and smart sociopaths comfortably inhibit higher levels of management of such places. I don't use that term as an insult just to be clear, rather personality trait that is not binary but very much endless tones of grey.
Triple above if IT is just a cost center to given corporation.
Talk about "10X performers" reminds me of the saying "It’s a marathon, not a race." Most people recognize Usain Bolt, but how many people have heard of Eliud Kipchoge?
In our field, the "Usains"—the flashy 10X performers—are hailed as heroes. If you are a "Kipchoge", quietly focusing on a sustainable career, you will probably fly under the radar.
Rather "it's a crawl, not a marathon".
Also, I think the most value a programmer provide is as a maintainer.
I blame feature factories led by agile clergy for the perceived drop in commercial software quality in the last 10-15 years. There is no place for maintainance.
This is a weird take. The most basic principle of agile is that you start with a tiny kernel of software that does something useful, and then iterate on it. In effect, all agile software development is maintenance.
Its not like they are going to get paid 10x more for over achieving. There is nothing flashy to this. Instead they will be reassigned to other people's problems on top of their own work. So, its best to just keep it to themselves and over achieve as necessary to do less work, because they will get paid the same either way.
This is the crux of the problem for me. How many of us are literally not allowed to work on stuff not on the backlog, which is usually driven by product people. We only deal with the product roadmap and other issues (technical debt, inefficiency, security issues, etc) don’t get resolved unless it somehow impacts the product. If you’re very lucky, you’ll have an actual technical CTO who has the power to say no and allow the developers to remediate issues (one CTO I worked with had to spend enormous political capital to get a single sprint dedicated to upgrading to Java 8 so that the developers could benefit from lambdas - something that for our code base literally cut development time in half due to the way we ingest and process very dynamic ingested data).
There must be some law of software engineering that all engineering teams eventually become run like assembly lines where management disallows ground-up thinking.
One place I worked finally only implemented a proper security program when a potential customer demanded it, and it was ultimately implemented as a checkmark-based solution to meet the terms of the contract. This meant burning CVE’s more than writing secure code.
This was frustrating as management at the time decided microservices were what we needed, but then resulted in a distributed monolith because they weren’t allowed to spend the time on architecture work, tooling to secure communication between services, or even have proper distributed tracing.
Its a law of incentives.
At some point protecting the existing processes is more important than growing, which implies disruption.
At that point all the things mentioned above start
That's not exactly true. What upsets people in the corporate world is telling others that their creative ideas enshrined as a Corporate Policy are wrong and asking to do it the other way.
What doesn't upset people in the corporate world is finding a way to further said Policy while at the same time getting yourself a license to some creativity in the ways to implement it.
So, you end up with these colossal frameworks, yes that's plural. The developers like to pat themselves on the back for their supreme challenge of conquering the beast to... put text on screen. It's stupid, but it a way it's self-validating because these frameworks are just massive. They provide an API more than 10x larger the standards they replace so that developers don't have to form original opinions or build things.
When I say stepping outside the mold I mean not doing any of that stupid shit. As a result of avoiding the stupid I can release products that are possibly 1000x faster to execute, more accessible, dramatically faster to maintain, and so on. One developer that actually knows what they are doing can easily replace an entire development team. If that one developer that knows what they are doing always knows how to implement test automation they can reduce expenses associated by regression around 95-98%. But when you do any of that you have immediately invalidated the existence and imposter nonsense of the other developers like popping a balloon. The natural response is hostility.
Fortunately I was able to switch careers and go do something else.
<< You’ve got to make their lives decent
And this is where we agree. If you can make the performer life better ( not automatically with money ), you got their attention.
I totally agree with your sentiment but I think “more free time” is a difficult award in general. Most managers would probably look at most high performers and say “you want more time? Then work less! You are already over performing” it’s somewhat out of their hands how much someone chooses to work, but they can more directly control how much they pay and award via bonuses.
Note that I am not denying pathalogical burn out is a thing.
Like, I'm currently willing to take a pay cut to get more autonomy and a better (for me) workplace environment.
I’d rather lower compensation but actually being heard out by business.
It also of course usually works that having higher compensation goes in hand with business listening to people with higher comp.
It's less of a trade-off than it's often portrayed as.
In practice, these are not the same people. The people who have a direct impact on empowering and respecting you are your manager and their manager.
These people also have (having been one) surprisingly little say in how much you get paid. HR rules that land. We can present arguments and beg and plead, but ultimately don't really have any decision making power on the paycheck side.
Yes, there can be pockets of good management in otherwise bad companies, and vice versa, but generally the two are largely aligned.
i.e. when I've been in roles where both pay and respect are good, the latter is always because my direct management chain supported it. The same company has always had unlucky teams where respect was missing even though payscales were the same (since the latter is company-wide).
That where the saying comes from: "People leave managers not companies".
Pushing teams and product managers to take a bit of time up-front to consider architectural decisions, ideal vs minimal feature sets, security concerns, etc. got me promoted into a manager of managers role.
What I didn't realise was that it wouldn't actually mean having more weight to throw around. Instead those sideline efforts became my entire job and that job was exhausting.
I still believe it's possible for startup product teams to move fast without sacrificing quality and sustainability, but I'm increasingly convinced that the only way to achieve that balance is to build it in from the start.
Only one went back to coding. Most of us are quite happy with our work (not sure how we look).
Because no one has means to validate what actually they did.
I have seen loads of ppl who cannot make heads or tails in code but went management route.
The key is to recognize the Maslow's hierarchy here as well (hierarchy of benefits, instead of hierarchy of needs). Once you offer someone top comp and top health benefits, you have crossed the hygiene layer. Then you go to the social layer (recognition, awards, non-toxic env) and finally the self-actualization layer (autonomy, pushing them harder, long-term aspirations).
Dont cheap out on the hygiene factors!!
A non-toxic work environment isn’t a “benefit”, it’s a basic requirement. Same for autonomy. Healthcare is just compensation.
In the end, compensation is what matters.
a good team and good project is worth a lot
I could say we can safely ignore everything you wrote. Not everyone is driven solely (or even primarily) by money alone. Some/many people are, so your take is one of many valid ones but not the only one. So managers, you actually need to understand what drives your high performers.
I have never quit a job due to pay, it has always been due to other factors.
One of the quickest ways to disengage a high performer is to micromanage them. These individuals have proven time and again that they are capable, innovative, and reliable.
It goes well when company goals align with high performers goals and as soon as the two diverge it starts being more problem than not.
We have lots of articles and voices about CV driven development so that is also there.
Very much a "developers do the Jira tickets I create, that's it" kind of mentality in most PMs I've ever met
Exactly what you're saying - does this tech debt Work™ or is it affecting future development or causing incidents?
[0] https://technology.riotgames.com/news/taxonomy-tech-debt
The arrogant-yet-incompetent management I have encountered actually makes it difficult for high performers since the mental “box” they want people to fit into and be cogs in the machine, gets exposed as false; the usual way to fix this is to get rid of the problem, by firing the high performers.
Ultimately, I think if the management has self awareness and clear goals, a lot of this crap can be avoided (but sometimes that means selecting out people who are rocking, because they don't match the system).
i.e. retaining your 10x superstar is important, but are the rest of the team really only capable of 1x? Really? What's the benefit to them of giving 2x?
There seems to be some myth that everybody gives every ounce of their potential, out of the goodness of their heart as an employee. I think the reality is that most of us do whatever the role requires, plus anything we happen to enjoy/fixing frustrations.
You also have the effect where the perception of being a 'high performer' might be gamed.
E.g. it might be rather trivial to churn out code and be perceived like a high performer, but you are essentially just creating alot more job for everyone else and drag them down.
Also, it is easy to do so much stuff that you will be blocked and waiting on other, who seem slow etc.
Unless the manager is working along side you he likely wont notice. And these points also happen automatically by itself. But I guess adversial collegues use the concept to game the workplace.
Or you could pay the high performers more and compensate them better?
People are generally not spending their time at work for sheer altruism. There are of course exceptions, but I would say the majority has bills to pay and the uncertain future to consider; people work, not because of self-fulfillment and spiritual growth and whatnot, but because they get money for their efforts.
Also, if the work environment is micro-managed, meeting-infested, has arbitrary policies, lacks autonomy, does not recognize people, has near zero growth opportunities, bottom ranks go "WTF?" every time when upper ranks open their mouth, and so on, I doubt people can become high performers to begin with.
That is: the work environment has to do something right for high performers to arise at all. So, optimizing the components of a good work environment further might be fine, but if those are already on an OK level, from the point of view of the high performer: what's the point -- what's in it for them?
Then again, I don't live in the States.