5 ms·

I'll bite. Management always seem to get the crap. To summarize, if engineers knew how to manage things better than management, why don't they? From my experien

I'll bite. Management always seem to get the crap. To summarize, if engineers knew how to manage things better than management, why don't they? From my experience, teams without management seem to complain about that and end up with bad results. There are more factors at play, and honestly it's very rare that the engineers sees that (or even acknowledge that they don't know all the relevant factors, with all the implications that gives). Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.

jamestimmins 7y ago
Yeah I don't mean to imply that it's managers per se. Management seems suuuuper hard and I wouldn't want the task of assessing engineering productivity. I just mean that the "metrics" put out by Agile give the illusion of something useful to managers. It's totally understandable that folks in positions of authority would attempt to make use of them. But I think the illusion of objectivity is more damaging to teams than the acceptance of uncertainty.
- ratww 7y ago
  I think it has a lot to do with bargain power. By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker. By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.
- shantly 7y ago
  I'd say that attempting to use the same tool to help a team communicate with one another and to communicate with management or stakeholders who aren't very close to the project (involved daily near the ground level) is essentially doomed. Management will either hate the answers they get or they'll ruin the tool's utility to the team, resulting in worse communication at every level and slower work. Or both. It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.
  - ryandrake 7y ago
    As a project manager, I hate taking a bug tracker and trying to beat it into being a project management/communication/measurement tool. The only reason I always end up doing so is that bug trackers are already in the engineers’ daily workflow so they are usually the source of truth about the project. I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is.
    - shantly 7y ago
      > I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is. What'd that look like, that's different from what they do now? Trying to imagine what developer input to that would look like. I think a lot of devs already feel like existing PM tools they use for sprint tracking and such are worse than if they pushed more planning into git or somewhere otherwise closer to the code, so getting buy-in might not be so hard if devs got to be a little less heavy in a bunch of not-actually-that-useful-to-them tools on a day to day basis.
      - ryandrake 7y ago
        Could be something as complex as MS Project or simple as a shared spreadsheet with rows for each project and columns for each milestone or for things like ETA, dependencies we’re blocked on, escalations needed, scope changes, etc. Not sure how that could gel well with a source control tool but I’m all ears! I think 1/4 of the challenge is what tool to use and 3/4 is convincing and motivating people to be reliable and forthcoming with accurate information. A good project manager demonstrates he or she can add value, unblock things, escalate and communicate appropriately, and not just be the Project Police.
- apotheon 7y ago
  Management has, culturally, become very metrics-oriented. This is the root of the problem under discussion here. See Goodhart's law for a brief statement of why this can't work. Almost every time I bring this up somewhere, someone pops up to say that metrics are important, key to fair and impersonal management. Without it, everything would suck, and managers couldn't do anything. The problem with that thinking is two-fold: 1. It ignores the fact that, as soon as there's a metric that determines someone's rewards and punishments in a management system (whether it's governmental regulation, corporate middle-management, anarcho-communistic self-management, or anything else), the system of measurement will get gamed, and the most overtly "successful" will end up being the most cleverly sociopathic about it. 2. There is an alternative to strictly quantitative evaluation. The alternative is qualitative evaluation. This requires good judgement, intimate knowledge of the problem domain, good intentions, and the ability to consider context, among other things. Sadly, this is incompatible with bureaucracy, which means you need to either carve a bureaucracy-free zone out of the larger organization to manage a team well or stay out of medium-to-large corporations (and out of small businesses that ape the behaviors of large bureaucracies). Managers who insist on doing everything quantitatively (and sometimes they're forced to do so by their managers) will not get good results. "Good" is qualitative, not quantitative. Equating "good" with metrics just gives you results that look "good" on paper, but really aren't good. Probably the biggest benefit of a small organization is the ability to eschew managerial bureaucracy in practice.
hrktb 7y ago
Management gets the crap because they have the responsibility and push the processes. It’s as if we were complaining that elected officials get the crap for mismanaging the country. Well, that’s the point of them doing their job. Our goal is not to all become managers (though some do, exactly for these reasons), it shouldn’t be a ”why don’t you do it ?” rhetoric.
AnimalMuppet 7y ago
Somewhere, there's always an impedance mismatch. Agile can be managed, and managed well - I've seen it done - but above that manager, there's another manager. Somewhere up the chain, someone wants to see progress on a PERT chart or similar, and the person who is managing an agile project doesn't have a good way to answer.
- shantly 7y ago
  It is vital to have someone close enough to the project that the team trusts them to see their honest opinions about progress and blockers, including non-bullshit pointing of tasks, who is the point person for communicating progress to management, and who is capable of producing reports that are technically bullshit in an is-this-quantifiable-this-way sense but actually do reflect reality usefully to managers. Someone who does that well is worth All The Money. They're useless if you're giving management direct access to team planning & communication tools, of course.
  - ryandrake 7y ago
    In some places these are called Engineering Project Managers, in others they are Technical Program Managers. You may think they are worth All The Money but let me assure you they usually make far, far less than the developers :-)
ptx 7y ago
Agile was proposed as a way for engineers (or "self-organizing teams") to manage things better. The complaint is that the engineers' better management process has now been hijacked by management and turned into something else.
bb88 7y ago
A space alien with a raygun and a watch knows just enough English to tell you to build a time machine "or else!" Any attempt to persuade him otherwise just results in him pointing his raygun to his watch. Either he's ignorant, can't or won't understand, or simply doesn't care. Software management in 2019 is still very much like this. Management has had 40 years to solve this problem, and it looks like it won't be solved in the next 40 either
dragonwriter 7y ago
> if engineers knew how to manage things better than management, why don't they? They do: engineering-led companies are often dynamic success stories, then when they get big enough traditional management works down from the top to lower levels and the firm stagnates.

