Talent Cooling (2020)
nirantk.com
nirantk.com
Not sure I'd call it "fancy."
I've watched corporations chasing out high performers for decades, yet still manage to achieve their goals. They don't excel, and often end up being "part of the road," as Stuart Brand might say, but they never regret chasing out talent, and also never regret chasing talent away at the interview stage.
I know that I nursed my butthurt, with a secret "they'll regret not hiring me!" thought, for a couple of years, and realized that it didn't matter one whit. One or two of the places actually ended up going belly-up, and I like to flatter myself into thinking I could have "saved them" (SPOILER: No, I wouldn't have. They just would have sidelined me, and gone over the cliff anyway, like my previous employer).
Human nature can be very disappointing, sometimes.
'“Refactoring” becomes a rallying cry instead of shipped.'
I can imagine product managers right now saying 'hey that's me' this must be true. Note that an ask to refactor rather than continually shipping fast is a sign of mature engineering and is common.
Nobody pays to think about how to make the tech stack better outside of company time. And when you try to push your hare-brained schemes, the management reaction is of skepticism of the benefits and worry about the potential risks.
Driving these kinds of improvements is a risky, thankless job, that's not necessarily good for your career.
Most people either want to work as little for as much money as possible, so they phone it in, or want to get promoted, which usually involves playing office politics.
Bad advice blogs just write vaguely relatable complaints that are generic enough to get a wide audience to empathize from their past experience. The reader is supposed to imagine themselves as the superior engineers in the story (the heroes) and imagine the people the bad engineers and business people as the villains. Stoking the reader’s ego is a classic engagement farming technique.
No compelling reason is provided, except "it has to do with startups".
For a long time I couldn't pin down why this stuff bugged me, but I think I finally have it: it considers people to be static and one-dimensional. Because hey, there's no way the people who are expert/genius/10x could fall off the wagon, or stop keeping up with the field, or have kids, or burn out, right?
And similarly, the reverse is also true - is it impossible to train people to be better at their jobs? Are successful startups a magical place where a couple brilliant people come together and after that, a company can never hire that level of brilliance again?
There was another article a week or two ago that spent some time discussing how software tends to be 80% reading/maintenance work and 20% (maybe) greenfield work, and how optimizing for readability, durability, easily understood code and the like is better for the long-term health of a project/company than flashes of brilliance. And I'd guess that as your product scales and matures, shipping quickly becomes more difficult because more work has to be done to prepare things; quality expectations have changed; interfacing with and matching existing components functionality becomes a bigger part of the process. Saying stuff like "we lost our most brilliant people and now things are falling apart" feels like an excuse and an organizational failure to me, rather than a talent problem.
Great point.
These articles also assume that companies are static, one-dimensional, and only get worse over time. These articles are designed to resonate with people who left some previous job in the past that didn’t go well, which is a common enough experience that most engineers will experience it at least once over a career.
The problem is that they take this generic experience (which the reader likely recognizes as valid because they’ve seen it before) and try to present it as if it’s a law that all companies are doomed to follow. In reality, companies ebb and flow over time as management changes over and many good companies get better, not worse. Unfortunately articles like this create a fatalism or doomerism that creates some very cynical engineers. Ironically, those cynical engineers often become the “B players” that lead to a decline of a company, all while they imagine themselves as the “A players” because they think they’re the only ones who see it like it is.
‘B’ players, though… they indeed just do a job through the day. No passion, just a job well done. They like to think that they have other things to do with their life, and they do exactly that.
When it goes well, everyone loves me. Especially the team. Because they've been saying all along what's going off the rails but nobody listens any more. But I can say it, and for a while at least everyone hears it.
So many companies hire just a few top talents and fill the rest of positions with average guys.
This works well as the top guys solve the hardest problems and also split the complicated things into less complicated things the average guys can tackle.
If I would start a software business, I would do the same. I would rather direct juniors and give them manageable tasks, solve the most complex things myself and take care of the architecture than hire experienced seniors who I might not afford.
There is a big problem if those top guys are gone.
I recall a study that indicated that as far as small teams go there are only a handful of people (very rare) that actually can bring a team's productivity, happiness, and other factors UP. Rather the vast majority of team's productivity and happiness was largely determined by the worst participant, not the best.
Granted that's all very difficult to measure / defined, but I've found that to be the case personally.
There's so much focus on hiring "the best" I'm not sure that's where the issues are.
Especially in micro services environments the number of commits do not reflect genuine work. Someone can push a boilerplate change every day to one of the 17 repos required to ship and make it seem like they are working when in reality it’s just bureaucracy. Change everything to focus on ease of shipping high quality features and eliminate excuses as to why that can’t be happening.
If only it were that simple. I've been inside clients where this happened. It generally wasn't pretty. You want an avalanche of trivial features? This is how you get an avalanche of trivial features.
Meanwhile, the end user population is restless with non-trivial features sitting in backlogs for quarters and years on end...
Then some bright bulb decides to let end users vote which features get worked upon. And the largest cohort of users dominate the agenda driving away the multitude of 1-3% cohorts that happen to make up the majority of the market for the product with their Microsoft Office-like lists of not-quite-alike feature lists, but are the bread and butter of most mature codebases serving large diverse end user populations. Sales people love large diverse end user populations. They make sales so much easier.
There is no substitute for judicious leadership. The map is not the territory. You need a balance that you will always struggle to adjust; all metrics or all gut feel both lead to poor outcomes.
I’m saying if you have an organization that can’t ship anything, then you need to right the ship by promoting a mindset of actually building and shipping value. The value is not determined by the ICs.
This hits close to home. Every death spiral I’ve seen has had a phase where “refactoring” seemingly becomes the primary activity of the team.
Some of this is refactoring is necessary: When inexperienced engineers write the wrong structure at first and need to correct it. However, much of it is arguably unnecessary: Engineers “refactoring” code to make the system more their own creation than someone else’s work, or simply rewriting old code because it’s easier to revisit familiar old code with the benefit of hindsight than it is to write new code with new challenges.
I once inherited a failing project with a team of engineers 3-4 turnovers removed from the original authors. They were burnt out from being busy all the time, but they couldn’t actually point to any new features or even improvements they had shipped recently. It was all just “refactoring” to complete an architecture change that had been started by previous engineers who left. At that point, nobody who remained actually knew why the giant refactor was started or what benefit it was supposed to bring. They were just “refactoring” old code to match a new style that a departed lead has preferred. Madness.
There are lots of factors that impede growth and yes the raw talent is one of them. But the other factors like technical debt, product debt, poor leadership, lack of alignment, all contribute to “not shipping”. You cannot realistically solve these problems with engineering talent alone. Without a system or structure to enable them even the least “talented” engineer would be rendered useless.
So say you have very high taxes, well as with most things the top 10/20% are paying 80% of the taxes. If you bump your tax rate too high you lose the top earner who end up leaving the country. This then creates a ripple of people earning a lot who all leave and you're left with very few top earners and high taxes.
Not sure I am personally for low tax systems but it shows you how most things work best when you're in the middle, not at an extreme.
A manager gets put into place (usually an inside hire) who is either outside of their competence or too set in their ways and it impacts morale, hiring, communication, and eventually software quality and compensation.
These managers are often at the mercy of their team. They usually report to a nontechnical VP or director who isn't hip to the resume building, lack of velocity, and implicitly lowered expectations.
I have interviewed at, consulted with, and worked for some of these orgs. It's basically a 50/50 shot on whether the situation is salvageable, and that's after management has made the wise decision to bring in an outside eye.
My favorite anecdote on this was a local company related to insurance of some sort. I pitched my services but was passed up on for someone else who I knew would only further the problems. A very short while later, I received a stack of resumes, including for the person they brought in to right the ship, all on the same day. Management got so frustrated with the development team they blanket fired everyone in IT below Director level and outsourced development to Romania.
Here are two mental models I used successfully to reason about teams.
One is the idea from Team Topologies that whenever a member leaves or joins a team, you get an entire new team. This new team has to go through the phases of a team again (form, storm, norm...). Also teams are entire entities that are bigger than the sum of their parts. That's why a single person leaving a team can have an outside impact in the performance of said team.
Another idea is the Dead Sea effect [1]. This stipulates that high performers will tend to leave teams because they can, while low performers will stay behind.
[1] https://www.google.com/search?q=dead+see+effect&oq=dead+see+...
That's not to say the article's bad - it's quite the opposite, but it's kind of sad that this needs to be said (and it does!)
Nearly every IoT product I buy seems to be staffed with those mediocre teams, resulting in apps that are practically useless.
I'm not going to say that some "top talent" won't be toxic to an organization, but having _nobody_ in those top spots to help mentor and bring up the level of more junior developers in an organization is a recipe for shipping nothing but bad products that make nobody happy.