4 ms·

"Textbook" was possibly more a nervous tic than a statement of fact -- I've not read a lot of management textbooks... However, whenever I see generalist manage

"Textbook" was possibly more a nervous tic than a statement of fact -- I've not read a lot of management textbooks... However, whenever I see generalist managers at work, there always seems to be massive emphasis on schedule risk and at least in organisation I've been in, the proposed mitigation is always regular status meetings (and perhaps other forms of check-in as well). This seems to have been almost entirely normalised in the software world, particularly anywhere that's gone down the agile pathway: fine-grained tickets in an issue tracker (or possibly cards on the wall -- but haven't ever seen that one in action) and a daily standup with an explicit goal of making sure nobody is "spinning their wheels".

eru 9y ago
One problem is that 'agile' has been taken over by management types.
sverige 9y ago
> However, whenever I see generalist managers at work, there always seems to be massive emphasis on schedule risk and at least in organisation I've been in, the proposed mitigation is always regular status meetings (and perhaps other forms of check-in as well). I think the reason for that behavior is because they don't want to be caught unawares when some deadline is missed. In other words, one of the metrics they are measured on is meeting deadlines, which of course pushes schedule risk to the top of the pile. There's merit to that, but that has to be balanced with the quality of the product. The blind spot for such managers is that constant check-ins and updates on progress too frequently interrupt the flow of people who need time to think things through. Adding pressure at the wrong point can possibly ruin the quality of the final product.
- ScottBurson 9y ago
  I have a completely different way of mitigating schedule risk: find the most difficult, unpredictable subproblem and do that first. I guess it's not quite fair to say that I've never seen a manager pick up on this idea, but it still doesn't seem to have become their first-choice strategy.
  - mikhailfranco 9y ago
    An experienced architect will always do this. Often the most risky subproblem is the one that is least understood (unknown unknowns), which needs to be investigated, even if it turns out not to be a great risk. In agile-speak this is called 'spike solution'. Also see lean architecture methods, such as: - 'Just Enough Software Architecture', by George Fairbanks. - 'Risk and Cost Driven Architecture', by Eltjo Poort.
heymijo 9y ago
Thanks for the explanation. I've got a working theory: most people, even managers, even lauded ones, don't know much about "textbook" management. They mostly manage how they were managed, some picking up a few things here or there. It's recursive. I've worked in businesses, started and scaled my own, and have also been a teacher (k-12). We all go to school for at least 13 years and internalize what "teaching" is. Most teachers' classrooms end up looking like ones they experienced even if the "textbook" lays out massively different ideas. It's the same problem as management.* We all also work, and internalize some conception of "management." Thus, most manage they way they were managed. Throughout my career I've worked with over a hundred different organizations. I can read about many more in the news and case studies. I see very little in practice that aligns with hardly any of the big ideas in management that I've learned from the likes of Drucker and Deming. *It has not gone unnoticed that education is our first experience with management. Often it has Taylorist, Theory X, command and control roots. In contrast, the great teachers I see have a lot in common with great managers and management theory (see Drucker, Deming).

eru 9y ago

One problem is that 'agile' has been taken over by management types.

sverige 9y ago

> However, whenever I see generalist managers at work, there always seems to be massive emphasis on schedule risk and at least in organisation I've been in, the proposed mitigation is always regular status meetings (and perhaps other forms of check-in as well). I think the reason for that behavior is because they don't want to be caught unawares when some deadline is missed. In other words, one of the metrics they are measured on is meeting deadlines, which of course pushes schedule risk to the top of the pile. There's merit to that, but that has to be balanced with the quality of the product. The blind spot for such managers is that constant check-ins and updates on progress too frequently interrupt the flow of people who need time to think things through. Adding pressure at the wrong point can possibly ruin the quality of the final product.

ScottBurson 9y ago
I have a completely different way of mitigating schedule risk: find the most difficult, unpredictable subproblem and do that first. I guess it's not quite fair to say that I've never seen a manager pick up on this idea, but it still doesn't seem to have become their first-choice strategy.
- mikhailfranco 9y ago
  An experienced architect will always do this. Often the most risky subproblem is the one that is least understood (unknown unknowns), which needs to be investigated, even if it turns out not to be a great risk. In agile-speak this is called 'spike solution'. Also see lean architecture methods, such as: - 'Just Enough Software Architecture', by George Fairbanks. - 'Risk and Cost Driven Architecture', by Eltjo Poort.

heymijo 9y ago

Thanks for the explanation. I've got a working theory: most people, even managers, even lauded ones, don't know much about "textbook" management. They mostly manage how they were managed, some picking up a few things here or there. It's recursive. I've worked in businesses, started and scaled my own, and have also been a teacher (k-12). We all go to school for at least 13 years and internalize what "teaching" is. Most teachers' classrooms end up looking like ones they experienced even if the "textbook" lays out massively different ideas. It's the same problem as management.* We all also work, and internalize some conception of "management." Thus, most manage they way they were managed. Throughout my career I've worked with over a hundred different organizations. I can read about many more in the news and case studies. I see very little in practice that aligns with hardly any of the big ideas in management that I've learned from the likes of Drucker and Deming. *It has not gone unnoticed that education is our first experience with management. Often it has Taylorist, Theory X, command and control roots. In contrast, the great teachers I see have a lot in common with great managers and management theory (see Drucker, Deming).