The Accountability Problem
jamesshore.com
The Accountability Problem
1–10 of 62 posts
Re: The Accountability Problem
#2>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!
Re: The Accountability Problem
#3>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!
Re: The Accountability Problem
#4Let'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.
Re: The Accountability Problem
#5thanks so sharing
Re: The Accountability Problem
#6This 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.
Re: The Accountability Problem
#7Let'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 w…
> 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.
Re: The Accountability Problem
#8This 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 li…
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.
Re: The Accountability Problem
#9This guy hasn't actually worked in sales or marketing and it shows.
Re: The Accountability Problem
#10This 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 li…
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.