4 ms·
The core insight-- that mediocrity and failure provide about the same payoff (zero) in a modern technological economy-- is accurate. Here's where the divergenc
by michaelochurch 14y ago
The core insight-- that mediocrity and failure provide about the same payoff (zero) in a modern technological economy-- is accurate.
Here's where the divergence happens. Being a top performer requires a lot, and not all of it's intrinsic. Fit with tools and project are important, and so are relationships. There aren't intrinsic A and B players. For example, most software projects have one or maybe two "blazers" who write most of the new code and make the important decisions, and many more who spend the bulk of their time keeping up. It's a lot better for your career to be in the former category; get out if you're in the latter. This is what language and tooling wars are often about in companies: people wanting to change the landscape so they can be the trailblazers and the others end up as the followers. This is why it's economically worth it (in a corporate context) to invest so much energy into tooling and language fights instead of on the work itself: if you win the battle, the leverage it applies to your work is immense. The truth is that most projects have a rank ordering that becomes self-perpetuating, because the high-ranking people take the best work and progress faster. There isn't one global equilibrium where the "best" people are magically matched to the best work, but N! stable equilibria, where N is the number of participants.
Why is this important? Well, the correct insight is that the payoff curve (between input factors and output) is now convex. In a concave world, you wanted to manage toward the middle: reduce variance, bring up the slackers. This is what management is good at: bringing everyone in to the middle of the performance curve. That's also why traditional management is failing in the technological world. Maximizing a concave function is equivalent to minimizing a globally convex one, which is the easiest class of optimization problems (there's one global optimum). For these, incremental evolution (gradient descent) works: you converge to an optimal solution (in economic terms, an equilibrium). It's not equipped to handle the convex world where there are zillions of possible local optima and non-local insight is required in order to find better solutions.
What's inaccurate is the idea that there are "intrinsically" mediocre vs. excellent people and that the former should just be discarded. Why do we have to stay in school until we're in our mid-20s? Because our economic contributions are worthless until we've had an amount of schooling that would be considered immense by historical standards. The reason for all this schooling is to increase the probability of a person ending up as a "10x" contributor in an economy that has no place for 1x contributors.
As for stack ranking, that's something separate, and it's actually harmful to the top performers. Stack ranking is about intimidation-- nothing else. The idea is ancient: Romans called this method of intimidation and punishment decimation. Split the regiment into groups of 10, of which one will die. Sometimes it was random (drawing lots) and sometimes the groups voted. The reason for the 10% cut was because (a) it's not enough of a force reduction to "disrupt continuity" but (b) it was large enough to scare the shit out of people. People use "decimation" as a synonym for "devastation" but that's not correct, because "decimation" is a controlled, small reduction of force. Stack ranking is the same concept, but with political infighting used instead of randomness to make the decisions, and the "divide-and-conquer" campaign it wages against the proles is intentional.
Intimidation's effect is performance-middling. It kills creativity and innovation, and the top performers suffer, but it brings the slackers closer to the median. Traditional, intimidation-based management worked well in a concave world where people were mostly doing low-margin commodity work and one slacker could cancel out 5 good workers, but it fails catastrophically in the convex world.
- lucisferre 14y agoAre you suggesting that different languages and tooling would make different players on the team 'A' players? Sorry, but I find this to be an extremely dubious claim. At the risk of coming off as a completely arrogant ass, I've been an 'A' player in two completely different language, stack and tooling environments so far. Now I find myself shifting the lion's share of my coding time from back-end to front-end work, but aside from an initial adjustment period, I don't find this to be a huge hit to my productivity or effectiveness. I'm pretty confident most other 'A' players can do the same easily, probably more easily than I can. Am I unhappy in an environment that forces to use tooling that I find to be unproductive, sure. I've been here before, but nonetheless I was still one of the 'A' players. A players are not different because of having the right fit with tools or projects, or because of more (or less) education. They are different because they have a good fit with their purpose combined with passion for what they do.
- michaelochurch 14y agoAre you suggesting that different languages and tooling would make different players on the team 'A' players? Sorry, but I find this to be an extremely dubious claim. It depends how far apart they are. Having written the code is a huge advantage. Getting to write code is a major advantage (if most of your time is spent reading code, your odds of transferring to a new-dev role on the same team are low). Picking tools that one knows well is also an advantage, but probably less of one, because there are far crappier corporate codebases than in-use open source tools (in general). If the people are very far apart in ability, then those kinds of changes won't permute the ranking... on the other hand, if there's that much spread among programmers of equal rank, then you have an unusual team and a recipe for chaos.
- arohner 14y ago> It depends how far apart they are. Totally disagree. A level programmers are almost by definition, A level programmers in every language they've ever encountered. For B level programmers, you're right, it's worthwhile to play tug-of-war on languages and tooling.