The book I referred to answers the "but engineering team doesn't have revenue".
Engineering can be art, sure, and if you like, we can even discount the idea that art creation can be seen as economic activity. But is there a need to measure productivity then?
Cost of running it includes engineering salaries, so isn't a good measure to include when you measure productivity of engineers. A productive engineer would be worth a higher salary, but if you include the cost of that higher salary reducing his value would that also reduce the salary you want to pay? Doesn't make sense.
Engineering: costs (salaries + infra) are covered by revenue (services rendered to exec team). Executive team: costs (execs salaries, expenses to pay engineers and sales for their services, accumulating interest to be returned to investors if any) are NOT covered by revenue (which comes from customers).
I find this decomposition incredibly neat and enabling solving the right problems.
It indeed doesn't. Where did you get that idea? It's not as complicated as you probably think.
If the engineer has rendered services which are worth his salary + his actual expenses to achieve that, he has earned exactly his salary, high or low.
Engineer B removed some tech debt. Future efforts to build widgets will take less time to build.
Engineer C rewrote the backend to prevent a vulnerability exposure that could have lead to disaster.
Who was most productive? Who deserves a raise?
Engineer D spent months working on a project that was cancelled by management
Engineer E was tasked to build a feature that no customers ended up using
Productivity is a team effort. Even most brilliant engineer will be unproductive if they're given unproductive work
Whoever consistently "earns" more than their salary this way, deserves a raise.
Future efforts to build widgets will take less time to build -> How to quantify ? Vulnerability exposure that could have lead to disaster -> How to quantify ?
What you are saying is nice and clean on paper but simply impossible in practice.
And if a task has an internal price on it, but the development time slips, to the point it exceeds the price, do you stop development?
I think this method is interesting, but I have a feeling that all you're doing is shifting the complexity around. The underlying complexity is still there (it's impossible to accurately estimate a development task and impossible to measure developer productivity). I guess that's a good thing, though - now the whole company has to deal with the complexity rather than just the dev team ;)
