It sounds simple, but note that I said "50 minutes", not 5, which is a big difference. Specifically, in a 1.5 week sprint cycle involving about 40 maven modules with complex inter-dependencies, a 380-step procedure to deploy into production and that is fragile enough that simply getting it to work at 95% reliability in 50 minutes was a huge advancement over the state when I showed up.

(The previous developers "looked" productive because they could work on things a module at a time, but they went in a circle for two years because they were incapable of delivering a fully integrate working system)

In this particular case the company was using an "agile" process except this what not bought into by many of the key people, including the superstar developer, lead manager, product manager, etc. It did mean however, that if I wanted to speed up the build, I would have conversations about "How does this benefit the customer?" which would degenerate into "does the customer want to get this product at all?" It would mean not doing anything else for a sprint cycle, for one thing.

Now that particular case required an organization to gain some size and lumber along for a long time to build up a huge code base, but bullshit happens in small organizations too.

Yeah, that situation sounds pretty bad. Thankfully I think we're a long way from that, and I'm sure that will come across in our hiring process.