May 5, 2022·edited May 5, 2022Liked by Listiarso Wastuargo
Nice article on 10x (as an S.E. grad).
Observation: There are only two major types of 10x. Generalist and PM Hybrid belongs on class A engineers (Product, Organization, Broad Skills), Specialists and Fixers belongs on class B engineers (Mentoring, Debugging, Narrow Skills). The weirdness is that class B sounds like the David Graeber's definition of BS Jobs (especially the Duct Tapers), whilst being promoted on LinkedIn a lot,as they are overspecialized and corporate dependent. Class A sounds more plausible as the startup 10x developer, but they are interpreted by the same LinkedIn crowd as "jerks".
Question:
1. Instead of identifying 10x engineers, how can one identify a 10x-friendly company/manager (or the inverse)?
2. How does one rectify the need of 10x engineering sessions vs Kaizen principles? Also, the differentiation of 10x in reference to CTO vs Middle Management vs "rank-and-file" programmers?
3. People has joked about the 100x and 1000x engineer, is that even possible?
4. What are the basic triats of a potential 10x engineer?
I do agree that class B depends on corporate while class A are more versatile. Tho after working with a lot of people I believe there are people who are hardwired differently (i.e. no matter how long, how many different mentors, how many different companies, they can't become class A). Hence these "categorization" is useful to let the reader identify "hey, I belong to these. It might be a good idea to double down here"
Answers to the question:
1. Very interesting question that makes me wonder myself. I'd imagine I'd ask the following question in interview: "how are software engineers evaluated?"
1.a. if they say: "by speed of delivery" or "by line of code written" or "by their productivity" -> run as far as you can.
1.b. if they say: "by amount of bugs and SLA" -> ask their numbers and ask who are their top engineers look like.
1.c. if they say: "by their contribution to the company metrics" -> ask what does their top engineers do day to day. Do they analyze metrics? Are engineers seen as cost center or innovation driver?
2. I don't see 10x engineer and Kaizen (continuously improving) as 2 distinct separate concept. Sure 10x engineers make less mistake. But there are times 10x engineers need to make continuous mistakes as part of experiment. The difference at this point between 10x engineers and the normal ones are that the mistakes are intentional (we do foresee that mistakes will happen, but we don't know what they are), and they learn and fix it fast. This means being sensitive to changes and be able to react quickly (vs throwing things to the wall and see what sticks)
3. I've seen engineers who can enable 100x engineers (building infra/abstraction, derisking huge projects, enabling new area of investment). I have been the enabler and multiplier for those 100x engineer. But I personally don't see them as 100x more effective/efficient engineers (i.e. having them is better than having 100x engineers).
> "by their contribution to the company metrics" -> ask what does their top engineers do day to day. Do they analyze metrics? Are engineers seen as cost center or innovation driver?
This will need some extra explanation in later articles
> I don't see 10x engineer and Kaizen (continuously improving) as 2 distinct separate concept.
It is that 10x is more heterodox on key players, whilst Kaizen is more whole-term orthodox. Similar to the middle management vs senior management, or A Players vs B Players. Are there any diagnostics to see who are the "potential 10x" developers rather than the "rank-and-file"?
Nice article on 10x (as an S.E. grad).
Observation: There are only two major types of 10x. Generalist and PM Hybrid belongs on class A engineers (Product, Organization, Broad Skills), Specialists and Fixers belongs on class B engineers (Mentoring, Debugging, Narrow Skills). The weirdness is that class B sounds like the David Graeber's definition of BS Jobs (especially the Duct Tapers), whilst being promoted on LinkedIn a lot,as they are overspecialized and corporate dependent. Class A sounds more plausible as the startup 10x developer, but they are interpreted by the same LinkedIn crowd as "jerks".
Question:
1. Instead of identifying 10x engineers, how can one identify a 10x-friendly company/manager (or the inverse)?
2. How does one rectify the need of 10x engineering sessions vs Kaizen principles? Also, the differentiation of 10x in reference to CTO vs Middle Management vs "rank-and-file" programmers?
3. People has joked about the 100x and 1000x engineer, is that even possible?
4. What are the basic triats of a potential 10x engineer?
Thanks for the thoughtful comment.
I do agree that class B depends on corporate while class A are more versatile. Tho after working with a lot of people I believe there are people who are hardwired differently (i.e. no matter how long, how many different mentors, how many different companies, they can't become class A). Hence these "categorization" is useful to let the reader identify "hey, I belong to these. It might be a good idea to double down here"
Answers to the question:
1. Very interesting question that makes me wonder myself. I'd imagine I'd ask the following question in interview: "how are software engineers evaluated?"
1.a. if they say: "by speed of delivery" or "by line of code written" or "by their productivity" -> run as far as you can.
1.b. if they say: "by amount of bugs and SLA" -> ask their numbers and ask who are their top engineers look like.
1.c. if they say: "by their contribution to the company metrics" -> ask what does their top engineers do day to day. Do they analyze metrics? Are engineers seen as cost center or innovation driver?
2. I don't see 10x engineer and Kaizen (continuously improving) as 2 distinct separate concept. Sure 10x engineers make less mistake. But there are times 10x engineers need to make continuous mistakes as part of experiment. The difference at this point between 10x engineers and the normal ones are that the mistakes are intentional (we do foresee that mistakes will happen, but we don't know what they are), and they learn and fix it fast. This means being sensitive to changes and be able to react quickly (vs throwing things to the wall and see what sticks)
3. I've seen engineers who can enable 100x engineers (building infra/abstraction, derisking huge projects, enabling new area of investment). I have been the enabler and multiplier for those 100x engineer. But I personally don't see them as 100x more effective/efficient engineers (i.e. having them is better than having 100x engineers).
4. This is a tough one. There are a lot of traits I'd list. But if I have to narrow it down to one, I'd choose high-agency-ness: https://twitter.com/shreyas/status/1276956836856393728
> "by their contribution to the company metrics" -> ask what does their top engineers do day to day. Do they analyze metrics? Are engineers seen as cost center or innovation driver?
This will need some extra explanation in later articles
> I don't see 10x engineer and Kaizen (continuously improving) as 2 distinct separate concept.
It is that 10x is more heterodox on key players, whilst Kaizen is more whole-term orthodox. Similar to the middle management vs senior management, or A Players vs B Players. Are there any diagnostics to see who are the "potential 10x" developers rather than the "rank-and-file"?
Counter curiosities: some people say focus on the 3x Devs instead https://blog.accelerate.io/2018/04/10/2018-04-10-forget-about-10x-developers-focus-on-3x/
1. It is purely based on individual test performance on adaptability
2. It lacks explanations on benchmarking teamwork and social/negotiate skill
3. The 3x dev problem can be said as the "Midwit", "clueless", "Cheems Mindset" (something ethereal is missing, making this not antifragile)