The Accountability Problem • Hacker News Board

Re: The Accountability Problem

#41

Post by jeremyjh » Sun, Oct 19, 2025, 2:48 PM UTC

Esophagus4 wrote: post #31

A bit rambling and meandering, but some decent points in there I guess. Lost me on the elephants. Setting goals on estimated value vs measured value is the difference between a process goal and an outcome goal. I guess the idea is you can’t control outcomes, but you can control your process inputs. In baseball, for example, if you want to be a good hitter, don’t set a goal to hit .300, set a goal to do the things tha…

This just pushes the responsibility for outcomes farther from the people doing the work. The CEO is going to answer to the board based on outcomes. If the sales leader knows they can't penetrate a market or engineering leader knows the feature will flop and they don't change the company's strategy then they are failing.

Re: The Accountability Problem

#42

Post by Esophagus4 » Sun, Oct 19, 2025, 3:00 PM UTC

jeremyjh wrote: post #41

Esophagus4 wrote: post #31

A bit rambling and meandering, but some decent points in there I guess. Lost me on the elephants. Setting goals on estimated value vs measured value is the difference between a process goal and an outcome goal. I guess the idea is you can’t control outcomes, but you can control your process inputs. In baseball, for example, if you want to be a good hitter, don’t set a goal to hit .300, set a goal to do the things tha…

This just pushes the responsibility for outcomes farther from the people doing the work. The CEO is going to answer to the board based on outcomes. If the sales leader knows they can't penetrate a market or engineering leader knows the feature will flop and they don't change the company's strategy then they are failing.

That’s… a strange dismissal of my point, and not based in reality. And despite yourself, you’re agreeing with me. The smart sales leader will find creative ways to pivot. And even if they don’t hit their numbers for factors outside their control, if they played their hand well, that’s what you reward.

If you’re solely graded on outcomes, you end up with very bizarre behavior as people game the system.

See: surgeons avoiding high risk patients because they don’t want to ding their outcome scores. And see Wells Fargo employees fraudulently creating accounts for people to boost their numbers.

You want to have an org that encourages (calculated) risk taking and rewards those who persevere though difficult situations.

Re: The Accountability Problem

#43

Post by gubicle » Sun, Oct 19, 2025, 3:01 PM UTC

alphazard wrote: post #29

Everyone who has worked in tech should reflect on the fact that it would be shocking to see a product manager produce a spec for the behavior of a feature, or a spreadsheet with discounted value analysis as in TFA. Those are both artifacts that aid in decision making, and especially aid in making the kind of decisions that product orgs have taken from other more qualified people at a company. Unfortunately, product m…

The (relatively big and successful) tech company I work at, has gradually seen ~all high level decision-making positions filled with PMs, while senior engineers who have been at the company for years are being pushed out and/or leaving. Most of these PMs have very little understanding of the tech, the market, or how software engineering works, yet they now make ~all of the product decisions at the company. I haven't worked on anything remotely useful, or bottom-line impactful in 2 years. I was originally very optimistic about the company and elected to get paid in as much stock (vs cash) as possible... which I now realize was a big mistake.

Re: The Accountability Problem

#44

Post by pessimizer » Sun, Oct 19, 2025, 3:42 PM UTC

I really like this idea, and he seems to have gotten a good way into trying to formalize it.

I think there should be a lot more gambling carefully designed and introduced into processes and institutions, and that the reason we don't do it is because of an almost religious reverence for markets, and the idea that they are natural. There is nothing natural about a market; what they are is useful. They are artificial, intentional situations that converge to a particular desirable outcome, and an effort is made to remove all fluff and friction that doesn't encourage that outcome. A price auction is a game, and it's designed by the people who certify and enforce the sale.

Having different departments estimate potential gains and quantify what they're willing to risk for those gains, and having developers decide whether they can get something like that done for that amount, and using the success of those wagers for accounting purposes seems like it has a lot of potential. Your product manager might just be a full time bookie, looking at every step in the process and trying to figure out whether bets that have been made by different departments will pay off, and trying to match bets against each other to come out even. His job would be to give everyone credit to bet with (and to "cut off" bad bettors.)

Re: The Accountability Problem

#45

Post by pessimizer » Sun, Oct 19, 2025, 3:48 PM UTC

skydhash wrote: post #28

firesteelrain wrote: post #27

Earlier quoted context omitted.

In all of these types of stories, it is always the CEO or CTOs fault the way it is framed. There is never any accountability on the engineers part. CEO/CTO sets the vision. They are not the ones developing the UI or developing the API or writing documentation etc CEO determined there was a market fit or vision for a product, convinced an investor or shareholder to invest based on multiple reviews of this vision then…

> it is always the CEO or CTOs fault the way it is framed. There is never any accountability on the engineers part. If we're going with the military analogy in TFA, it's always the general fault for loosing a war. Especially if the soldiers did all they were told to do. He's the one in control making all the major decision. > CEO/CTO sets the vision. They are not the ones developing the UI or developing the API or wr…

> If a general only stays in a bunker, deciding things based on map and single line reports, then it's a poor general.

This is a bit of an exaggeration: if he can pull the signal out of the maps and single-line reports and deliver results, then he is a good general. The point is he can't blame his failure on the fact that he didn't know what was happening, because his job is to understand enough to make money. If he failed because didn't understand, then he should have been prioritizing his information pipeline (whether that's personal knowledge or it's finding the right people to deliver the correct information to him intelligibly.)

