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.
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 load shifts to engineering. Suddenly, engineers are doing parts of product’s job. The result is predictable: engineering gets stretched thin, and both Product and Engineering fail to fully document or even understand what they’ve built.
The project falls apart because Product drops the ball, but Engineering is the team at the end of the funnel, so the blame naturally tends to land on them. Product’s output is often hidden, and it’s easy for them to say, “Well, we did our part. Engineering just didn’t deliver.”
> The project falls apart because Product drops the ball, but Engineering is the team at the end of the funnel, so the blame naturally tends to land on them. Product’s output is often hidden, and it’s easy for them to say, “Well, we did our part. Engineering just didn’t deliver.”
I've seen this get worse with LLMs. I've had specs that were wholly or in significant part generated by ChatGPT, but they look detailed so the are plausible workslop. I've been given a spreadsheet with nonsense items "Implement adaptive intent-driven workflows across user touchpoints" (I generated this example with GPT).
When I asked what any of it meant I was met with silence. Later through the grapevine I hear the requirements were generated by ChatGPT and the guy responsible for them doesn't understand the system at all. But guess who is responsible for delivery?
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.
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.
I’ve struggled for a decade to pin down my frustration with most product owners and it’s this at the root. They are often true imposters. At a startup they are shielded by CEO founders who beat the imposter syndrome drum, giving legitimacy to their incompetence.
I've also heard this quite a lot. If they've never actually had to use the product or similar products in a professional setting, where their results mattered, then they aren't qualified to play the part of the user.
If the product has actual users, it's always better to talk to them directly, than to trust the opinions of someone who doesn't use the product to generate value every day.
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 product or feature is received by the market. Most people claiming to can't. The people who can are expensive. You can't reliably train white collar workers to be hedge fund managers, and you can't reliably train white collar workers to lead product development.
That mostly encapsulates all of the "but this guy at Apple" objections that get thrown around by people defending product orgs, as if they were a business insight that most of us don't yet understand.
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 choose me). Or they will say we need to buy more time/resources/team etc.
The point here is - if they can't fend of the Opportunists and if they can't buy more time/resources etc by themselves but end up being reliant on some one that can easily be framed as incompetence and will be framed as such by Opportunists.
So you want to change the game, be honest about what "competent" people do when faced with unpredictability and complexity ie understand their limits. They generally exit the space. And others fill the space.
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.
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.
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.
It does seem that something went wrong in your story, but I don’t think it’s the CEO not knowing how to develop software. Maybe I misunderstand what you mean by that phrase.
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 hired a set of people to execute on this vision.
Yes, there are plenty of bullshit artists out there. But, the product itself is developed by people below the CEO.
> 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 writing documentation etc
That's why you need a feedback loop. If a general only stays in a bunker, deciding things based on map and single line reports, then it's a poor general. You have to also have a clear sense of what the product is (dogfooding it if it's necessary) so that you can adjust its course. Vision is all bell and whistle. People wants to pay for solutions, not nice ideas. They may even be willing to invest in such solutions. But you have to deliver it.
> 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.
Unless a single person decided to go completely against what they are told and did something bad all on their own, then yes, it's always the CEO/CTO fault.
>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.
...by the passing of which the name of the game will be to find another vehicle for occluding reality and creating optics. Something to replace "bets" with "shaping" and "appetite", for example.
Connecting effort and outcome is hard as orgs get bigger, and a lot (a LOT) of those strategies have to do with optics and the "sponsors" being "on the wave" at the moment (trusted by owners/board). While it is not realistic to say "we do the work until it works and costs be damned" some tools for this are required, and I would say putting out a "bet horizon" of a year or a quarter is setting up some nice political battles in the future.
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 think this talk speaks to an idea that is true for early stage and small businesses. That is software development is a strategic investment not a tactical one. Maybe I don't need a product database and an API just yet, I could use a spreadsheet. But I choose to do it because software can enable teams to capitalize on opportunities more effectively.
Of course, once software becomes mature there will be tactical decisions in the margins. But greenfield software is usually a strategic decision.
I am not sure this comment it is in any way related to the article it is commentating on. To name one example the comment complains about the absence of PV calculations while the article actually specifically describes this.
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.
Amazing presentation, the real gold is buried somewhere in the middle:
"To paraphrase Kent Beck, professional software development is about...
Communication and collaboration between large numbers of people with different perspectives."
This is why large organisations suffer, communication;)
People say it a lot that the code isn't most of the value but the auxiliary stuff is, which is true - but the conclusion from that shouldn't be that the work itself isn't that important, it's just that you'll see way less of it in a large organisation.
This is also why a well-aimed startup can easily blow the socks off companies with thousands of employees - the communication overhead is high, accountability is very diffused and everything is codified.
In an ideal world, you'd spend 100% of your time with either the work or something adjacent (like research), but of course, that's completely unrealistic. But if you aren't doing work but something else, it's probably a good idea to ask yourself, does this matter? Does it help my goals?
The site is down for me, so I'll check back later because this sounds like it discusses something that I've seen my entire career in tech... Imagine showing up to work at the fire station after getting out of the fire academy and 50+% of the people working at your station (including your manager and their manager) have never been to the academy, they don't know anything about the engine, they've never donned turnouts, and never gone into a fire; they are "in charge", but have to ask the people they're managing what to do.
"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.
The ears are also extrange, but quite incorrect in shape and size, but they are not horse ears. Is it possible that they saw some tusks IRL, but no elephant ear?
About the size, one elephant is smaller than a horse but has 4 small guys standing on it. Is it possible that it was a standard convention to get everyone in the drawing, instead of tying to make a photorealistic image.
Before Renaissance perspective was developed, artists used relative size to indicate things like relative importance (kings and Jesus were sometimes 20-50% larger than their followers), or timescale, or as you are suggesting, convenience to fit things in.
Basically, they didn't put much stock in making the scale realistic throughout the piece.
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.
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.
That would be fine if Sales & Marketing wants to discuss priority, aka aligning needs with capacity. It's either make them happy and take the blame when the technical debt is unsustainable, or seen as uncooperative. I think it's hard for them to promise the moon if Engineering keeps reminding them about reality.
It's not really a criticism because the author is very clear this is about early stage startups. At least, it's not a criticism of the author, it will be if random people start to adopt the idea...
But yet another software administration policy that is against maintenance.
> 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.
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.)
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.
> Assuming it was somehow classified as a failure, the next bigger issue to identify whom to blame.
Accountability is to gain introspection about the past and intermediate states of an (interpersonal) system to figure out what decisions were made by whom, when, how, and in which context, so that they be analyzed and similar failures or whole failure mores can be avoided in the future.
It isn't the ability to properly find a scapegoat. You don't make people accountable to be able to fire them. You can fire them regardless. You make them accountable so that they have the ability to produce an account of what, how, and why happened at a given time.
> Are you saying a person who is accountable may not be held responsible for the outcomes?
No, please re-read what I said. I said that it's not about finding a scapegoat to fire, but about understanding what, where, and why happened. If you don't have an account of a problem, then you don't know where the problem is located; even if it should be solved by firing someone, then you don't have the tools to figure out who and why needs to be fired.
The person you are replying to describes something akin to retrospective but even in Agile we still have people who need to be accountable and that includes the engineers too.
Assuming you’re earnestly not seeing how this works rather than seeking an argument:
I work in an industry where accountability is the norm. Individual people perform well-known, but difficult-to-execute steps of various processes; strict metrics define success and failure; close calls are not ideal; and the distance between success and failure is usually not revealed without precisely calibrated equipment. The ways to measure the outcomes are legally codified. Everything can be checked and double-checked, and people can, and often do, check those checks. Even then, sometimes the person that determined the metrics got them wrong. Sometimes it was measured wrong. Sometimes the person that said it was wrong turns out to be wrong. My primary professional function is to determine adherence to those standards. Potentially thousands of lives are at stake if we get the wrong thing wrong enough.
With a sane commit history and code reviews, this is a lot easier in software than it is in most realms. It’s definitely easier than mine.
Accountability isn’t just about failure— it’s about owning outcomes and giving an account of what you did to contribute to that outcome, good or bad.
> answerability, culpability, liability
You left off the end of the sentence.
> equated with answerability, culpability, liability, and the expectation of account-giving.
Account-giving is the key, here.
Since we’re focusing on problems: mistakes have different causes: being careless, having outdated knowledge, having the wrong requirements, physical or mental problems, equipment malfunctioning, bad processes… to identify the root problem, you need an account of what happened. To get that, you need to identify the person or people involved, and figure out what went wrong. That’s the only way you’re going to mature enough organizationally to have any semblance of quality. As the saying goes: if everybody’s responsible for something, then nobody’s responsible for it. The distinction is accountability.
So you don’t need to fire someone to hold them accountable— even being ‘in trouble’ every time someone does something wrong is counterproductive if it makes people hide or shirk responsibility for their mistakes. If someone fucks up badly or frequently enough, then maybe they are in trouble, and maybe they do get fired? But there’s a whole hell of a lot accountability that happens before that.
People make mistakes, and any organization that does not tolerate mistakes is run by people without the emotional maturity required to properly run an organization. The same is true of people unwilling to identify those mistakes and figure out either how they can be avoided in the future, or if they can’t be reliably avoided, mitigate their effects. Some of the leadership’s primary responsibilities involve defining the desired outcome, measuring the difference between it and the actual outcome, determining if/how it matters, and figuring out why it’s different. Those that refuse to address, or even acknowledge problems (and again, it doesn’t have to be punitive,) are masking their own laziness or incompetence.
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.
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.
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 load shifts to engineering. Suddenly, engineers are doing parts of product’s job. The result is predictable: engineering gets stretched thin, and both Product and Engineering fail to fully document or even understand what they’ve built.
The project falls apart because Product drops the ball, but Engineering is the team at the end of the funnel, so the blame naturally tends to land on them. Product’s output is often hidden, and it’s easy for them to say, “Well, we did our part. Engineering just didn’t deliver.”
I've seen this get worse with LLMs. I've had specs that were wholly or in significant part generated by ChatGPT, but they look detailed so the are plausible workslop. I've been given a spreadsheet with nonsense items "Implement adaptive intent-driven workflows across user touchpoints" (I generated this example with GPT).
When I asked what any of it meant I was met with silence. Later through the grapevine I hear the requirements were generated by ChatGPT and the guy responsible for them doesn't understand the system at all. But guess who is responsible for delivery?
I suppose they quickly choose the side of the user, saying "you don't have to convince me, I'm just playing the user role here".
If the product has actual users, it's always better to talk to them directly, than to trust the opinions of someone who doesn't use the product to generate value every day.
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 product or feature is received by the market. Most people claiming to can't. The people who can are expensive. You can't reliably train white collar workers to be hedge fund managers, and you can't reliably train white collar workers to lead product development.
That mostly encapsulates all of the "but this guy at Apple" objections that get thrown around by people defending product orgs, as if they were a business insight that most of us don't yet understand.
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 choose me). Or they will say we need to buy more time/resources/team etc.
The point here is - if they can't fend of the Opportunists and if they can't buy more time/resources etc by themselves but end up being reliant on some one that can easily be framed as incompetence and will be framed as such by Opportunists.
So you want to change the game, be honest about what "competent" people do when faced with unpredictability and complexity ie understand their limits. They generally exit the space. And others fill the space.
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.
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.
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.
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 hired a set of people to execute on this vision.
Yes, there are plenty of bullshit artists out there. But, the product itself is developed by people below the CEO.
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 writing documentation etc
That's why you need a feedback loop. If a general only stays in a bunker, deciding things based on map and single line reports, then it's a poor general. You have to also have a clear sense of what the product is (dogfooding it if it's necessary) so that you can adjust its course. Vision is all bell and whistle. People wants to pay for solutions, not nice ideas. They may even be willing to invest in such solutions. But you have to deliver it.
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.
That shouldn't be an alien concept.
> 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!
Connecting effort and outcome is hard as orgs get bigger, and a lot (a LOT) of those strategies have to do with optics and the "sponsors" being "on the wave" at the moment (trusted by owners/board). While it is not realistic to say "we do the work until it works and costs be damned" some tools for this are required, and I would say putting out a "bet horizon" of a year or a quarter is setting up some nice political battles in the future.
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.
Of course, once software becomes mature there will be tactical decisions in the margins. But greenfield software is usually a strategic decision.
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.
"To paraphrase Kent Beck, professional software development is about...
Communication and collaboration between large numbers of people with different perspectives."
This is why large organisations suffer, communication;)
People say it a lot that the code isn't most of the value but the auxiliary stuff is, which is true - but the conclusion from that shouldn't be that the work itself isn't that important, it's just that you'll see way less of it in a large organisation.
This is also why a well-aimed startup can easily blow the socks off companies with thousands of employees - the communication overhead is high, accountability is very diffused and everything is codified.
In an ideal world, you'd spend 100% of your time with either the work or something adjacent (like research), but of course, that's completely unrealistic. But if you aren't doing work but something else, it's probably a good idea to ask yourself, does this matter? Does it help my goals?
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.
https://www.uliwestphal.de/elephas-anthropogenus/
About the size, one elephant is smaller than a horse but has 4 small guys standing on it. Is it possible that it was a standard convention to get everyone in the drawing, instead of tying to make a photorealistic image.
Basically, they didn't put much stock in making the scale realistic throughout the piece.
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.
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.
Ah, one should think of accountability as a 2-way pipe rather than a sink!
there goes your answer.
But yet another software administration policy that is against maintenance.
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.
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.)
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.
Accountability is to gain introspection about the past and intermediate states of an (interpersonal) system to figure out what decisions were made by whom, when, how, and in which context, so that they be analyzed and similar failures or whole failure mores can be avoided in the future.
It isn't the ability to properly find a scapegoat. You don't make people accountable to be able to fire them. You can fire them regardless. You make them accountable so that they have the ability to produce an account of what, how, and why happened at a given time.
The very first line in the Wikipeda article on Accountability states that "accountability is equated with answerability, culpability, liability".
Are you saying a person who is accountable may not be held responsible for the outcomes?
No, please re-read what I said. I said that it's not about finding a scapegoat to fire, but about understanding what, where, and why happened. If you don't have an account of a problem, then you don't know where the problem is located; even if it should be solved by firing someone, then you don't have the tools to figure out who and why needs to be fired.
I work in an industry where accountability is the norm. Individual people perform well-known, but difficult-to-execute steps of various processes; strict metrics define success and failure; close calls are not ideal; and the distance between success and failure is usually not revealed without precisely calibrated equipment. The ways to measure the outcomes are legally codified. Everything can be checked and double-checked, and people can, and often do, check those checks. Even then, sometimes the person that determined the metrics got them wrong. Sometimes it was measured wrong. Sometimes the person that said it was wrong turns out to be wrong. My primary professional function is to determine adherence to those standards. Potentially thousands of lives are at stake if we get the wrong thing wrong enough.
With a sane commit history and code reviews, this is a lot easier in software than it is in most realms. It’s definitely easier than mine.
Accountability isn’t just about failure— it’s about owning outcomes and giving an account of what you did to contribute to that outcome, good or bad.
> answerability, culpability, liability
You left off the end of the sentence.
> equated with answerability, culpability, liability, and the expectation of account-giving.
Account-giving is the key, here.
Since we’re focusing on problems: mistakes have different causes: being careless, having outdated knowledge, having the wrong requirements, physical or mental problems, equipment malfunctioning, bad processes… to identify the root problem, you need an account of what happened. To get that, you need to identify the person or people involved, and figure out what went wrong. That’s the only way you’re going to mature enough organizationally to have any semblance of quality. As the saying goes: if everybody’s responsible for something, then nobody’s responsible for it. The distinction is accountability.
So you don’t need to fire someone to hold them accountable— even being ‘in trouble’ every time someone does something wrong is counterproductive if it makes people hide or shirk responsibility for their mistakes. If someone fucks up badly or frequently enough, then maybe they are in trouble, and maybe they do get fired? But there’s a whole hell of a lot accountability that happens before that.
People make mistakes, and any organization that does not tolerate mistakes is run by people without the emotional maturity required to properly run an organization. The same is true of people unwilling to identify those mistakes and figure out either how they can be avoided in the future, or if they can’t be reliably avoided, mitigate their effects. Some of the leadership’s primary responsibilities involve defining the desired outcome, measuring the difference between it and the actual outcome, determining if/how it matters, and figuring out why it’s different. Those that refuse to address, or even acknowledge problems (and again, it doesn’t have to be punitive,) are masking their own laziness or incompetence.
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.