Pretty much. When you start noticing that folks you respect and enjoy working with are trickling out at an ever increasing rate, that's the universe telling you that you should probably be looking around.
It's _very_ difficult to hire "up" in talent. Organizations _tend_ to hire slightly less talented people then they already have. Keeping top talent around and using them to attract more top talent is key. Once you lose top talent, the likelihood of you bringing in someone to help bootstrap things again is pretty low.
I have been brought in many times as a senior person to right a troubled ship. I can't think of a case where its turned out well...I'm hardly perfect - but its very easy for the existing team to decide you're a weird pain in the ass, and very difficult to 'reach down' in a friendly and constructive way and slowly tease them into acting like a functional team.
Similar experience. Often the entrenched interests have no idea how bad things are and will fight you every step of the way. I’ve had a couple of successes but in each of those cases the team was really hurting and glommed onto me like a life preserver.
These situations always strike me as very difficult, as righting a team that is already on the rocks is much, much harder than steering it away from big problems. Sometimes I wonder if the real purpose of being brought in to those situations is to give management cover for ending the project.
I agree. I am brought in somewhat regularly to "unfuck" troubled teams. Most times, what my manager is actually wanting is for me to tell him why the project should just be abandoned and the team rebuilt for something else.
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.
...especially since you don't want someone to bootstrap things again, you want someone to work on something that other people already bootstrapped - and lots of "top talent" don't find this kind of job very appealing...
This explanation is better than the one linked in the original post.
It still doesn't provide a solution. But I suppose the solution is to regularly fire the bottom x% to counter balance the effect.
I think this is the type of writing that I like the least. Someone trying to come up with another smart theory on Why Things Are Bad and Why Other People Are Mediocre (with the implication that he is not), with no supporting evidence and very little career experience to back up the observations made
It's the usual management excuse when things are going south that hey hired too many mediocre people.
Let's fire the whole team and have a new hiring process so we only hire the top 1%, 10xers. Two hard leetcode in 1 hour (2 interviews like that) and 2 day homework should be enough to weed out the low performers(but actually the process will be optimized to hire desperate devs and new grads).
I agree with you. This is a really low quality blog post. All the author did was add a fancy graph and some words to something that everybody knows - if a 1-2 good engineers leave, then everyone else bounces out of there.
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.
It's also doing the astrology thing of calling out common circumstances in an effort to have people go hey that's me!
'“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.
I feel like these posts are getting upvoted by people worried about their jobs / want to convince themselves that everything will fall apart if they leave their job.
Good advice blogs talk about how to fix problems and turn the ship around.
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.
Most people are mediocre (tech-wise). This is not to say that a few chosen ones possess the inimitable spark of genius, it's just for most people a job's a job.
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.
Not even that. They take an already existing concept (Brain drain) and decide to tell the world in multiple paragraphs about why we should use the new term Talent Cooling instead.
No compelling reason is provided, except "it has to do with startups".
If you want a shipping culture then encourage, praise, and promote people who actually ship features. If this is a new mindset shift, you will have some crabby people who complain about supposed corners being cut, red tape not worshipped properly, and all manner of reasons why the features being shipped are bad. You should listen to the concerns but redirect them to work on automating such corners and red tape and make them see that those getting promoted are actually shipping features and improving the system rather than complaining.
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.
> ...then encourage, praise, and promote people who actually ship features.
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.
It will be on engineering and product management to know what is a trivial vs. non-trivial feature and decide the product roadmap. This is not a question of what is the valuable feature.
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 is really interesting and I once heard about something similar in terms of a tax system.
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.
The 10X engineer might be a myth, but there's a real danger to ending up with a an organization full of "mediocre" talent that can't ship a good-quality product.
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.
Is there anything in that post that supports this theory?
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.
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.
This article entirely misses the mark on the reasons why scaling is difficult. I’d even go out on a limb to suggest they havent experienced solving these problems before.
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.
This feels like a rehash of older ideas I don't particularly like, eg. "A players hire A players, B players hire C players", etc.
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.
> 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.
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.
In my experience ‘A’ players don’t just ‘work’. They have a passion about what they do and just fulfill their passion with work that happens to be useful to others.
‘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.
The simple word is elitism: We'd all like to be part of some in-group that is automatically entitled to success with minimal effort. Broadly speaking, it's really just plain old immaturity that most programmers will outgrow if they aren't coddled.
This is one of the articles whose message (that great people drive product success) is immediately, blindingly obvious to anyone who interacts with engineers on a day-to-day basis, but seems like some sort of sage insight to management folks who try to divine company performance from slopes and graphs.
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!)
> After a period of time, your tech team is unable to ship fast enough and sometimes even your basic hygiene factors like uptime are suffering. “Refactoring” becomes a rallying cry instead of shipped.
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.
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.
There's a certain kind of "top talent" who like to explain why organizations suffer when people of their brilliance are not catered to. When they have to fix things, or maintain things. When they can't always be working on precisely what they want to be working on at every point in time, where they have to serve an actual purpose beyond "ooh, shiny!"
Those are big and bold claims with no data to back them up.
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.
49 comments
[ 2.0 ms ] story [ 116 ms ] threadWhen 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.
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.
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.
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.
No compelling reason is provided, except "it has to do with startups".
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.
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.
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.
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.
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.
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.
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.
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!)
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.
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+...