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
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.<p>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?<p>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?<p>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.
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.
Hiring top talent is both hard and costly.<p>So many companies hire just a few top talents and fill the rest of positions with average guys.<p>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.<p>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.<p>There is a big problem if those top guys are gone.
Is there anything in that post that supports this theory?<p>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.<p>Granted that's all very difficult to measure / defined, but I've found that to be the case personally.<p>There's so much focus on hiring "the best" I'm not sure that's where the issues are.
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.<p>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.
> 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.<p>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.<p>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.<p>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.k.a. the dead sea effect: <a href="http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/" rel="nofollow">http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...</a>
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.<p>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 is really interesting and I once heard about something similar in terms of a tax system.<p>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.<p>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.
This is a management hiring issue.<p>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.<p>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.<p>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.<p>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.
Those are big and bold claims with no data to back them up.<p>Here are two mental models I used successfully to reason about teams.<p>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.<p>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.<p>[1] <a href="https://www.google.com/search?q=dead+see+effect&oq=dead+see+effect&aqs=chrome..69i57j0i13l5j0i22i30l3j0i15i22i30.2658j0j7&sourceid=chrome&ie=UTF-8" rel="nofollow">https://www.google.com/search?q=dead+see+effect&oq=dead+see+...</a>
"Talent cooling" – the phenomenon where development slows because smart people leave <i>en masse</i> – isn't new. It's more broadly known as "brain drain."
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.<p>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!)
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!"
Similar to how cults are forming and then reinforcing: <a href="https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-cooling-of-group-beliefs" rel="nofollow">https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporativ...</a>