How to be a -10x Engineer

From a bit ago:

We fired our top talent. Best decision we ever made. - https://www.freecodecamp.org/news/we-fired-our-top-talent-be... ( https://news.ycombinator.com/item?id=15474893 125 comments; https://news.ycombinator.com/item?id=32211953 30 comments)

> “You will never be able to understand any of what I’ve created. I am Albert F**ing Einstein and you are all monkeys scrabbling in the dirt.”

> And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde.

> He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed.

And then follow up:

A team reborn after the fiery departure of its misanthropic guru - https://blog.solha.co/life-after-rick-our-team-reborn-after-...

What about the 0.01x Engineer? Much easier to achieve I think: do as little as possible without getting caught.

Plus, conversations are synchronous. If it's just one person explaining to another, it's no so bad. But what if that person needs to explain it to five or ten people? Do you have multiple 1:1 conversations or try to schedule a meeting at a time everyone is available?

Most of these are either management issues or written as if the person is acting in bad faith. But there are plenty of engineers who are 1) smart 2) driven, and 3) well-meaning that still find themselves in this position

One time I found myself in this position was overseeing an infrastructure migration for scaling reasons. The goal was to have it done before we hit scaling limits, and we had a team of 2 people and a fairly complex architecture. From the start, I suspected it might be difficult to do with the current staffing, even after extensive planning, but I underestimated what the costs would be to not completing the project on time.

I was told by my manager that completing the project before hitting scaling limits was life or death for the company (it wasn’t, I know this because the sales team didn’t hit their targets and we survived). I now realize this was my manager attempting to motivate me to take on a tough project, rather than real truth. Had I pushed back harder, inquired about company financials, this would have been exposed as not true.

While we eventually ended up completing the project, we completed our largest phase of hiring while in limbo between 2 architectures. The company became disorganized, accepting large amounts of tech debt as it was tough for new hires to understand what the “correct” thing to do was, and many people ended up adding to the legacy architecture in cases where they didn’t need to. It was a mistake that likely cost millions, even tens of millions in my eyes.

The correct thing to do, of course, was just to insist that we couldn’t scale until we trained or hired more people to help. Limiting growth is often seen as unacceptable in startup culture, but IMO should be considered more often.

> Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity.

The promise of "agile" is, IIRC, faster turnaround and iterative development. Yes, the 'wrong' thing is expensive. Getting something basic in someone's hands in 2-3 days to get some feedback is usually more productive than days of figma then 'sign off' then work work work then putting it in hands and getting back "this is wrong" (missing data, etc). Sometimes those things can be found in 'design-only' sessions, but I've rarely seen it happen where lots is found there, then things are implemented perfectly afterwards not requiring any further changes.

Much depends on the size/scope of the work, and I don't think there's one-size that fits all, but the ticketization of work process as teams grow pushes towards "one true way", which then seems to paper over a lot of cracks that don't easily show up in burndown charts.

That 15 or 30% might be the time ultimately taken on thinking/planning/etc of a specific issue, but too often it seems there's an idea of doing more up front "gets it done" and the notion of fast feedback/iteration cycles is glossed over, and you're expected to "get it done" - "all the planning was already done".

When doing dev-type work, I always end up needing to iterate with endusers/stakeholders, and there's little 'up front' that could have been planned to avoid some of that. It may be the nature of the people/teams I've worked with, though.