When faced with difficult problems, there is a very large difference in effectiveness between engineers. And it's not a one-dimensional scale, a brilliant engineer in one area can be quite average when solving different types of problems due to lack of context/domain knowledge/experience.
I tend to agree that lateral thinking can be a real advantage, but the vagueness of both OP and this post sort of grind my gears.
Who won against unfavorable odds and how?
I don't know if this meets your criteria for winning against unfavorable odds or not, but it does seem like that team was punching far above their weight class.
If you were on that team I would be absolutely riveted to learn more.
Were you on that team?
Am I interpreting this correctly as sarcasm? If so, it seems to suggest that the product was overvalued, the acquisition a mistake, and the "success" more to do with luck or duplicity than "lateral thinking", "high performance individuals/teams", or similar ideas brought up by the OP.
Those folks were bright hackers to be sure, but these days the best marker of a bright hacker or someone who intends to be is that they hang out on here.
You can look up my join date if you want, it’s a long time ago, but when I joined up on here I was green as grass and in this field experience, practice and hard work are at least as important to outcomes as native talent.
If you ever want to bat an idea around: ben dot reesman at gmail.
You had me up to this point. Great satire!
Most breakthrough progress I observe come from doing things that are conventionally considered impossible, low impact or just bad decisions. But the person/team had an insight to make it possible and wildly profitable.
If you look around, it happens all the time. Google famously made search useful; TikTok found an edge in low quality short form videos, despite all existing major players concluding high quality long form videos is the way.
Keep in mind that the contrarian vision and initial implementation is just the start, they needed continued investment and innovation to stay ahead of competitions, or get copied and leapfrogged.
In my experience, high-perming teams are those which are built to allow creativity. High emotional safety to express ideas and concerns, evidence-driven reasoning, dedicated time for experimentation, open discussions on just about any topic, nobody pulling rank to get their will done, etc.
Good leadership, consequently, is nudging people toward being that sort of collaborator.
Critically, I believe all people are creative. Or rather, useful creativity is a serendipitous meeting between situation and person. Whenever I'm at a loss for how to solve a problem, asking more people has always been the right answer. There's always someone who can think of a high-value solution to a tricky problem, and it's almost never the person I'd expect to.
Of course, this requires that your goal is to solve problems effectively. For many people, the goal is playing politics and looking good. Then you want the opposite approach. Keep information to yourself and force others to go with your ideas.
Perhaps the closest thing I've seen to a "lab" that might begin to experiment intelligently with abstract leadership ideas is something like YC, which is in position to iterate on the expensive, difficult, messy game of tech business leadership, because they have a privileged position to see what works, what doesn't, and what the limits of those observations are. And I would bet that even after ~2k companies (or whatever it is) no-one in their right mind at YC would think they've seen it all. They have, at best, a set of good heuristics. Not great, just okay.
From the IC perspective, high perf means the ability to modify the product quickly and surely, while making practical trade-offs using sound judgement about the larger context of the work, by manipulating the code and code meta data (e.g. bugs and features). These systems are highly complex especially analyzed across ~20 dimensions of performance, and success often means guessing which dimensions to care about and which to leave to their own devices. If there is a systematic error mode in an IC its when your prioritization scheme is wrong because it's ossified, or because you're unlucky.
Buying kimono and black belt does not make one good at martial arts - reading about leadership will not make someone a leader.
Which makes me think about Dwight Shrute type of people.
I have noticed a combination of examples that confirm and reject this. Speaking for myself and some of the colleagues whom I consider good developers: none of us want to deal with the official responsibility that comes with being a leader so we don't want to step into that role. On the other hand our manager is an excellent developer and super sharp individual and he seems to have boundless energy for leader-type activities - the kind that just thinking about makes us feel weary. My (unsubstantiated) theory is that it comes down to a combination of culture+work ethic+ambition+grit: just putting one's head down and getting stuff done, irrespective of whether it is creative or enjoyable. Of course, our manager gets paid very very well so that, at least partially, makes up for the trouble.
I suppose at the end of the day I'd like to understand how you can read a manual like "How to win Friends and influence people" while still maintaining high standards of quality and integrity. Because it seems like most people read books like that and become spineless manipulative dishonest people. I've come to prefer the honest, harsh judgments of technologists to the constructed speech you often get from leaders. I would be thrilled to work with a leader who can somehow square that circle.
Even in web pages, compare the slickness of lichess.org to chess.com. The former is elegant, individualistic and non-corporate, the latter has the hallmark of too many meetings and divided "team" work.
We get that sometimes management labels a code slinger a 10x engineer, especially if he is also good at conference presentations. This, however, is not the definition on HN.
I've certainly seen more group efforts turn into Rube Goldberg machines than efforts of single persons. The group may understand the Rube Goldberg machine, tell management that the code is perfect, but it is still horrible for outsiders (sometimes deliberately).
Whereas chess.com made 2 million USD in revenue last April. Obviously, with that revenue, you have dozens of individuals pulling in different directions wanting to prove themselves and trying to make the platform "better".
So the former is a bazaar. The latter a cathedral. Non comparable.
Isn't that exactly the comparison being made? A "10x" engineer can build a cathedral alone that does what you would otherwise have to hire a whole bazaar of engineers to replicate, at much higher cost.
(Pedantry: You're actually confused on the metaphor here. The Cathedral and the Bazaar was about development methodology, not individual performance. In fact a centralized, corporate product like chess.com would almost certainly be labelled a "Cathedral" by ESR. A "bazaar" is a project built of high-value individual contributions regardless of origin. Whether lichess qualifies or not, I don't know.)
2) I've been at startups that need 10x engineers, and ones which don't. There are technically boring problems to be solved 10x engineers won't work on (and won't be 10x at). Many of those can be very lucrative. There are technically hard problems which will never be solved without a 10x'er.
I hate this kind of generalization and generic advice. If you're writing a medical patient record management system, the right toolkit, organizational structure, recruiting, etc. is very different than if you're doing build an autonomous robotics startup, which is in turn different from writing a mobile operating system, which is different from a mobile, social video game.
- Inventory management systems
- Employee records systems
- Health care records systems
Most of this work is about:
- Managing legacy tools and systems, much of which is diving into some complex mess for a few days to change one line of code
- Managing odd-ball one-off use-cases. If the customer has coupon code X, and is in Minnesota, do Y. If an employee was laid off on the last day in February in a leap year, do Z. Etc. These glum on and make spaghetti, and a lot of coding is just about getting stuff like this done.
- Long, boring meetings
- Documentation and, if you're lucky, test infrastructure
- ... and so on.
Technical performance matters a lot less than a whole bunch of other skills, and in most cases, hiring criteria are often "has a pulse." Most such systems use an "enterprise" stack (e.g. Java+Oracle or Microsoft tools).
I’ve worked on teams where there was a hood ornament manager and the real manager, usually carrying a Tech Lead semi-title.
Interestingly enough I’ve seen both be effective, but it’s a hell of a lot easier in the former case.
The rest of the time I just try to slog through the work and maybe take a moment here and there to be a 1.1x strategist.
I try to get all my mentees to be brilliant for a minute a day and just show up and complete all the work the rest of the time.
The thing with these fluffy observational posts is that it’s rarely if ever concrete: here’s the Goliath to our David, here’s the advantages we leveraged to get the drop on the better-resourced, ostensibly smarter competitor, here’s how we opened the door with the slender bit of the wedge, and this is how we maintained cohesion and momentum to ram it right up Goliath’s ass.
Anything short of that is fucking whiffle-ball and is a waste of pixels on HN’s front page.
Let’s hear the actual story about how your scrappy and creative and cohesive group left the big enemy with a broken jaw. Otherwise, yawn.
In a word, it's subjective.
As we move through life we humans enjoy extracting pithy and broad nuggets of wisdom from our experience as we introspect. Occasionally they are even generally true! But as I've grown a little less naive I've come to appreciate that most broad observations, as convincing as they may appear, are usually incredibly subjective - to the originator (among which I include myself) they make 100% sense, but devoid of the context from which they derived (as they are often presented) they are usually little more than noise.
It's the horrible gnarly truth of the world that we must become comfortable with to stop making these oversimplifications. </ armchair philosopher>
Getting a job at RenTech is easier than winning the Nobel or Turing, but harder than getting a job anywhere else.
Getting a job at hardass backend FAANG is easier than getting a job at RenTech, maybe about as hard as getting into an Ivy with undistinguished parents.
Hitting that top 1-3% performer at FAANG is harder than completing a PhD at Stanford or Cal, but easier than selling a YC startup for 500MM+.
People want it to be subjective so that 0,0 can be in sight of wherever they are, but I know damned well that I’d flunk a RenTech interview, and even more so that I’ll never win the Turing.
There’s a lot of structural nuance and important details but it was an absurdly elite group of people who hadn’t been disillusioned yet and we forced Google’s jaws open wide enough that there are now 2 panopticon ads businesses instead of 1.
Antonio García Martínez wrote a great book about it called “Chaos Monkeys” if you’re a long-form reader.
High Performance Individuals and Teams - https://news.ycombinator.com/item?id=25118762 - Nov 2020 (73 comments)
If you can schmooze with stake-holders, explain esoteric subjects to non-technical people in a simple manner, and are pleasant to be around, _on top of_ being able to grok basically any code, you're "10x"
Being able to navigate the Byzantine hallways of high-stakes executive politics, even more.
Being able to do both without flashing a “neuro-atypical” badge in any public way? You’re making 10-50MM a year.
Consensus around here tends to be that’s a lot more than 10x. So unless the market is utterly busted (which implies an exploitable arbitrage), the notion of a “10x” engineer is way low.
What do you reckon Carmack makes when he chooses to work? I bet it’s a lot more than 10x the median.
Great engineer = 1 golden egg per day, or 3 clay eggs per day.
Average engineer = 1 clay egg per day, or 10 days for a golden egg.
To maximize productivity you hire average engineers to produce the clay eggs.
If people do this it will be obvious to future employers.