I've been called a 10xer before, and I'm the only one in my company currently at that level. We're a data company first and software second.
Trainings don't work. What does work is pair programming but you have to do this effectively. Say you have 3 buckets, frontend, backend and infrastructure. Ideally, you want to pair someone who has very full infrastructure and backend buckets, with someone who has an overflowing frontend bucket. Mix and match. There's no value in pairing two more backend oriented engineers together.
There's also no value in categorizing things in frontend and backend, if you just have a frontend engineer that throws things over the hedge to the backenders garden, you're going to have a shit shoveling contest and this doesn't work. Of course, you should still have people specialized in certain domains, but you should try to share knowledge within your team as much as possible and try to broaden's people experience instead of having people work on their own little islands. Pair someone with a backend background on a big frontend ticket with an experienced frontender and before you know it you'll have two full stack engineers that'll possibly grow to become a "10x" or whatever that means.
Code reviews are critical and it's important to have someone in your team that carries a big stick and isn't afraid to use it. This is a sensitive thing I've noticed, I've worked at companies where I wasn't the only 10x engineer, and the code reviews there were a joy because I was getting very valuable feedback. It wasn't so much that my code was wrong, but more something like `{} as MyInterface` could also be written as `<MyInterface>{}`. There were a lot of style related comments. What I notice in my current team is that people feel like this is unnecessary, but I always felt like it is valuable when another engineer suggests something like "maybe you could abstract this?" because it introduces a bigger picture that I may not have thought of before. It's very loathsome to carry the big stick, but I feel like if I dont, we're going to go back to the old patterns of not writing tests, not thinking about architecture.. Those kinds of things.
You said a lot of things, many I agree and have experienced as well, but never answered OP. How do you create 10x engineers? Well you can’t. And you probably shouldn’t try. If you’re 10x somewhere it means you’re at a place with a significant (I.e. 10x) skills mismatch between people in the team. It’s not fun for anyone, the company and team become too dependent on you, and you skew any ability to project how long work would take on both sides by your presence.
The best bet for both parties would be they find places “where they belong” - if you consider yourself 10x ie the smartest person in the room, you need to seek a better room for yourself where that’s not the case.
But that is the answer, in that there is no answer :) And agreed, it is always a mismatch. But I do think that with what I said, that'd be the foundation to create a 10x engineer. That's how I became one, because I was matched with people of that skill level and got to work directly together with them for years. And if I'm 10x by my company's standards, go figure how good those guys were ;)
You're right in a way, but you're missing the "10x compared to what?". Consider the 1x baseline as being the median productivity of your development team (which is definitely hard to approximate, but for the sake of the exercise let's take 'value-added tickets per developer' [which excludes bugs/rework]). Then the goal is to do 10x on this median in a reasonable amount of time. Rince and repeat.
Trainings don't work. What does work is pair programming but you have to do this effectively. Say you have 3 buckets, frontend, backend and infrastructure. Ideally, you want to pair someone who has very full infrastructure and backend buckets, with someone who has an overflowing frontend bucket. Mix and match. There's no value in pairing two more backend oriented engineers together.
There's also no value in categorizing things in frontend and backend, if you just have a frontend engineer that throws things over the hedge to the backenders garden, you're going to have a shit shoveling contest and this doesn't work. Of course, you should still have people specialized in certain domains, but you should try to share knowledge within your team as much as possible and try to broaden's people experience instead of having people work on their own little islands. Pair someone with a backend background on a big frontend ticket with an experienced frontender and before you know it you'll have two full stack engineers that'll possibly grow to become a "10x" or whatever that means.
Code reviews are critical and it's important to have someone in your team that carries a big stick and isn't afraid to use it. This is a sensitive thing I've noticed, I've worked at companies where I wasn't the only 10x engineer, and the code reviews there were a joy because I was getting very valuable feedback. It wasn't so much that my code was wrong, but more something like `{} as MyInterface` could also be written as `<MyInterface>{}`. There were a lot of style related comments. What I notice in my current team is that people feel like this is unnecessary, but I always felt like it is valuable when another engineer suggests something like "maybe you could abstract this?" because it introduces a bigger picture that I may not have thought of before. It's very loathsome to carry the big stick, but I feel like if I dont, we're going to go back to the old patterns of not writing tests, not thinking about architecture.. Those kinds of things.