Otherwise, it's like saying you weren't responsible for the car accident because you were drunk.

Re: The Accountability Problem

#46

Post by master_crab » Sun, Oct 19, 2025, 3:59 PM UTC

drooby wrote: post #35

alphazard wrote: post #29

Everyone who has worked in tech should reflect on the fact that it would be shocking to see a product manager produce a spec for the behavior of a feature, or a spreadsheet with discounted value analysis as in TFA. Those are both artifacts that aid in decision making, and especially aid in making the kind of decisions that product orgs have taken from other more qualified people at a company. Unfortunately, product m…

I was spoiled at my first company out of college. My director cared deeply about product specs, acceptance criteria, and making sure engineers actually understood product and business decisions. It was so nice. Oh, how sweet and naive I was to the world… hahah. It still blows my mind that product isn’t treated like a soft engineering discipline in its own right. When product doesn’t do its own thinking, the cognitive…

Any product person who hasn’t had years of engineering or sales needs to be taken out back and treated like Old Yeller (metaphorically of course). If you can’t deeply associate with the customer or comprehend the engineering of systems, you are not fit to be in the flow from keyboard to customer.

Re: The Accountability Problem

#47

Post by alphazard » Sun, Oct 19, 2025, 4:49 PM UTC

pols45 wrote: post #40

alphazard wrote: post #34

Earlier quoted context omitted.

A whole generation has come up thinking that it's normal for the direction of the product to be guided by the dumbest, least competent people in the room. Pretty much every tech company has, or aspires to have a product org. The best intuition pump I have for product managers is the analogy of hedge fund managers. There exist people who can predict the market, just like there exist people who can predict how a produc…

Competence is not magic. There are unpredictable and complex problems that competence can't solve - see The Theory of Bounded Rationality. So what happens when the "competent" can't solve what falls in their lap given constraints like resources/time/team etc? They will either say we can't do it (someone else like Trump will put up his hand immediately and say but I can, I can do anything, Hilary is just a clown choos…

I think we are just using the word competence differently. It's not an innate quality. It's an observed quality. I would define it as the ability to perform a task well.

Flipping a coin has no skill component, it's all chance. It's impossible to be competent at flipping a coin. Poker has a skill component. A single hand is mostly luck, but repeated hands tend to result in the same few players having more at the end. That is observable evidence that poker has a skill component, and it make sense to call people with that skill "competent at poker".

If a problem is complex or unpredictable, then there will be a luck component, but chain enough of those together (like over the course of a few quarters at a company), and the luck washes out leaving a skill signal.

The short-term noise actually helps those in imposter roles hide their lack of competence. It's like a poker player that never bets, and decays their bankroll slowly enough that no one really notices. Then through politics they are able to get a refill, and stay at the table to let it slowly decay again.

Re: The Accountability Problem

#48

Post by array_key_first » Sun, Oct 19, 2025, 5:16 PM UTC

ronbenton wrote: post #19

akickinthestone wrote: post #17

On one company I worked on, in one year tech team shipped 53 epics, delivering all the features sales, CS and product needs. By EOY the company grew zero. Literally zero. This was a series A company. CTO got in a meeting with the CEO and said: we delivered everything you asked for, but the company didn't grew. What went wrong? CEO wasn't able to act on this. In the end the company started by laying off the tech team…

Why does the CEO knowing how to develop software matter? This sounds more like the company was unable to sell the software, either because of product/market fit or some other reason

Because the CEO needs to understand their product deeply to know what is achievable, what isn't, and how easy it is. Many (most?) software products leave simple "duh" type features on the table, while they pursue incredibly difficult and brittle things instead. This can be prevented.

Just like how, IMO, a car company CEO needs to know how a car works very well. They should know enough to gauge that a dual clutch transmission on a 30,000 dollar car is risky and will blow up.

Again, we see this same sort of problem with cars. Cars will have all these incredibly complex bells and whistles. But then the basics, like the engine and transmission, suck ass and break down. And that's why Honda and Toyota eats their lunch.

Re: The Accountability Problem

#49

Post by marcosdumay » Sun, Oct 19, 2025, 5:20 PM UTC

nerdponx wrote: post #38

alphazard wrote: post #29

Everyone who has worked in tech should reflect on the fact that it would be shocking to see a product manager produce a spec for the behavior of a feature, or a spreadsheet with discounted value analysis as in TFA. Those are both artifacts that aid in decision making, and especially aid in making the kind of decisions that product orgs have taken from other more qualified people at a company. Unfortunately, product m…

When somebody incompetent is hired to do a job, do you blame the incompetent person, or the person who hired the incompetent person?

On this case, probably the person that decided to split the job that way or the person that decided that somebody must be hired.

Re: The Accountability Problem

#50

Post by alganet » Sun, Oct 19, 2025, 5:55 PM UTC

> They called them “stories,” and “epics,” and recorded them in Jira, but they were more like technical tasks.

Yep. Mostly title-only technical tasks that will end up as a point in a graph, and an excuse to put tools over people instead of people over tools. A true perversion of the agile core principles. Jira-oriented product development killed agile.