[apejcic]

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.

[inigyou]

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, but you'll probably be fired for having ethics, but that doesn't make it bad engineering.

[surajrmal]

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.

[brazukadev]

> Considering the large increases in revenues bug tech extracts year over year

I don't know if bug tech was a typo or intentional but from now on I'm using it in place of big tech.

[Yoric]

> Engineers over-engineer simple problems because their performance reviews reward technical complexity, not business impact.

Having tech led teams at both high-profile and low-profile tech companies, that is _not_ my experience.

Most engineers worth their salt value quality. Product Management generally doesn't see quality as a feature, therefore doesn't take it into account. For short-lived code, quality is indeed over-rated. For long-lived code, quality is the thing that determines whether you can keep improving or tuning other features or whether you'll miss deadlines. Sadly, retrofitting quality in an existing codebase is awfully expensive.

There's also one important, but often undervalued, aspect. Overwhelmingly, today's tech world has been built by neurodivergent engineers. In my experience, neurodivergent engineers tend to value getting to the end of things, rather than letting them drop mid-way. This can absolutely be seen as over-engineering, but it's often a cognitive scaffolding that will ensure that the work can be resumed (by them or anyone else) even after context-switching to something entirely different.

Whether it actually _is_ over-engineering often depends on how well the engineer is aware of the actual needs, rather than being spoon-fed instructions without visibility. Or on the maturity and skill of the engineer, depending on the case.

[jwoq9118]

Relevant

https://terriblesoftware.org/2026/03/03/nobody-gets-promoted...