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.
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.
"This just became a JOB..." -Gilfoyle
[1]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.
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.
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.
vs.
"Not everything that can be counted counts, and not everything that counts can be counted"
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.
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.
Nah, you have it completely backwards. If the users said “this specific job took 5 minutes today but was only 1 minute yesterday”, that’s actionable, you can e.g look at what changes were deployed overnight.
But users always say “the system is slow”, even if they have only the vaguest idea of what “the system” is, and even if it’s actually faster than yesterday. It’s not really clear what any sysadmin can do other than spending hours every day painfully extracting the details from the user only to find nothing is wrong. Every day, forever.
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.
https://en.m.wikipedia.org/wiki/God_helps_those_who_help_the...
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.
Why? That multiplier is often what's at issue, and why "the exact same principles" don't apply.
