[andrey_utkin]

Engineering activities are economic activities.

Engineering activities must make sense as economic activities.

Engineering activities productivity can be measured the same way the productivity can be measured for any economic activities.

See "Internal Market Economics: Practical Resource-Governance Processes Based on Principles We All Believe In", Book by N. Dean Meyer.

The posted article came so close to the idea of the right measurements, I was intrigued and was like "yes, say it!", but the author didn't say what I expected, instead they pointed at quantifying calendars and commit logs. What a bizzare self-contradiction.

[dmos62]

So what is that true way to measure productivity you alude to? By the way, engineering can be an economic activity, but it doesn't have to be. Could be an art as well, for example.

[andrey_utkin]

Simply: does revenue exceed cost of running it?

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?

[username90]

> Simply: does revenue exceed cost of running it?

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.

[dmos62]

Also, what if engineering is good, but sales is bad? Engineers might exceed their productivity goals, but it wouldn't amount to profit.

[andrey_utkin]

Then from the internal market economics PoV, here's how it looks:

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.

[andrey_utkin]

> 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.

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.

[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.)

[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.

[visarga]

> Engineering activities productivity can be measured the same way the productivity can be measured for any economic activities.

The economy is basically a population based evolutionary process. Its nature is open ended - things that seem important now might have been seen as being useless or stupid a decade or two ago, like neural nets in 1985 and personal computing in 1950's. So we can't tell ahead of time which will become important, but the exploration process and extreme diversity are the main gain. It's all about getting to those stepping stones that we don't even know we will need. Inspired engineering is eventually rewarded with economic success, just like biological evolution.

[andrey_utkin]

So what's your point? Mind you, we're discussing an article on engineering productivity in business.

Nothing is happening without funding.

Business can't run producing things which are not valuable in the moment, it will go bankrupt.

Government can sponsor such things as it sees fit, best if guided by a clear hypothesis that funding it makes the outcomes probabilistically better than not funding it.

When nobody is paying you but you're tinkering with some stuff, then it's you who is sponsoring it with your time and other resources.

[visarga]

That's exactly my point - following the gradient of money you won't get to the global optimum because it's just a short sighted signal. You need to invest into crazy ideas to get anywhere. Unknown unknowns don't get discovered in a systematic way and are not profitable step by step.

If your name is Christopher Columbus and it's 1492, your project gets rejected for being implausible, what do you do?

[nytgop77]

Pitch it to different investors. His own country Italy did not fund him, so he pitched it to Spain.