I think even building domain expertise is partially "permissioned" in so far that the engineer needs to be allowed to spent time on deep-diving problems. If he can only spend just enough time to find surface-level fixes, then it's more difficult to build the deeper understanding of the domain.
That's fair. I hear that complaint a lot. E.g. how do I work on the next level's behaviors if I'm buried in surface-level work. It's not always possible, I agree. I wrote some thoughts about it here: https://www.developing.dev/p/protect-your-time
It depends on the domain and skills they rely on. For instance, a specialist in video encoding technologies would be less effective if they switched over to AI.
There is a lot that transfers (e.g. general software skills + behaviors) though so I'd say it's not all lost and they'd still be strong engineers until they learned their new domain.
Engineers that operate in the "tech lead" role rather than the "specialist" role wouldn't skip a beat. More of their skills are transferable across domains.
Remember that “permissioned” doesn’t mean “sit around and wait for someone to give it to you”. There is action to be taken there! Definitely read Ryan’s How To Receive Scope, it adds a lot of value. 👏🏼
“Some of the strongest engineers I know chase problems further than anyone else because they are curious to understand the root cause.”
Sometimes it’s not about being the smartest in the room. Sometimes it’s about continuing to dive in, asking the questions no one else is, chasing your curiosity, and pushing through until you find things.
Fantastic insights, Ryan! Your breakdown of why most engineers aren't considered "10x" is spot-on. The combination of deep domain expertise and impactful influence sets them apart. Your distinction between "permissioned" influence and "permissionless" domain expertise provides a clear roadmap for aspiring engineers. Building expertise through curiosity is a gem of advice – the relentless pursuit of understanding root causes can truly set engineers on the path to solving unique problems. Congratulations on hitting 42,000 readers – your valuable content is clearly resonating with the software engineering community!
Love the classification between "permissioned" and "permissionless". Never had this perspective about the traits you described.
Thanks for sharing!
Happy to! "permissionless" growth is the most motivating in my opinion
I think even building domain expertise is partially "permissioned" in so far that the engineer needs to be allowed to spent time on deep-diving problems. If he can only spend just enough time to find surface-level fixes, then it's more difficult to build the deeper understanding of the domain.
That's fair. I hear that complaint a lot. E.g. how do I work on the next level's behaviors if I'm buried in surface-level work. It's not always possible, I agree. I wrote some thoughts about it here: https://www.developing.dev/p/protect-your-time
Does that imply that being a 10x engineer is in large part contextual? If a 10x engineer changes careers or domains, do they lose their edge?
It depends on the domain and skills they rely on. For instance, a specialist in video encoding technologies would be less effective if they switched over to AI.
There is a lot that transfers (e.g. general software skills + behaviors) though so I'd say it's not all lost and they'd still be strong engineers until they learned their new domain.
Engineers that operate in the "tech lead" role rather than the "specialist" role wouldn't skip a beat. More of their skills are transferable across domains.
Thanks Ryan for sharing this! In my opinion, the most straightforward way to gain more influence is to lead by example.
Agreed, leading by example is a great way to build credibility
Remember that “permissioned” doesn’t mean “sit around and wait for someone to give it to you”. There is action to be taken there! Definitely read Ryan’s How To Receive Scope, it adds a lot of value. 👏🏼
Although "permissioned" isn't fully in our control, you can increase your chances a lot by building a solid track record
This 👏👏👏
“Some of the strongest engineers I know chase problems further than anyone else because they are curious to understand the root cause.”
Sometimes it’s not about being the smartest in the room. Sometimes it’s about continuing to dive in, asking the questions no one else is, chasing your curiosity, and pushing through until you find things.
Awesome message, Ryan – thanks for sharing.
Happy to, curious engineers learn the most!
Fantastic insights, Ryan! Your breakdown of why most engineers aren't considered "10x" is spot-on. The combination of deep domain expertise and impactful influence sets them apart. Your distinction between "permissioned" influence and "permissionless" domain expertise provides a clear roadmap for aspiring engineers. Building expertise through curiosity is a gem of advice – the relentless pursuit of understanding root causes can truly set engineers on the path to solving unique problems. Congratulations on hitting 42,000 readers – your valuable content is clearly resonating with the software engineering community!