The times that I have been the person getting 40 hours worth of work done in 20 hours, I was using the other 20 hours to rewrite things with a different approac

The times that I have been the person getting 40 hours worth of work done in 20 hours, I was using the other 20 hours to rewrite things with a different approach ... in other words, the "deep work" that the business didn't see a need for. I knew that the deep work was why I could get 40 hours worth done in 20 hours, so I made sure I did the deep work. That, of course, put me behind in my directly assigned (non-deep-work) tasks. However, the deep work paid off in more powerful ways (more powerful abstractions, allowing me to find solutions to problems we thought we would be unable to solve, discovering real problems that we didn't yet know we had, etc.), and ultimately made it possible for me get my tasks done in the other 20 hours (or, to deliver something else of enough value that they decided my original tasks didn't matter). It's not nearly as neat as "40 hours worth in 20 hours", and it certainly didn't lead to a bunch of free time sitting on my hands. It was just a case of knowing the deep work was necessary, even if those assigning me work didn't, and doing that deep work anyway, and having things work out well because the deep work really was necessary and powerful. And I think that happens a lot with good developers in the "enterprise" software world.