How to Be a 10x Engineer: Execute in an Extreme Straight-Line(smalldiffs.gmfoster.com)
smalldiffs.gmfoster.com
How to Be a 10x Engineer: Execute in an Extreme Straight-Line
https://smalldiffs.gmfoster.com/p/how-to-be-a-10x-engineer-straight
22 comments
Agreed!
> "Do You Even Want to Be 10x? You don’t have to. You’re not a lesser engineer if you operate at a steady clip, write clean code, and value stable processes. Seriously. Some workplaces thrive on consistent, methodical improvement—and a 10x renegade might actually hurt them."
> "Do You Even Want to Be 10x? You don’t have to. You’re not a lesser engineer if you operate at a steady clip, write clean code, and value stable processes. Seriously. Some workplaces thrive on consistent, methodical improvement—and a 10x renegade might actually hurt them."
Plumbers do often use initiative and offer improvements over what the customer initially requested.
Of course, but the expectation wouldn't be "make my house better", it would be specific to plumbing and making the pipes work. It wouldn't make sense to expect them to add a guest bathroom because that's better for the house.
As an engineer — in other words: a salaried employee — you're already a businessperson. How do you negotiate for better total compensation or benefits if you reject knowing, and thus positively influencing, your worth to the company?
If you really don't want to engage in that sort of thing, I'm sure there's a lot of companies that'll let you be a fungible code monkey for pennies…
If you really don't want to engage in that sort of thing, I'm sure there's a lot of companies that'll let you be a fungible code monkey for pennies…
I get what you're saying but this is inherently a contradiction:
> As an engineer — in other words: a salaried employee — you're already a businessperson.
An engineer is NOT a business person. I don't recall business fundamentals in computer science classes... but I get it, most companies see full time employees as part of the business that they are responsible for.
The main problem I see is that it becomes an issue as to where the boundaries of the role is, and therefore pushes engineers away from their focus and that leads to more problems down the line. I've seen this so many times in my career and I can attribute it to the fact that orgs do not respect how hard engineering is, so they think they can have this role wear many hats, and then you have applications that are fragile and hard to work with. I get anyone can quit and find a better job, but that's besides the point. "Impact" is just a lazy way for businesses to define roles.
> As an engineer — in other words: a salaried employee — you're already a businessperson.
An engineer is NOT a business person. I don't recall business fundamentals in computer science classes... but I get it, most companies see full time employees as part of the business that they are responsible for.
The main problem I see is that it becomes an issue as to where the boundaries of the role is, and therefore pushes engineers away from their focus and that leads to more problems down the line. I've seen this so many times in my career and I can attribute it to the fact that orgs do not respect how hard engineering is, so they think they can have this role wear many hats, and then you have applications that are fragile and hard to work with. I get anyone can quit and find a better job, but that's besides the point. "Impact" is just a lazy way for businesses to define roles.
Do you receive financial remuneration for your services as an engineer? Then I'd say you're engaging in an ongoing business transaction. As such, the parties to the contract this is happening under will each evaluate whether continuing the existing business relationship is worthwhile.
You may think that this kind of deliberation is outside of the context of what being an engineer is, but it's certainly not outside of the context of what being an employee is. If you wish to be an engineer and not be saddled with business stuff, don't demand compensation, or only token compensation, which is what I alluded to at the end of my last post. In the context of business, all parties need to constantly prove that what they're providing is worth more than what they're asking for.
You can work at a company that asks for "impact", and be given a degree of agency for determining which problems are worth solving, and solve them, hopefully leading to increased revenue, reduced costs, or reduced risks. Or, you can not do that, do whatever Jira asks you to do next, and have no case as to why the company should give you more money or indeed continue to employ you in favor of another engineer who can demonstrate more of an "impact".
You may think that this kind of deliberation is outside of the context of what being an engineer is, but it's certainly not outside of the context of what being an employee is. If you wish to be an engineer and not be saddled with business stuff, don't demand compensation, or only token compensation, which is what I alluded to at the end of my last post. In the context of business, all parties need to constantly prove that what they're providing is worth more than what they're asking for.
You can work at a company that asks for "impact", and be given a degree of agency for determining which problems are worth solving, and solve them, hopefully leading to increased revenue, reduced costs, or reduced risks. Or, you can not do that, do whatever Jira asks you to do next, and have no case as to why the company should give you more money or indeed continue to employ you in favor of another engineer who can demonstrate more of an "impact".
Right, you are basically saying that because the company pays you, you are obliged to just do what you are paid for, and that can be literally anything within legal boundaries and the success of the company.
I acknowledge that, and I am also pointing out that it isn't very helpful as a goal for something that is meant to be a specialized domain. Telling them to "create impact" is borderline tautological. Obviously every employee needs contribute and make the business money, but it should be up to the stakeholders and leadership to be a little more specific as to what the goals are, and let the engineers focus on doing engineering.
For example, we see a lot engineers transition to management because of this kind of expectation that running the business is always the priority. This causes a lack of domain specific expertise which is filled with new engineers, which causes a lot of inconsistencies in the software systems, which creates complexity, bugs, slows down development, etc., and this costs a lot money, just because engineering is being underestimated in favor of doing more business-centric tasks.
I acknowledge that, and I am also pointing out that it isn't very helpful as a goal for something that is meant to be a specialized domain. Telling them to "create impact" is borderline tautological. Obviously every employee needs contribute and make the business money, but it should be up to the stakeholders and leadership to be a little more specific as to what the goals are, and let the engineers focus on doing engineering.
For example, we see a lot engineers transition to management because of this kind of expectation that running the business is always the priority. This causes a lack of domain specific expertise which is filled with new engineers, which causes a lot of inconsistencies in the software systems, which creates complexity, bugs, slows down development, etc., and this costs a lot money, just because engineering is being underestimated in favor of doing more business-centric tasks.
This exchange is fascinating to me, because I still feel like we're talking past each other.
I suppose it could be helpful to think of a job designation such as "software engineer" as sort of a shorthand for "businessperson whose toolbox is one of a software engineer" as long as we're in that employer-employee relationship, and if we want to exclude all the pesky business stuff from our daily doing, it cannot be in the context of that relationship.
This also means that all the usual problems of deficient software craftsmanship, such as inconsistencies, accidental complexity, faults, low velocity, and so on, aren't even problems as far as the employer is concerned as long as there is no impact to the business.
In a way, it's inconsistent of you to be concerned that any of these problems is going to cost the business money. Either you accept the task of deciding what's good or bad for business, or you don't.
Some devs who dislike actually engineering around time, money or risk constraints at work do open source stuff in off hours where that stuff doesn't matter. The one to decide if that's worthwhile to you is yourself. In the context of a business, engineering is simply a requirement to what's actually its goal, which is of course making gobloads of money, consistently, with minimal effort.
One thing that I can see though is that in many of these cases where engineering is asked to work on high-impact issues, engineering doesn't actually have all the information, or the toolset required to draw conclusions from it. In that sense, yes, demanding that from engineers comes across as a bit lazy. Nevertheless, it's not like you have to prove to e.g. Netflix that the service doesn't meet your requirements anymore: the onus is on them, and the same way it's on engineers to prove that their salaries are warranted. Of course, that goes both ways, and your employer can fail to meet your own requirements.
The option to have less agency is one that many employers will gladly grant you, but we are not married to companies, and these arrangements have to make sense for us as individuals as well. Hamstringing ourselves from being able to demonstrate our worth doesn't feel like the correct course of action, even if we care more about our produced engineering artifacts than even its buyer does.
I suppose it could be helpful to think of a job designation such as "software engineer" as sort of a shorthand for "businessperson whose toolbox is one of a software engineer" as long as we're in that employer-employee relationship, and if we want to exclude all the pesky business stuff from our daily doing, it cannot be in the context of that relationship.
This also means that all the usual problems of deficient software craftsmanship, such as inconsistencies, accidental complexity, faults, low velocity, and so on, aren't even problems as far as the employer is concerned as long as there is no impact to the business.
In a way, it's inconsistent of you to be concerned that any of these problems is going to cost the business money. Either you accept the task of deciding what's good or bad for business, or you don't.
Some devs who dislike actually engineering around time, money or risk constraints at work do open source stuff in off hours where that stuff doesn't matter. The one to decide if that's worthwhile to you is yourself. In the context of a business, engineering is simply a requirement to what's actually its goal, which is of course making gobloads of money, consistently, with minimal effort.
One thing that I can see though is that in many of these cases where engineering is asked to work on high-impact issues, engineering doesn't actually have all the information, or the toolset required to draw conclusions from it. In that sense, yes, demanding that from engineers comes across as a bit lazy. Nevertheless, it's not like you have to prove to e.g. Netflix that the service doesn't meet your requirements anymore: the onus is on them, and the same way it's on engineers to prove that their salaries are warranted. Of course, that goes both ways, and your employer can fail to meet your own requirements.
The option to have less agency is one that many employers will gladly grant you, but we are not married to companies, and these arrangements have to make sense for us as individuals as well. Hamstringing ourselves from being able to demonstrate our worth doesn't feel like the correct course of action, even if we care more about our produced engineering artifacts than even its buyer does.
If I understood correctly, you're effectively saying that the priority of a software engineer is the success of the business, and that their value is directly correlated to the amount of value they add to the business, and that it's on them to prove and justify this.
The main concept for me is how software engineering is a vehicle for increasing value to any business, since it's about information technology, which is based on automation.
> In a way, it's inconsistent of you to be concerned that any of these problems is going to cost the business money.
I don't see this as inconsistent because an engineer's value to the company should be implicit by the definition of the role.
I guess this is where my disconnect is. I don't see engineering like any other role, i.e. management. I see it as something that should inherently add value if done properly because of its very nature. This may sound like I'm glorifying engineering over other roles, but we're now talking about the possibility of AGI and *replacing* engineers with software made by other engineers, so there's something inherently different about it.
The original context of this was 10x engineers, and how they need to add value to the company, but what better way than to leverage the limitless automation of software to do so (as oppose to having them worry about the direction and details of the business)?
The main concept for me is how software engineering is a vehicle for increasing value to any business, since it's about information technology, which is based on automation.
> In a way, it's inconsistent of you to be concerned that any of these problems is going to cost the business money.
I don't see this as inconsistent because an engineer's value to the company should be implicit by the definition of the role.
I guess this is where my disconnect is. I don't see engineering like any other role, i.e. management. I see it as something that should inherently add value if done properly because of its very nature. This may sound like I'm glorifying engineering over other roles, but we're now talking about the possibility of AGI and *replacing* engineers with software made by other engineers, so there's something inherently different about it.
The original context of this was 10x engineers, and how they need to add value to the company, but what better way than to leverage the limitless automation of software to do so (as oppose to having them worry about the direction and details of the business)?
I think what we are really talking about right now is essentially a pair of jobs that, though both called "software engineer", are vastly different in scope.
One of them is a software developer who basically does just that, implement requirements. To enable an engineering department with this type of developer, management needs to already have developed a pretty good view on the business processes that could benefit from automation, or that could become feasible in the first place through software. It is understood that a 5% improvement on the critical path can be more difficult, yet still more worthwhile than a 50% improvement in some less important part of the system. To gain this understanding, management needs to know what is technically possible and perform lots of requirements analysis. After that, well-defined work packets can be handed down to rank and file engineers, and then everyone is on their merry way.
The other kind of software engineer performs most of this support work on their own. Such an engineer has additional responsibilities, but can be useful in many more places because the surrounding support structures don't need to exist. You might not even have to give them specific guidance. However, it means that to use this kind of engineer effectively, you have to expose them to accidentals like time, money and risk, or they will not be able to accurately assess where their talents would be most useful.
Many organizations will actually have both types of engineers. But invariably, the perception of how valuable they are will be heavily skewed in favor of the latter kind of engineer. In the hands of management, they handle like a chef's knife, while the "pure" type of engineer would feel more like a cookie cutter. Even the sharpest, most efficient and most perfect cookie cutter will have a hard time to be perceived as more valuable than a reliable multi-use tool that needs next to no setup for decent results.
The point is, maybe you really hate all that stuff. Nothing stops you from being an awesome cookie cutter. More power to you. I suspect, however, that most of your colleagues would regard that as a career-limiting move.
One of them is a software developer who basically does just that, implement requirements. To enable an engineering department with this type of developer, management needs to already have developed a pretty good view on the business processes that could benefit from automation, or that could become feasible in the first place through software. It is understood that a 5% improvement on the critical path can be more difficult, yet still more worthwhile than a 50% improvement in some less important part of the system. To gain this understanding, management needs to know what is technically possible and perform lots of requirements analysis. After that, well-defined work packets can be handed down to rank and file engineers, and then everyone is on their merry way.
The other kind of software engineer performs most of this support work on their own. Such an engineer has additional responsibilities, but can be useful in many more places because the surrounding support structures don't need to exist. You might not even have to give them specific guidance. However, it means that to use this kind of engineer effectively, you have to expose them to accidentals like time, money and risk, or they will not be able to accurately assess where their talents would be most useful.
Many organizations will actually have both types of engineers. But invariably, the perception of how valuable they are will be heavily skewed in favor of the latter kind of engineer. In the hands of management, they handle like a chef's knife, while the "pure" type of engineer would feel more like a cookie cutter. Even the sharpest, most efficient and most perfect cookie cutter will have a hard time to be perceived as more valuable than a reliable multi-use tool that needs next to no setup for decent results.
The point is, maybe you really hate all that stuff. Nothing stops you from being an awesome cookie cutter. More power to you. I suspect, however, that most of your colleagues would regard that as a career-limiting move.
Yeah that makes sense. There seems to be no escape from assessing the risks and investment, although I think there is some inherent value to doing proper engineering, such that the risk is usually worth it because software automation has accelerating returns, but that is also a hard sell in most cases except highly technical areas.
It's an interesting discussion, thanks for your input!
It's an interesting discussion, thanks for your input!
As an engineer my job should be to engineer systems not to worry about how the business is running and how much profit it makes.
and yet you don’t actually get to be an engineer if the business is not running and profits are not made - if that happens you get canned and you have to find another place to engineer. the whole purpose of your employment is that you should generate more value to the company than your compensation. people that are not aware of this will have a difficult career in front of them
and yet you don’t actually get to be an engineer if the business is not running and profits are not made - if that happens you get canned and you have to find another place to engineer. the whole purpose of your employment is that you should generate more value to the company than your compensation. people that are not aware of this will have a difficult career in front of them
Sure, but you are describing something that is not an engineering problem, and part of my point is that this has consequences for the business as well.
We're really talking about how the roles are divided in teams within an org, and increasingly engineers are having to worry about non-engineering tasks and I have experienced this causing a lot of issues in the long run for the business.
I'm basically saying that if you make the roles wear too many hats then they can't be experts in their domain and this has consequences sooner or later. One of the ways companies dilute the roles is by telling them to "create impact", instead of say create systems with no bugs and that can be iterated upon quickly.
We're really talking about how the roles are divided in teams within an org, and increasingly engineers are having to worry about non-engineering tasks and I have experienced this causing a lot of issues in the long run for the business.
I'm basically saying that if you make the roles wear too many hats then they can't be experts in their domain and this has consequences sooner or later. One of the ways companies dilute the roles is by telling them to "create impact", instead of say create systems with no bugs and that can be iterated upon quickly.
I'm basically saying that if you make the roles wear too many hats then they can't be experts in their domain and this has consequences sooner or later. One of the ways companies dilute the roles is by telling them to "create impact", instead of say create systems with no bugs and that can be iterated upon quickly.
I don’t disagree with just about everything you wrote except for one perhaps fundamental issue - what I think is engineers (best ones, 10x ones) always think of the business and in order to do that they must learn the business inside and out. and their engineering decisions need to heavily weight on the business. here’s a personal example, I’ve worked as lead engineer on software solution that is deployed in courthouses across the united states. we were working on modernization (basically creating an enterprise version of legacy powerbuilder app)… up until that point I have been in this industry for 9 years and have worked on-site in a courthouse in colorado for 3. I was intimately familiar with both the innerworkings on the courthouses but also demographic if the entire user-base. hence, ALL engineering decisions were made with the business in mind, how does my company win new business, how does the business work overall… if someone else was leading this effort who was not familiar with the business the new app could have been an absolute marvel of engineering with every imaginable bell and whistle but would likely have been a collosal failure
I don’t disagree with just about everything you wrote except for one perhaps fundamental issue - what I think is engineers (best ones, 10x ones) always think of the business and in order to do that they must learn the business inside and out. and their engineering decisions need to heavily weight on the business. here’s a personal example, I’ve worked as lead engineer on software solution that is deployed in courthouses across the united states. we were working on modernization (basically creating an enterprise version of legacy powerbuilder app)… up until that point I have been in this industry for 9 years and have worked on-site in a courthouse in colorado for 3. I was intimately familiar with both the innerworkings on the courthouses but also demographic if the entire user-base. hence, ALL engineering decisions were made with the business in mind, how does my company win new business, how does the business work overall… if someone else was leading this effort who was not familiar with the business the new app could have been an absolute marvel of engineering with every imaginable bell and whistle but would likely have been a collosal failure
I agree there is some overlap with what engineers should know about the business, I guess it's just a matter of where the line is drawn. I also think one of the factors is the size of the team and also the structure of the org. If an org is large enough, then it can afford to have engineers specialize in doing just engineering without thinking about the bigger picture, so long as they have a clear goal in mind. That said, my experience with large orgs is the opposite and it's where they push engineers towards management and leadership a lot more than in other smaller orgs.
In my opinion the productivity of engineering should come from the engineering itself, especially with software systems. Software is about automation. The better the engineering, the more productive the org becomes. This potential is hurt by having engineers worry about what the customer wants or how the business works in detail. But yeah, this varies with what the type of business, and the size and structure of the org.
In my opinion the productivity of engineering should come from the engineering itself, especially with software systems. Software is about automation. The better the engineering, the more productive the org becomes. This potential is hurt by having engineers worry about what the customer wants or how the business works in detail. But yeah, this varies with what the type of business, and the size and structure of the org.
This potential is hurt by having engineers worry about what the customer wants or how the business works in detail. But yeah, this varies with what the type of business, and the size and structure of the org
not every engineer needs to know about business. but “10x” ones do I believe - all of the business. they are the ones that put guardrails around engineering decisions and ensure business continuity and prosperity. I do not believe that there should be any lead engineer anywhere who is not intimately familiar with the business - all of the business - of the company she/he is working for.
not every engineer needs to know about business. but “10x” ones do I believe - all of the business. they are the ones that put guardrails around engineering decisions and ensure business continuity and prosperity. I do not believe that there should be any lead engineer anywhere who is not intimately familiar with the business - all of the business - of the company she/he is working for.
Fair enough, although I still believe more engineering should mean more productivity at least if the org structure allows for it. There is always someone who did not spend 10+ years studying CS that can help with the high level directions and communications, but I'm still learning in this regard. Thanks for your input.
The highlight for me is the distinction between being reckless and being 10x. It’s not about ignoring rules entirely; it’s about getting the right sign-offs and aligning the team, then going full throttle. Really resonates with how I like to work. There's something about having total urgency on delivering something that makes us rethink the existing process like nothing else.
Big appetite for risk; own it, do it and ship it--these two are very hard in a large organization. Let me give you an example: one time, I had to move five solaris servers from one rack to another rack (with same IPs, etc). The app owner agreed to it as well. Powered off, then moved to another rack, powered on. Now that unsupported BEA WebLogic app server cluster didn't come up. People were just pointing fingers at each other. No appetite for risk; owning it without solving unforeseen problems is a big NO.
10x Engineer is possible in a green field environment. In any other scenario, someone like Elon on the top have to own the risk. No middle manager, no senior management want to take on risks.
10x Engineer is possible in a green field environment. In any other scenario, someone like Elon on the top have to own the risk. No middle manager, no senior management want to take on risks.
Musk's takeover and move of twitter servers is absolutely not an example of "10x" engineering. It is sociopathic hero worship.
An untouchable authoritarian oligarch saying "how hard can it be" while taking a blowtorch to societal support structures is going to inflict death and pain on people, the neediest among us.
The Wolf is a much better exemplar of the patterns of a truly effective 10x engineer who makes things better for the business. Were a Wolf to behave like Musk, they would be fired.
https://randsinrepose.com/archives/the-wolf/
An untouchable authoritarian oligarch saying "how hard can it be" while taking a blowtorch to societal support structures is going to inflict death and pain on people, the neediest among us.
The Wolf is a much better exemplar of the patterns of a truly effective 10x engineer who makes things better for the business. Were a Wolf to behave like Musk, they would be fired.
https://randsinrepose.com/archives/the-wolf/
[deleted]
It's like hiring a plumber and telling them "your job is to create the most impact in my house"... uh, no... how about you tell me what you want or what the problem is, and if you want an overhaul that can be done as well. This whole "create impact" and "add business value" is such a sneaky way to exploit people, and of course there are many people who oblige and just dedicate their entire careers to running a business instead of being engineers and implementing things properly.