16 ms·

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 r

by proc0 2y ago

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.

bdangubic 2y ago
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
- proc0 2y ago
  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.
  - bdangubic 2y ago
    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.
    - proc0 2y ago
      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.

by proc0 2y ago

bdangubic 2y ago

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

proc0 2y ago
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.
- bdangubic 2y ago
  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.
  - proc0 2y ago
    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.