jamestimmins 7y ago

Yeah I don't mean to imply that it's managers per se. Management seems suuuuper hard and I wouldn't want the task of assessing engineering productivity. I just mean that the "metrics" put out by Agile give the illusion of something useful to managers. It's totally understandable that folks in positions of authority would attempt to make use of them. But I think the illusion of objectivity is more damaging to teams than the acceptance of uncertainty.

ratww 7y ago
I think it has a lot to do with bargain power. By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker. By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.
shantly 7y ago
I'd say that attempting to use the same tool to help a team communicate with one another and to communicate with management or stakeholders who aren't very close to the project (involved daily near the ground level) is essentially doomed. Management will either hate the answers they get or they'll ruin the tool's utility to the team, resulting in worse communication at every level and slower work. Or both. It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.
- ryandrake 7y ago
  As a project manager, I hate taking a bug tracker and trying to beat it into being a project management/communication/measurement tool. The only reason I always end up doing so is that bug trackers are already in the engineers’ daily workflow so they are usually the source of truth about the project. I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is.
  - shantly 7y ago
    > I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is. What'd that look like, that's different from what they do now? Trying to imagine what developer input to that would look like. I think a lot of devs already feel like existing PM tools they use for sprint tracking and such are worse than if they pushed more planning into git or somewhere otherwise closer to the code, so getting buy-in might not be so hard if devs got to be a little less heavy in a bunch of not-actually-that-useful-to-them tools on a day to day basis.
    - ryandrake 7y ago
      Could be something as complex as MS Project or simple as a shared spreadsheet with rows for each project and columns for each milestone or for things like ETA, dependencies we’re blocked on, escalations needed, scope changes, etc. Not sure how that could gel well with a source control tool but I’m all ears! I think 1/4 of the challenge is what tool to use and 3/4 is convincing and motivating people to be reliable and forthcoming with accurate information. A good project manager demonstrates he or she can add value, unblock things, escalate and communicate appropriately, and not just be the Project Police.
apotheon 7y ago
Management has, culturally, become very metrics-oriented. This is the root of the problem under discussion here. See Goodhart's law for a brief statement of why this can't work. Almost every time I bring this up somewhere, someone pops up to say that metrics are important, key to fair and impersonal management. Without it, everything would suck, and managers couldn't do anything. The problem with that thinking is two-fold: 1. It ignores the fact that, as soon as there's a metric that determines someone's rewards and punishments in a management system (whether it's governmental regulation, corporate middle-management, anarcho-communistic self-management, or anything else), the system of measurement will get gamed, and the most overtly "successful" will end up being the most cleverly sociopathic about it. 2. There is an alternative to strictly quantitative evaluation. The alternative is qualitative evaluation. This requires good judgement, intimate knowledge of the problem domain, good intentions, and the ability to consider context, among other things. Sadly, this is incompatible with bureaucracy, which means you need to either carve a bureaucracy-free zone out of the larger organization to manage a team well or stay out of medium-to-large corporations (and out of small businesses that ape the behaviors of large bureaucracies). Managers who insist on doing everything quantitatively (and sometimes they're forced to do so by their managers) will not get good results. "Good" is qualitative, not quantitative. Equating "good" with metrics just gives you results that look "good" on paper, but really aren't good. Probably the biggest benefit of a small organization is the ability to eschew managerial bureaucracy in practice.

hrktb 7y ago

Management gets the crap because they have the responsibility and push the processes. It’s as if we were complaining that elected officials get the crap for mismanaging the country. Well, that’s the point of them doing their job. Our goal is not to all become managers (though some do, exactly for these reasons), it shouldn’t be a ”why don’t you do it ?” rhetoric.

AnimalMuppet 7y ago

Somewhere, there's always an impedance mismatch. Agile can be managed, and managed well - I've seen it done - but above that manager, there's another manager. Somewhere up the chain, someone wants to see progress on a PERT chart or similar, and the person who is managing an agile project doesn't have a good way to answer.

shantly 7y ago
It is vital to have someone close enough to the project that the team trusts them to see their honest opinions about progress and blockers, including non-bullshit pointing of tasks, who is the point person for communicating progress to management, and who is capable of producing reports that are technically bullshit in an is-this-quantifiable-this-way sense but actually do reflect reality usefully to managers. Someone who does that well is worth All The Money. They're useless if you're giving management direct access to team planning & communication tools, of course.
- ryandrake 7y ago
  In some places these are called Engineering Project Managers, in others they are Technical Program Managers. You may think they are worth All The Money but let me assure you they usually make far, far less than the developers :-)

ptx 7y ago

Agile was proposed as a way for engineers (or "self-organizing teams") to manage things better. The complaint is that the engineers' better management process has now been hijacked by management and turned into something else.

bb88 7y ago

A space alien with a raygun and a watch knows just enough English to tell you to build a time machine "or else!" Any attempt to persuade him otherwise just results in him pointing his raygun to his watch. Either he's ignorant, can't or won't understand, or simply doesn't care. Software management in 2019 is still very much like this. Management has had 40 years to solve this problem, and it looks like it won't be solved in the next 40 either

dragonwriter 7y ago

> if engineers knew how to manage things better than management, why don't they? They do: engineering-led companies are often dynamic success stories, then when they get big enough traditional management works down from the top to lower levels and the firm stagnates.