6 ms·

> Businesses are paying exorbitant salaries and providing ping pong tables Businesses are paying market rate salaries to employees who generate them revenue. I

by smadge 7y ago

> Businesses are paying exorbitant salaries and providing ping pong tables Businesses are paying market rate salaries to employees who generate them revenue. If anything engineers should be the ones questioning the exorbitant compensation and perks at the top of the org structure. > why shouldn't they have visibility into what's being done? Because they shouldn't be micromanaging. They should be setting high level goals and expectations and giving teams autonomy and trust. Intrusive surveillance and low level metrics create perverse incentives that detract from those high level goals.

rrrrrrrrrrrryan 7y ago
But how can they set goals without any visibility into what a team can typically accomplish in a given time period? How can they identify better performers and worse performers? I'm not saying agile is the right solution, (it probably isn't), but expecting higher-ups to fund a black-box team is kind of naive.
- kyuudou 7y ago
  Ye olde SV Scrum clip[1] "This just became a JOB..." -Gilfoyle [1]https://www.youtube.com/watch?v=oyVksFviJVE https://www.youtube.com/watch?v=oyVksFviJVE S01E05 Scrum scene I do like Agile, it's the typical problem of managers misusing it to micromanage, engage in useless metrics etc.
- jiggawatts 7y ago
  Measure the deliverable, not the deliverers. Reporting on random internal stuff instead of the actual problem at hand is the #1 problem I see with corporate reporting, everywhere. I see various combinations of people wasting time measuring: 1) The thing that is easy to measure, typically money or time. 2) The things they "understand", typically people for HR, compliance for legal, money for finance, etc... 3) The things their manager wants to know, no matter how irrelevant that is to executing their own job well. Meanwhile what they should be measuring is the qualities of the end-product or the overall external customer end result. It doesn't matter one iota if Bob the Developer Guy missed an internal 3-day deadline that John the Manager made up on the spot if the end product is a winner in the market and makes the users ecstatically happy to part with their money. This happens everywhere, with everybody. For an IT-centric example, the common one I see is: Helpdesk: "The users are complaining that the app is slow" Admins: "The load is only 10%, but fine, we'll add more capacity!" Helpdesk: "The app is still slow!" Admins: "The load is only 5%! They should have no reason to complain!" Do you see the issue? No, seriously: do you? Because practically nobody does, in my experience. Take a minute. What happened here is that the admins measured the thing that is easy for them to measure: the load. There's a cute little bar graph in VMware, or a chart in their network appliance, or whatever. What they should have been measuring is latency from the end-user perspective, but that's hard to measure and practically no product tells you this number out of the box. So their entire process, their reporting, their troubleshooting, their forms, requests, everything becomes focused on the thing that they can see and control. Even if it's pointless, ineffective, and basically a waste of everyone's time and effort. This happens with developers in exactly the same manner. Software quality is stupid hard to measure. Long term supportability is borderline impossible to measure without a time machine. Technical debt is hard to even explain to a manager, let alone keep tabs on in terms of numbers. So what's easy to measure? Time! Deadlines, sprints, release dates, etc... That's super easy. That's why inevitably the unimportant internal time metrics become critical to everybody, but the actually important metrics aren't even measured and become invisible to management until it's far too late.
  - freshhawk 7y ago
    This is a good breakdown of this really common dynamic. It is recognizable to many people, some of whom use it for their benefit, which can be very effective. When I learned that last fact a lot of things made more sense.
  - parasubvert 7y ago
    Part of the reason that DevOps culture became a professional movement was to treat both as an end-to-end problem. Which stops misunderstandings like throwing the code to “Ops” and expecting the VMware admin to understand how an app behaves. User response time is a fairly simple metric to measure if you’re a developer. They should expose that, and other metrics, that the customer values. This is one of the reason I’ve enjoyed some “true” agile teams with a strong product owner: they encourage an end-to-end focus on outcomes.
    - stainforth 6y ago
      I feel like Jonathan Blow's jai language looks to do things like this as part of the language, at least to the developer.
  - nine_k 7y ago
    This makes important points. But time and money are the things by which companies live and die. Not keeping tabs on them is suicidal. OTOH measuring time and money consumption of some technical internal steps is just uninformative.
  - brians 7y ago
    As a manager, I want to measure leading indicators of success and failure. Absolutely, feedback control based on the real output is important. I must measure that! But I’m always looking for ways to predict that, so I can steer more gently. What’s a leading indicator of a crisis? A late team struggling to make a deadline. What’s a leading indicator of that? Mismatch between estimates and performance. I need to know about bad point estimates because if I don’t fix it—I mean fix the PM’s misalignment—they’re going to push the team into something dangerous.
