IMO, and this is what the engineers never get to find out, at the managerial level, a big concern is to keep the 'labor' "fed" (fed here means fed with list of

IMO, and this is what the engineers never get to find out, at the managerial level, a big concern is to keep the 'labor' "fed" (fed here means fed with list of tasks). Meaning, an ideal for a manager in this aspect is to have tasks ready one after the other, so that there is no time during the work week where the engineer is under the impression that (s)he doesn't have anything to do. This is actually not easy. Real work, and real productivity is nonlinear. You have times of serious crunch, and times where there really is not much to do. Entrepreneurs do this better, but in startups there is almost never a time where there is not much to do (there is always something to do). Or flat hierarchies, especially one where the boss is also an ex-engineer, also do relatively better. This really gets worse in the case of org-chart hierarchies in established/blue-chippy companies, where middle management, especially one that has no clue of tech work, solves this problem by creating pipelines of tasks that can safely be described as "bullshit jobs". Some middle managers decide to use up the pipeline in a way so as to keep the engineers occupied 60-70 hours a week, others 40-50 hours a week, something that varies from team to team.