It is hard to tie every job or action to revenue. Let's say I'm a platform engineer who makes internal tools. I generate no attributable revenue of my own; I make other engineers more efficient. But how much? We can't run an experiment where engineers don't use my platform because it's mandated; directly using the PaaS is forbidden.
Or I'm a manager. I help my engineers get work done. Let's consider the happy case and assume we can measure our team's revenue. How much of that revenue is attributable to the manager's superior skill, and how much to the rockstars under him/her? What would an experiment look like; the engineers manage themselves, or we compare with the previous manager?
No company that I know goes this far. In their defense, it is a challenge. An open problem, even.
You wouldn't run an A/B test to quantify your impact, but you could pretty easily do before/after metrics (or just collect them on the way during a graduated rollout) for any feature you're rolling out. It should be straightforward to quantify productivity benefit for a large initiative.
> How much of that revenue is attributable to the manager's superior skill
The output of a manager is the output of their team. We can't A/B test managers (or at least, we probably shouldn't), but we can look at a cohort of managers and see how well their teams are generating business impact. Combined with other data (e.g., upward feedback surveys, level-skip 1on1s, retention metrics, etc.), we can measure the impact of a manager.
> The output of a manager is the output of their team.
People say that but it makes no sense. That means the same manager would have a different "output" going from one team to another. Are you going to cut his/her salary if he leaves a big, successful team to help fix a flailing team because it has less output?
I get it: doing it this way is easy. My ideal is marginal attributable revenue or profit. How much better are you than the next person? We can haggle over the marginal part but I'm not conceding on attribution. Otherwise you're mooching off other people's work. Why are we paying you the big bucks? Show me what you did.
> People say that but it makes no sense. [...] Are you going to cut his/her salary if he leaves a big, successful team to help fix a flailing team because it has less output?
I think it works fine if we add on the concept that a good manager operates on a different timescale. The on-boarding timeline for a first-line EM can be months at some companies.
In your example, the manager moving over should be given a compensation package based on the expected value he's going to get out of the flailing team once he works his magic. (And, indeed, this is exactly the kind of package often given to externally-hired CEOs brought in for turnarounds.)
> Otherwise you're mooching off other people's work. [...] Show me what you did.
But that's just it. The manager's skill is improved utilization of resources. The leader's skill is improved direction of resource utilization. By definition, those skills are expressed on the canvas of the team they lead.
Or, more simply: A leader without followers isn't actually a leader at all!
And, indeed, we see that in the real world too: A successful executive in one company goes elsewhere, doesn't fit in with the new company's culture, and performs terribly. It's a tale as old as time.
Managers need to sign off on how many hours it saves. Its their neck at the end of the day.
It helps that we are often saving ~400 hours/yr spending ~80 hours or less.
We can also see it in overtime hours being eliminated, and the (real) engineers are making more complex designs but the size of the team hasn't changed.(30% more complex in 2.5 years, same team size) They also havent replaced engineers that left the team.
Basically: We save enough hours that it is obvious. There are added benefits like not having humans do manual checks, so less prone to errors. (Although I argue that our bugs are equally as dangerous)
Making sure those $ saved didn’t screw things up somehow is the hard part to measure.
And - this is going to blow your mind - but sometimes you can actually make things more efficient by spending more money. Cutting costs can be the exact opposite of the right thing to do.
So while I am jealous that your productivity can be measured so simply, I’m dubious about how many programmers’ contributions can be so easily reduced to a simple metric.
We can take or reject projects, so if you are a bad predicter of use/time to completion, you are going to do worse.