undefined | Better HN

0 pointsproc01y ago0 comments

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.

0 comments

3 comments · 1 top-level

bdangubic1y ago· 2 in thread

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

proc0OP1y 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.

bdangubic1y 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.

1 more reply

j / k navigate · click thread line to collapse