Hacker News Reader

Comment by kozikow | Hacker News Reader

Story of two engineers in a team I worked with.

P is what most people would consider 10x engineer (but not this article). Can get anything done few times quicker than anyone else. It's like 10 junior engineers stacked in one person. But it often would be unmaintainable mess.

M is a lot like article describes. Understands what needs to be done and creates good technical designs. Often unf*s mess created by P. Delivers business value. Do not write a lot of code.

It's funny that depending on whom you ask, M or P would be the 10x engineer and other would be the bad engineer. Real 10x engineer can wear the M or P hat depending on circumstances.

View on HN

I much rather have no 10x engineer on my team, but instead engineers who do just a bit more than the bare minimum.

For example, who don't just test their single use case, but check if it breaks anything around it. Or who invest just a tiny bit more time to actually write down what their bug analysis has yielded. Or who update the documentation after an interface change. Or who write solution designs to think about the approach, before hacking some ugly mess. Or who check with the PO or user if the chosen approach/design is what they expected. Or who ...

In my experience having devs who do more than the bare minimum is way more productive for most day-to-day business. Maybe there's room for a powerhouse in cases, where you have to drastically restructure a code base and quickly create some PoC.

Every business I've ever been at had a "strike team" of the 2x+ engineers (in the M sense) that didn't typically do maintenance work, they unfucked messes or rescued projects. It seemed pretty effective from my standpoint.

I wonder if it woudl be better to think of it as the the 10X team, rather than a single 10x developer.

Im still studying CS so I'm probably way off base,but it seems far more realistic, and usefull.

There are definitely 10X teams in that sense. Two problems:

(1) Very few corporate compensation programs are team-oriented; managers are structurally forced to reward/punish individuals, not teams. In many cases there is even some sort of forced distribution that requires the manager to punish someone on the team regardless of performance. This makes it counterproductive to attempt to construct a uniformly high-quality team in the first place.

(2) The organizational friction encountered by a 10X team is the same as for a 10X developer, only much larger in scope, thus more expensive and visible. A 10X developer might want to write a bunch of unit tests; a 10X team might want to swap out the entire CI/CD system and reorganize their relationship with product management.

Reply on news.ycombinator.com