(Of course, it goes without saying that his process is highly adapted to his context (US, hard database problems); if I were to apply it to Singapore or Vietnam, it would need to be modified. But that's true of every practically useful thing.)
Conversation
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
On the contrary: if you find a technique that allows you to reduce management problems earlier in the value chain, you should test that first, instead of settling for downstream techniques. (This is a core principle in Grove's High Output Management; and it's really useful.)
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
Actually, I disagree on this. 'Technical taste' is not that difficult to evaluate if you're a decent programmer.
In my prev company, you could ask engineers "rank colleagues according to acumen" and come to a consensus pretty quickly (with maybe slight disagreements).
1
Replying to
And the understanding was built from "who is least likely to come up with a systems design that will bite us in the ass in a couple of months."
I wasn't in the top 2, just fyi. Which was why I always deferred on certain technical design decisions.
1
Replying to
Slava's context was that he built RethinkDB — which took on MongoDB directly. Databases are hard technical products, and so I get why he's using his process.
I wouldn't personally use such a rigorous process. But I would definitely try out his 'judgement' filter.
1
Replying to
Also, the 10x engineer discussion is irrelevant here. It's not useful. In practice, we worked backwards from what we *needed* in our company to a hiring process that optimised for those needs. e.g. We needed people who could embed with customers, so you can imagine the reqs.
1