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 management has become an imposter role, a side door into tech companies for people who can't contribute to the sales, financial, or technical parts of the business. They would just be bloat if that was where it stopped, but these imposter roles task themselves with making important decisions, at the company's expense.

Like the author, I've found some success in forcing accountability, to the point that imposters hand off decisions to someone who can legitimately navigate to a solution. A lingering problem is that business decision making isn't about one-time decisions, it's about decision making rate. As long as poor decision makers can retain their position in the critical loop, they will impede the ability of the business to function. The solution is building the organization around accountability and consequences for misallocating the company's resources: setting up a system where the organization tends towards competent decision makers gaining influence, and incompetent decision makers losing influence or leaving.

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 - which delivered what is was asked for (even sometimes knowing that it was not going to work).

The more I think about it, I get a feeling that if your core product depends on software and your CEO doesn't know how to develop software, then your company is doomed to fail. And because all companies depend on software nowadays, more and more are doomed to fail. There's also this new idea of CFOs running the company. But they don't run the company, they run the books. It's hard to grow a product based on the books.

It's confusing and it looks to me that less and less people have the balls to be accountable for their lack of action.

>But, thanks to my CPO and CEO’s support, I can say that we are building software using product bets. We identified a handful to take to the leadership team earlier this year. They estimated the value, then chose a specific set of bets for us to pursue based on our capacity. It’s definitely elevated our conversation around product strategy, and I can see it getting even better as we gain familiarity with the approach.

> What we haven’t done yet is finish any bets. We just started our first formal bets this year. So I can’t yet tell you how it will turn out.

Sounds good, let's check back in a year!

This seems to assume that any endeavor in software is something entirely established from scratch. There are no patterns, experiences or reusable parts that can be relied on. A hack at it until it works methodology.

Accordingly, it seems to imply that we as developers can’t be accountable for anything but effort. It’s a sad condemnation of our industry, and at odds with any (normal) commercial undertaking that has limited resources that must be allocated among competing alternatives.

Any real manager knows the basics of calculating the best choice amongst competing alternatives by establishing projected cashflows and calculating the PV (present value) of each. But not for software - we’re too special.

(normal) - one that can sustain itself on a commercial basis, rather than just on injected capital or borrowed funds.

I liked the article, it is really in depth.

Thing is I am taking the opposite approach because author has different goals.

Author gets to be VP of engineering on company that has multiple product teams and he gets to sit at "the table".

I am engineering lead for a company that has one dev team, I can give my opinions and run stuff however I want but I don't get a sit at the table.

The way I see it if I would like to take authors approach I would be like Scotty trying to go over commanders head - going with the analogy as software engineer I run the ship I am not making decision or being responsible about where the ship goes.

So my approach is that I minimize responsibility of the engineering team and I use scrum to do so. We are accountable for running the ship on time, every sprint gets delivered, every release is delivered like a clockwork. Business gets their input and output - if they have clear requirements that are small enough for the sprint going in, they will get change on production after 6 to 8 weeks.

We cannot promise something will be there in 6 months or a year, we can work on figuring out requirements with business and find out what we can promise to be there in 8 weeks on production.

We guard the process so we have predictable schedule on finished tasks and releases - what is finished or almost finished goes to the release candidate and we promise RC will be in 2 weeks on production and most of the time it works.

Yes we can do an emergency bypass and get someone to work on something ASAP - but it really has to be important, not something "a person" thinks is important.

Prediction is state A of the application + 2 weeks that is fully possible for reasonably well written requirements. If someone wants to hold me accountable for their grand vision I say no, he has to deliver requirements that I can help him with -

so just developers should not let themselves to be pushed around to be responsible for more than they actually should.

Just like captain in Star Trek has no say about how the ship has to be run I don’t want business guys coming over and making me do stuff their way.

Complete side note: I’m on public wifi right now and the domain used to host the images in this article is, for some reason, blocked. But as the author (or whatever tool was used to generate the article) has taken time to write decent `alt` text, I can still get a good idea of what is going on. Kudos.

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 that will make you a .300 hitter. “I want to take 50 swings in batting practice per day. I want to workout once per day. I want to spend 30 minutes watching films of the next pitcher I’ll face…” etc.

In reality, it’s probably a little of both. For example, Sales teams are often compensated on revenue generated (outcome), but what if you did a good job (process) but didn’t hit your numbers because the market was just really bad in your vertical? A good leader will recognize this and still compensate you (i.e. hold you accountable) appropriately rather than punishing you for the outcome.

If one leader hits their targets in an easy environment, and another misses but comes close in a really challenging environment by being really creative and scrappy and clever, the second leader should be the one with the big reward.

You should be judged on how well you play your hands, not solely whether you win the game.

"And like medieval scholars drawing elephants they’ve never seen, we make those interpretations through the lens of our own biases."

Those images are quite amusing. They drew an elephant like a boar but with odd tusks. So the tusks were probably described correctly (semi-correctly) for the most part, but the size is totally wrong, which is weird. It's like ... "hey, I saw a thing with huge tusks but it was not bigger than a boar."

Or perhaps the one who drew this just imagined a strange boar, and never heard of the tusks. It's strange.

I still need those features and a date. Thank you, Sales & Marketing.

This guy hasn't actually worked in sales or marketing and it shows.

>To do so, we have to take accountability, rather than [just] allowing it to be forced upon us.

Ah, one should think of accountability as a 2-way pipe rather than a sink!

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

thanks so sharing

Let's say we got someone to be accountable for something. And that something has failed horribly. Now what?

Infact, the first problem would be to identify whether something is a success or failure. This is tough, as anything can be dressed up as success, attributing any negatives to the external factors. Any determination (success or not) would mostly go by perceptions people have on other people, but not really by what happened on the ground, unless it is so glaring or media made a fuss about it.

Assuming it was somehow classified as a failure, the next bigger issue to identify whom to blame. At this point, it would fizzle out with a circular to everyone stating a new policy or general guidance, without naming anyone.

Let's say we have a rare instance where a person was named as accountable for the failure. Mostly likely it will be shown as team decisions and team work that resulted in failure. Can the entire team be fired? No way. Infact the team would be rewarded for going through such crisis situation that got high visibility.

Most preachings about accountability and responsibility do not go into how to actually use them in the aftermath of a failure or success.

ChatGPT 说：

I really liked how this post digs into the accountability gap that exists in so many organizations. It’s not that people don’t care or aren’t trying — it’s that no one feels real ownership for outcomes once responsibilities get spread across layers of management. I’ve seen this happen in agile teams too: endless retros, reports, and syncs, but no one truly driving the result. What resonated most is the idea that accountability shouldn’t come from top-down pressure, but from mutual trust and clarity of purpose. When everyone knows why something matters and can see the impact of their work, accountability becomes natural instead of forced.