[marcus_holmes]

Engineer A built the new widget that Sales have been talking about for months. This immediately generates $1m in revenue.

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?

[toomanybeersies]

Building on this:

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

[andrey_utkin]

Each of these tasks, or ongoing commitments, has a clear price when you run an organization the Internal Economics way.

Whoever consistently "earns" more than their salary this way, deserves a raise.

[blackbear_]

The key question is how do you quantify earnings/savings? In the example:

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.

[andrey_utkin]

It's an investment problem for those who hold the money in the organization.

Say, we have an organisation consisting of exec team and engineering team.

Engineering team has a bright idea that a certain undertaking will reduce time to make one widget. They bring this case to exec team. "It will reduce the cost of a widget from X1 to X2, the project will take T time and cost C."

If exec team sees this investment interesting and possible, they make that investment. The worth of the project is simply its cost C. Exec team willingly paid, and if they got what they wanted for it, they should be happy with "productivity". (Similarly to how you don't bemoan "productivity" of the baker you buy your bread from.)

[blackbear_]

Yes. Again, properly estimating X1, X2, T and C is so difficult in most cases that this strategy is not really applicable (notable example: technical debt).

[andrey_utkin]

See http://www.hubbardresearch.com/wp-content/uploads/2019/06/In...

[blackbear_]

Calibrated estimates with huge uncertainty ranges are still useless, even if calibrated.

"One month of refactoring this component can save us between 500k and 50M in the next five years with 90% probability" - this is not very useful for the decision maker, yet it is quite difficult for a domain expert to narrow the range.

[marcus_holmes]

Ok, but some tasks are less valuable and take more time to do, but are completely necessary. How do you value something like that? What if the "value" is actually less than the cost of the task (but it's still absolutely necessary)?

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 ;)

[andrey_utkin]

> What if the "value" is actually less than the cost of the task (but it's still absolutely necessary)?

This is a false premise. But it's surprising how many people seem to hold it, to their peril.

> I have a feeling that all you're doing is shifting the complexity around. The underlying complexity is still there

That's right, but do you agree this approach moves it to a place where it makes more sense, where it informs good decisions and is manageable?

> it's impossible to accurately estimate a development task and impossible to measure developer productivity

It's not impossible, but it's not something we as a society or an industry have a common fine grasp on. On this topic, I like best the books by Doug Hubbard: "How to measure anything" and "The failure of risk management: what is it and how to fix it".

It just requires yet another unusual mindset: probabilistic thinking, in addition to the above-established value-based thinking. You have to use a technique called calibrated probability assessment. We started practicing this at my workplace, and it seems to be working as intended, but we're not well calibrated yet.

[marcus_holmes]

> That's right, but do you agree this approach moves it to a place where it makes more sense, where it informs good decisions and is manageable?

I have no idea. I don't know enough about the approach to assess it. I like the idea of it, but I'd be concerned about the method of valuation. There's a lot of hand-waving in corporate accounting and the value of anything in a company is mostly a made-up number (enforced occasionally by accounting standards). I'd be concerned that all it does is externalise (and therefore politicise) the kind of decisions that a good CTO normally makes internally.

> It's not impossible

I should have refined my statement. It's impossible to give a definitive estimate for software development. You can definitely give a probablistic one (which I think is what you're talking about), but that's usually unacceptable to the rest of the executive team. Educating the rest of the executive team to think in probabilities sounds harder than just telling them "no you can't have a definitive deadline" ;)