4 ms·

"A lot of textbook management techniques..." Can you unpack this? Would like to hear more.

dasmoth 9y ago
"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).
lordnacho 9y ago
I have "management" in my degree title, from a world famous uni. Basically a good taste of an MBA, since an MBA there is a year. Very little of a management course is about how you treat people. If anything, you are left with Taylorism and the lingering question of how it relates to knowledge workers. Because Taylor was basically measuring factory workers' performance, whose contribution is to do some repeated action over and over. If that sounds like treating someone like a robot, it's because it is. This is not to say nobody has thought about this. HBR will run an article now and again about HR issues. But there's nothing especially compelling where you'd be able to find a root cause, find a specific solution, and implement it. If it was, management wouldn't be magic, it would be engineering. And the practitioners would not be paid enormous sums for doing the impossible, they'd be paid moderately well for being ordinarily competent. Most of the things on the course are really not that different from reading the FT regularly. So-and-so company found their product wasn't appealing to young people, so they tried X and it was a massive success. Doesn't tell you what to do if you were to run this firm, but after you've read a few you'll think you know. Case studies are a case study in post-hoc fallacy. Then there's a bunch of supposedly advanced financial stuff, which if you're an engineer you'll laugh at. Ratios, really? Interest rates? If you do a proper finance course there will be real things to learn (stoch calc doesn't show up much in engineering), but not in the business school. And there's a few useful things, too, like the history of capitalism, but nothing that develops a proper intuition or method for a field of problems like engineering does.
- dasmoth 9y ago
  Thanks. Ultimately, I think I was referring to the Taylorist aspect. There's also a philosophy that I've seen labelled as "teamism" and which seems to form the basis of methodologies like Scrum. I'm not sure teamism is quite the same thing as Taylorism -- but it shares the same distrust for individuals working on problems without near-constant oversight.
  - crdoconnor 9y ago
    Scrum has elements of Taylorism: team members are treated as interchangeable cogs to be assigned units of work and it has a crappy "productivity" measure built in (velocity).

"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).

lordnacho 9y ago

I have "management" in my degree title, from a world famous uni. Basically a good taste of an MBA, since an MBA there is a year. Very little of a management course is about how you treat people. If anything, you are left with Taylorism and the lingering question of how it relates to knowledge workers. Because Taylor was basically measuring factory workers' performance, whose contribution is to do some repeated action over and over. If that sounds like treating someone like a robot, it's because it is. This is not to say nobody has thought about this. HBR will run an article now and again about HR issues. But there's nothing especially compelling where you'd be able to find a root cause, find a specific solution, and implement it. If it was, management wouldn't be magic, it would be engineering. And the practitioners would not be paid enormous sums for doing the impossible, they'd be paid moderately well for being ordinarily competent. Most of the things on the course are really not that different from reading the FT regularly. So-and-so company found their product wasn't appealing to young people, so they tried X and it was a massive success. Doesn't tell you what to do if you were to run this firm, but after you've read a few you'll think you know. Case studies are a case study in post-hoc fallacy. Then there's a bunch of supposedly advanced financial stuff, which if you're an engineer you'll laugh at. Ratios, really? Interest rates? If you do a proper finance course there will be real things to learn (stoch calc doesn't show up much in engineering), but not in the business school. And there's a few useful things, too, like the history of capitalism, but nothing that develops a proper intuition or method for a field of problems like engineering does.

dasmoth 9y ago
Thanks. Ultimately, I think I was referring to the Taylorist aspect. There's also a philosophy that I've seen labelled as "teamism" and which seems to form the basis of methodologies like Scrum. I'm not sure teamism is quite the same thing as Taylorism -- but it shares the same distrust for individuals working on problems without near-constant oversight.
- crdoconnor 9y ago
  Scrum has elements of Taylorism: team members are treated as interchangeable cogs to be assigned units of work and it has a crappy "productivity" measure built in (velocity).