- closeparen 6y ago
  By assigning problems to specific responsible individuals, and noticing the existence / quality of the solutions they produce? If anything, Agile obscures individual performance, in that it treats everyone as fungible and every part of the system a commons.
tootie 7y ago
Trust, but verify. I work on the services side and we frequently are in the position begging for more surveillance. If you are really so confident in the speed and quality of your delivery (my org borders on cocky) then the biggest risk we face is being misaligned to client expectations due to poor communication. We always ask for their explicit sign off on story criteria and feedback on features as soon as they are finished to make sure we're aligned and let them see exactly what pace we're setting.
- frereubu 7y ago
  I see what you're getting at, but the Russian proverb that Reagan made famous - "Trust, but verify" https://en.wikipedia.org/wiki/Trust,_but_verify https://en.wikipedia.org/wiki/Trust,_but_verify - raises a wry smile each time I read it because it's such an obvious oxymoron. You either trust, or you verify. There's an earlier version attributed to Mohammed - "Trust in God. But tie your camel first." - so the sentiment has been around for a while. It feels like it's just a way of reducing cognitive dissonance, which is useful I suppose, but I wish people wouldn't use it because it allows a feeling of resolution without a real resolution of the tension between trusting and verifying.
  - sorokod 7y ago
    And before that God helps those who help themselves https://en.m.wikipedia.org/wiki/God_helps_those_who_help_themselves https://en.m.wikipedia.org/wiki/God_helps_those_who_help_the...
  - tootie 6y ago
    I work in services, so for us it's like "Trust, but write explicit assumptions and disclaimers into the contract". It's like when you commit to paying $2M for a custom piece of software, you expect to pay the fee and get the product. Not spy on your vendor then sue for your money back. But you have to prepared to protect your investment.
  - bananamerica 6y ago
    I don’t think neither of these sayings are in themselves contradictory. The first could be translated as “I trust your work ethics, but I also know that your human nature will lead you to perform better under supervision”. The second basically says: “God has my back on a number of things, but She also expects me to do my part”.
Nerevarine76 7y ago
> Businesses are paying market rates salaries to employees who generate them revenue. You use this argument to defend engineers but then question c—level executive salaries. The exact same principles apply but at a multiplicative level.
- goatinaboat 7y ago
  You use this argument to defend engineers but then question c—level executive salaries. The exact same principles apply but at a multiplicative level That’s simply not true, workers and managers are qualitatively different. There are no shortage of examples of managers of companies losing money and marketshare who nevertheless are paid bonuses every year then leave with a golden parachute.
- antonvs 7y ago
  > but at a multiplicative level. Why? That multiplier is often what's at issue, and why "the exact same principles" don't apply.
wmeredith 6y ago
Eh, trust is earned (in both directions of course). I’ve been badly burned by devs and managers alike over the course of my career.

by smadge 7y ago

rrrrrrrrrrrryan 7y ago

But how can they set goals without any visibility into what a team can typically accomplish in a given time period? How can they identify better performers and worse performers? I'm not saying agile is the right solution, (it probably isn't), but expecting higher-ups to fund a black-box team is kind of naive.

kyuudou 7y ago
Ye olde SV Scrum clip[1] "This just became a JOB..." -Gilfoyle [1]https://www.youtube.com/watch?v=oyVksFviJVE https://www.youtube.com/watch?v=oyVksFviJVE S01E05 Scrum scene I do like Agile, it's the typical problem of managers misusing it to micromanage, engage in useless metrics etc.
jiggawatts 7y ago
Measure the deliverable, not the deliverers. Reporting on random internal stuff instead of the actual problem at hand is the #1 problem I see with corporate reporting, everywhere. I see various combinations of people wasting time measuring: 1) The thing that is easy to measure, typically money or time. 2) The things they "understand", typically people for HR, compliance for legal, money for finance, etc... 3) The things their manager wants to know, no matter how irrelevant that is to executing their own job well. Meanwhile what they should be measuring is the qualities of the end-product or the overall external customer end result. It doesn't matter one iota if Bob the Developer Guy missed an internal 3-day deadline that John the Manager made up on the spot if the end product is a winner in the market and makes the users ecstatically happy to part with their money. This happens everywhere, with everybody. For an IT-centric example, the common one I see is: Helpdesk: "The users are complaining that the app is slow" Admins: "The load is only 10%, but fine, we'll add more capacity!" Helpdesk: "The app is still slow!" Admins: "The load is only 5%! They should have no reason to complain!" Do you see the issue? No, seriously: do you? Because practically nobody does, in my experience. Take a minute. What happened here is that the admins measured the thing that is easy for them to measure: the load. There's a cute little bar graph in VMware, or a chart in their network appliance, or whatever. What they should have been measuring is latency from the end-user perspective, but that's hard to measure and practically no product tells you this number out of the box. So their entire process, their reporting, their troubleshooting, their forms, requests, everything becomes focused on the thing that they can see and control. Even if it's pointless, ineffective, and basically a waste of everyone's time and effort. This happens with developers in exactly the same manner. Software quality is stupid hard to measure. Long term supportability is borderline impossible to measure without a time machine. Technical debt is hard to even explain to a manager, let alone keep tabs on in terms of numbers. So what's easy to measure? Time! Deadlines, sprints, release dates, etc... That's super easy. That's why inevitably the unimportant internal time metrics become critical to everybody, but the actually important metrics aren't even measured and become invisible to management until it's far too late.
- freshhawk 7y ago
  This is a good breakdown of this really common dynamic. It is recognizable to many people, some of whom use it for their benefit, which can be very effective. When I learned that last fact a lot of things made more sense.
