[imbnwa]

The problem in Enterprise is that the environment is designed to fracture the Engineering team as much as possible so that it isn't capable of collective bartering. This is the point of most de facto Agile SCRUM applications: if I, a manager, can't get the estimate I want from you, I can get it from someone else or I can coerce you into the estimate I want indirectly by shoving the burndown chart, or any other weaponized metric, into your face to train you into providing the estimates and deliverables I so desire, which have nothing to do with efficiency.

Because of this leverage, technical debt quickly stacks up as everyone is policing themselves and others to not do the unanimously agreed upon 'right thing' to deliver a more cohesive software infrastructure; my god is cohesion the least likely property of enterprise stacks, at least in my experience, hence: all the local heroes, the mounds of manual testing and lack of automation, the 'everything-at-once-per-quarter' releases instead of CI, the distinct aggregation of 'flags' over parsing data structures, etc.

It is impossible that people are working in such circumstances and are just entirely unaware that things could be better; there is an immense amount of pressure from all sides to essentially 'shut up and dribble'. But that also facilities an environment where individuals or teams are just implementing whatever in their own little kingdom so long as it gets in before the sprint is done. My org alone has three different ways of doing the same exact thing amongst three different teams.

Engineering teams should be reviewing the product roadmap as an independent entity and deliberating on how to approach that collectively. A Director of Engineering is the tie breaker. Estimates come from the team, not individuals, or even individual teams.