Good engineering isn't always about building new things, but making existing ones continue to work well. Funding new ideas is generally a hard problem for large organizations and that's not entirely an engineering culture problem. There are a lot of terrible practices out there in the world that you should stay wary of. Too many false positive alerts, flakey tests, not enough tests, not listening to users, taking a solution because it's easy and popular but not necessarily a good fit for your specific requirements, etc. Many of these practices are popular unfortunately. That's not to say others don't have great ideas, just don't copy them blindly.

Having led engineering in SF big tech and now building my own startup, I’ve heard this exact argument countless times. I believe it is precisely why large tech companies are losing their ability to innovate. Engineering shouldn't be an academic pursuit of "good engineering" for its own sake. It is fundamentally a business function. The objective is to achieve real world goals and build things people actually want, even if that means the solution is scrappy and unpolished today, so long as it solves an important problem cheaply and effectively. In large organizations, accountability for actual value delivery is so diluted across the org chart that it practically disappears. Leaders gravitate toward building bloated "internal platforms" that offer little external utility. Engineers over-engineer simple problems because their performance reviews reward technical complexity, not business impact. It becomes a systemic shield, allowing the old guard to justify their headcount without delivering new value. Software engineering is uniquely plagued by this. Civil engineers understand their objective: build a bridge that safely carries traffic within a specific budget. They don't invent a novel, hyper-complex suspension architecture when a standard short-span bridge will do the job.

Having led engineering in SF big tech and now building my own startup, I’ve heard this exact argument countless times. I believe it is precisely why large tech companies are losing their ability to innovate. Engineering shouldn't be an academic pursuit of "good engineering" for its own sake. It is fundamentally a business function. The objective is to achieve real world goals and build things people actually want, even if that means the solution is scrappy and unpolished today, so long as it solves an important problem cheaply and effectively. In large organizations, accountability for actual value delivery is so diluted across the org chart that it practically disappears. Leaders gravitate toward building bloated "internal platforms" that offer little external utility. Engineers over-engineer simple problems because their performance reviews reward technical complexity, not business impact. It becomes a systemic shield, allowing the old guard to justify their headcount without delivering new value. Software engineering is uniquely plagued by this. Civil engineers understand their objective: build a bridge that safely carries traffic within a specific budget. They don't invent a novel, hyper-complex suspension architecture when a standard short-span bridge will do the job.

Considering the large increases in revenues bug tech extracts year over year, the maintenance and small improvements are not necessarily completely disregarding the business side of things. You cannot keep sustained performance without proper practices. Too much short term thinking like you see in startups leads to loss of confidence that new changes won't break existing customers, or hellish on call that no one wants to be part of. There is a lifecycle to product development and different phases require different tradeoffs. You sound like you align with the builder phase and that's great. I will also note that most civil engineering is about maintaining existing structures and roadways, not building new ones.

I would decouple "build things people want" from "business function". I would put in the former bucket things like: making the computer work smoothly and run apps. I would put in the latter bucket things like: show advertising to the user when the log in. Engineering should always be about the first, or it's bad engineering. The second is far more controversial - business leaders would like you to consider it good engineering to do that, but you get to interpose your own ethics.

I would decouple "build things people want" from "business function". I would put in the former bucket things like: making the computer work smoothly and run apps. I would put in the latter bucket things like: show advertising to the user when the log in. Engineering should always be about the first, or it's bad engineering. The second is far more controversial - business leaders would like you to consider it good engineering to do that, but you get to interpose your own ethics.