- parasubvert 7y ago
  Part of the reason that DevOps culture became a professional movement was to treat both as an end-to-end problem. Which stops misunderstandings like throwing the code to “Ops” and expecting the VMware admin to understand how an app behaves. User response time is a fairly simple metric to measure if you’re a developer. They should expose that, and other metrics, that the customer values. This is one of the reason I’ve enjoyed some “true” agile teams with a strong product owner: they encourage an end-to-end focus on outcomes.
  - stainforth 6y ago
    I feel like Jonathan Blow's jai language looks to do things like this as part of the language, at least to the developer.
- nine_k 7y ago
  This makes important points. But time and money are the things by which companies live and die. Not keeping tabs on them is suicidal. OTOH measuring time and money consumption of some technical internal steps is just uninformative.
- brians 7y ago
  As a manager, I want to measure leading indicators of success and failure. Absolutely, feedback control based on the real output is important. I must measure that! But I’m always looking for ways to predict that, so I can steer more gently. What’s a leading indicator of a crisis? A late team struggling to make a deadline. What’s a leading indicator of that? Mismatch between estimates and performance. I need to know about bad point estimates because if I don’t fix it—I mean fix the PM’s misalignment—they’re going to push the team into something dangerous.
closeparen 6y ago
By assigning problems to specific responsible individuals, and noticing the existence / quality of the solutions they produce? If anything, Agile obscures individual performance, in that it treats everyone as fungible and every part of the system a commons.

tootie 7y ago

Trust, but verify. I work on the services side and we frequently are in the position begging for more surveillance. If you are really so confident in the speed and quality of your delivery (my org borders on cocky) then the biggest risk we face is being misaligned to client expectations due to poor communication. We always ask for their explicit sign off on story criteria and feedback on features as soon as they are finished to make sure we're aligned and let them see exactly what pace we're setting.

frereubu 7y ago
I see what you're getting at, but the Russian proverb that Reagan made famous - "Trust, but verify" https://en.wikipedia.org/wiki/Trust,_but_verify https://en.wikipedia.org/wiki/Trust,_but_verify - raises a wry smile each time I read it because it's such an obvious oxymoron. You either trust, or you verify. There's an earlier version attributed to Mohammed - "Trust in God. But tie your camel first." - so the sentiment has been around for a while. It feels like it's just a way of reducing cognitive dissonance, which is useful I suppose, but I wish people wouldn't use it because it allows a feeling of resolution without a real resolution of the tension between trusting and verifying.
- sorokod 7y ago
  And before that God helps those who help themselves https://en.m.wikipedia.org/wiki/God_helps_those_who_help_themselves https://en.m.wikipedia.org/wiki/God_helps_those_who_help_the...
- tootie 6y ago
  I work in services, so for us it's like "Trust, but write explicit assumptions and disclaimers into the contract". It's like when you commit to paying $2M for a custom piece of software, you expect to pay the fee and get the product. Not spy on your vendor then sue for your money back. But you have to prepared to protect your investment.
- bananamerica 6y ago
  I don’t think neither of these sayings are in themselves contradictory. The first could be translated as “I trust your work ethics, but I also know that your human nature will lead you to perform better under supervision”. The second basically says: “God has my back on a number of things, but She also expects me to do my part”.

Nerevarine76 7y ago

> Businesses are paying market rates salaries to employees who generate them revenue. You use this argument to defend engineers but then question c—level executive salaries. The exact same principles apply but at a multiplicative level.

goatinaboat 7y ago
You use this argument to defend engineers but then question c—level executive salaries. The exact same principles apply but at a multiplicative level That’s simply not true, workers and managers are qualitatively different. There are no shortage of examples of managers of companies losing money and marketshare who nevertheless are paid bonuses every year then leave with a golden parachute.
antonvs 7y ago
> but at a multiplicative level. Why? That multiplier is often what's at issue, and why "the exact same principles" don't apply.

wmeredith 6y ago

Eh, trust is earned (in both directions of course). I’ve been badly burned by devs and managers alike over the course of my career.