Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The economics of software teams: Why most engineering orgs are flying blind

viktorcessan.com

Post reply on HN
Print view View original

31–40 of 299 posts

Re: The economics of software teams: Why most engineering orgs are flying blind

#31

Post by SpicyLemonZest »

tweetle_beetle wrote: post #24
InfinityByTen wrote: post #7

When I see someone just throwing a lot of numbers and graphs at me, I see that there are in to win an argument, and not propose an idea. Of late, I've come across a lot of ideas from Rory Sutherland and my conclusion from listening to his ideas is that there are some people, who're obsessed with numbers, because to them it's a way to find certainty and win arguments. He calls them "Finance People" (him being a Market…

As with most things, isn't the truth somewhere in the middle? True cost/value is very hard to calculate, but we could all benefit by trying a bit harder to get closer to it. It's all too common to frame the tension as binary: bean counters vs pampered artistes. I've seen it many times and it doesn't lead anywhere useful.

Here I think the truth is pretty far to one side. Most engineering teams work at a level of abstraction where revenue attribution is too vague and approximate to produce meaningful numbers. The company shipped 10 major features last quarter and ARR went up $1m across 4 new contracts using all of them; what is the dollar value of Feature #7? Well, each team is going to internally attribute the entire new revenue to themselves, and I don’t know what any other answer could possibly look like.

Re: The economics of software teams: Why most engineering orgs are flying blind

#32

Post by cmarot »

lknuth wrote: post #10

Making it solely about the extraction of dollars is a great recipe to make something mediocre. See Hollywood or Microslop. Its like min-maxing a Diablo build where you want the quality of the product to be _just_ above the "acceptable" threshold but no higher because that's wasting money. Then, you're free to use all remaining points to spec into revenue.

Exactly. In addition, sometimes a good software "only" makes you save 1% of your time, but that 1% was a terrible burden that induced mental fatigue, made you take bad decisions, etc. It can even make a great Engineer stay when he would have left with the previous version.

Re: The economics of software teams: Why most engineering orgs are flying blind

#33

Post by csomar »

sdevonoes wrote: post #27

Still don’t understand what regular people (like the author) gain from selling how wonderful AI is. I get that the folks at Anthropic and openai shove AI through our throats every day, but nobodies?

He is selling consulting around AI/LLM.

Re: The economics of software teams: Why most engineering orgs are flying blind

#34

Post by ozim »

Then let's disregard cost of running and maintaining a system for having exact financial feedback.

We do proxy measurements because having exact data is hard because there is more to any feature than just code.

Feature is not only code, it is also customer training, marketing - feature might be perfectly viable from code perspective but then utterly fail in adoption for reasons beyond of Product Owner control.

What I saw in comments — author is selling his consultancy/coaching and I see in comments that people who have any real world experience are also not buying it.

Re: The economics of software teams: Why most engineering orgs are flying blind

#35

Post by diatone »

InfinityByTen wrote: post #7

When I see someone just throwing a lot of numbers and graphs at me, I see that there are in to win an argument, and not propose an idea. Of late, I've come across a lot of ideas from Rory Sutherland and my conclusion from listening to his ideas is that there are some people, who're obsessed with numbers, because to them it's a way to find certainty and win arguments. He calls them "Finance People" (him being a Market…

You’re illustrating one of the points of TFA - a team that is equipped with the right tools to measure feature usage (or reliably correlate it to overall userbase growth, or retention) and hold that against sane guardrail metrics (product and technical) is going to outperform the team that relies on a wizardly individual PM or analyst over the long term making promises over the wall to engineering.

Re: The economics of software teams: Why most engineering orgs are flying blind

#36

Post by barrkel »

The argument against platform teams needs to be balanced with the compounding nature of technical debt.

The argument to always go for the biggest return works OK for the first few years of high growth (though the timeline is probably greatly compressed the more you use AI), but it turns into a kind of quicksand later.

Re: The economics of software teams: Why most engineering orgs are flying blind

#37

Post by bob1029 »

I don't understand the urgency around quantifying every aspect of the software process. Surely, we are in agreement that money in must at least equal money out if the company is to be viable? This is a simple quickbooks report, is it not?

Why don't we instead focus our energies on the customer and then work our way backward into the technology. There are a lot of ways to solve problems these days. But first you want to make sure you are solving the right problem. Whether or not your solution represents a "liability" or an "asset" is irrelevant if the customer doesn't even care about it.

Re: The economics of software teams: Why most engineering orgs are flying blind

#38

Post by LegNeato »

lynx97 wrote: post #19
Smaug123 wrote: post #8

Earlier quoted context omitted.

"Flying blind" is a completely standard idiom originating from flying while blinded by e.g. cloud or darkness. Its meaning is a figurative transplant of a literal description.

I know it’s an idiom. The point is that it still uses blindness as a stand-in for incompetence/unsafe guessing . Being common doesn’t make it harmless. Common just means we’ve normalized it. And you defending it shows that weve normalized it to a point where the double-meaning is seemingly only apparent to blind people.

No, it means not being able to see what is going on. Which is literally what the word blind means. You can be blinded by many things (blindfold, clouds/fog, bright lights, darkness, accidents, genetics, etc), permanently and temporarily. Non-humans can be blind and blinded. YOU are making it about a specific situation and projecting value judgements on it.

The author specifically says FLYING blind. Not "stumbling around like a blind person" or some such. If you are offended, that is on you. It's your right to be offended of course, but don't expect people to join in your delusion.

Re: The economics of software teams: Why most engineering orgs are flying blind

#39

Post by srdjanr »

lynx97 wrote: post #19
Smaug123 wrote: post #8

Earlier quoted context omitted.

"Flying blind" is a completely standard idiom originating from flying while blinded by e.g. cloud or darkness. Its meaning is a figurative transplant of a literal description.

I know it’s an idiom. The point is that it still uses blindness as a stand-in for incompetence/unsafe guessing . Being common doesn’t make it harmless. Common just means we’ve normalized it. And you defending it shows that weve normalized it to a point where the double-meaning is seemingly only apparent to blind people.

Well flying blind is unsafe guessing (ignoring modern instruments), that's a fact. But only "flying" and "blind" together. No one thinks this makes the word "flying" has a negative connotation here, and same with "blind".

Like "drinking" and "driving". On their own, they're both neutral, but "drinking and driving" is really bad.

Re: The economics of software teams: Why most engineering orgs are flying blind

#40

Post by [deleted] »

lynx97 wrote: post #19
Smaug123 wrote: post #8

Earlier quoted context omitted.

"Flying blind" is a completely standard idiom originating from flying while blinded by e.g. cloud or darkness. Its meaning is a figurative transplant of a literal description.

I know it’s an idiom. The point is that it still uses blindness as a stand-in for incompetence/unsafe guessing . Being common doesn’t make it harmless. Common just means we’ve normalized it. And you defending it shows that weve normalized it to a point where the double-meaning is seemingly only apparent to blind people.

[deleted]
Post reply on HN