[HN Gopher] The Accountability Problem
___________________________________________________________________
The Accountability Problem
Author : FrancoisBosun
Score : 127 points
Date : 2025-10-19 02:22 UTC (20 hours ago)
(HTM) web link (www.jamesshore.com)
(TXT) w3m dump (www.jamesshore.com)
| gsf_emergency_4 wrote:
| > _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!
| skybrian wrote:
| >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!
| julik wrote:
| ...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.
| zkmon wrote:
| 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.
| phoe-krk wrote:
| _> 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.
| zkmon wrote:
| >> 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?
| firesteelrain wrote:
| 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.
| DrewADesign wrote:
| 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.
| phoe-krk wrote:
| _> 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.
| lencastre wrote:
| thanks so sharing
| aryehof wrote:
| 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.
| Lionga wrote:
| 100% bullshit speak from agile coach who has 0 idea how
| software development actually works, but wants to sell C Level
| the new shiny idea.
| kcexn wrote:
| 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.
| cjfd wrote:
| 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.
| smoody07 wrote:
| This guy hasn't actually worked in sales or marketing and it
| shows.
| fmfamaral wrote:
| I still need those features and a date. Thank you, Sales &
| Marketing.
| skydhash wrote:
| 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.
| csswizardry wrote:
| 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.
| jdlshore wrote:
| Thanks! (Author here.) I wrote the markup by hand, and did
| spend extra time on the "alt" tags. I'm glad someone noticed.
| zduoduo wrote:
| ChatGPT Shuo :
|
| 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.
| akickinthestone wrote:
| 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.
| ronbenton wrote:
| 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
| array_key_first wrote:
| 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.
| dan-robertson wrote:
| 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.
| firesteelrain wrote:
| 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.
| skydhash wrote:
| > _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.
| pessimizer wrote:
| > 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.
| marcosdumay wrote:
| 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.
|
| That shouldn't be an alien concept.
| shevy-java wrote:
| "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.
| thwave wrote:
| they could have seen tusks themselves, and relied on verbal
| descriptions for the rest of the animal.
| gus_massa wrote:
| 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.
| afandian wrote:
| If you're interested, Uli Westphal has made a serious study of
| elephant drawings and the chains of influence.
|
| https://www.uliwestphal.de/elephas-anthropogenus/
| alphazard wrote:
| 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.
| MrDarcy wrote:
| 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.
| amelius wrote:
| But somehow nobody is calling them out for it.
|
| 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".
| alphazard wrote:
| 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.
| alphazard wrote:
| 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.
| pols45 wrote:
| 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 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.
| alphazard wrote:
| 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.
| drooby wrote:
| 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."
| master_crab wrote:
| 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.
| Seattle3503 wrote:
| > 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?
| nerdponx wrote:
| When somebody incompetent is hired to do a job, do you blame
| the incompetent person, or the person who hired the incompetent
| person?
| marcosdumay wrote:
| On this case, probably the person that decided to split the
| job that way or the person that decided that somebody must be
| hired.
| gubicle wrote:
| 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.
| ozim wrote:
| 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.
| Esophagus4 wrote:
| 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.
| jeremyjh wrote:
| 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.
| Esophagus4 wrote:
| 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.
| pessimizer wrote:
| 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.)
| alganet wrote:
| > 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.
| marcosdumay wrote:
| 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.
| dzonga wrote:
| ever wondered why the most successful software orgs never have
| Product Managers ?
|
| there goes your answer.
| Pannoniae wrote:
| 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?
___________________________________________________________________
(page generated 2025-10-19 23:01 UTC)