[HN Gopher] Broken Ownership
___________________________________________________________________
Broken Ownership
Author : rdoherty
Score : 109 points
Date : 2023-08-22 16:51 UTC (6 hours ago)
(HTM) web link (blog.alexewerlof.com)
(TXT) w3m dump (blog.alexewerlof.com)
| commandlinefan wrote:
| > You cannot be responsible for something you don't control
|
| But they sure can bring it up in your annual performance review.
| vidanay wrote:
| My personal simplified version of this: You can be GIVEN
| authority, but you have to TAKE responsibility.
| gurchik wrote:
| I've been working as a DevOps engineer or an SRE or whatever you
| want to call it for the last few years. I think I've seen most of
| these before.
|
| Probably the most common incarnation I've seen of this is the
| Mandate + Responsibility - Knowledge ("Gambler"). Organizations
| declare one day "You build it, you own it" but they don't
| actually set up their teams for success. Probably what I would
| call this instead is "Finger Pointer" as it inevitably leads to
| infighting. This can look like many different things along a
| spectrum ranging from reasonable feedback ("why didn't anyone
| prevent me from commenting out all the broken tests") to not so
| reasonable ("it worked fine on my machine, so it's not my
| fault"). Around the same time is when organizations layoff all
| the sysadmins. "We're not throwing code over the wall anymore, so
| why would we keep them?" A huge waste of organizational knowledge
| and no one is left who knows how the systems work, and this
| increases infighting since now people are afraid for their own
| jobs.
|
| The second most common I've seen is Responsibility + Knowledge -
| Mandate ("Foot Soldier"). This is pretty similar to the above. An
| engineering team is given the golden tablets from above that they
| now need to do ops, but they aren't given any bandwidth to do so.
| They're somehow expected to have the same velocity as before with
| more work on their plates. Some developers will already have the
| knowledge (or the capability to learn) how to do it, but why
| would they work harder just to prove their leaders right? They
| inevitably leave the company. I wonder sometimes how this is
| pitched in leadership meetings or board meetings. I'm assuming
| there's lots of buzzwords like "modern" and "cloud" which are all
| true but somehow it's a surprise when people start quitting or
| app stability gets worse. I'm thinking of one company I worked at
| which encouraged engineering teams to be pizza sized, but mine
| was 10+ people because there was an understanding that half the
| team would quit in less than 12 months.
| BSEdlMMldESB wrote:
| very nice, this is how I can now quickly say it and clearly think
| it:
|
| I've only ever worked for gamblers!
| physicsguy wrote:
| Add to this no ownership over scope, time or resourcing.
| withinboredom wrote:
| I wish the article went more in-depth with less advertising.
| While this is very interesting, I felt like it was also very
| superficial.
| coderintherye wrote:
| Great write-up! I'd add that most of the shortcomings of each
| archetype can be overcome by good process and communication. I
| think this is what highly technically minded engineers find most
| frustrating in team-based workplaces, that the hardest problems
| are not technical, but rather social and structural. However, the
| answer isn't to throw one's hands up in the air at lack of
| mandate, knowledge, or responsibility, but rather to communicate
| continuously with those who have those elements until you have
| gained them as well. This does require people higher up willing
| to give up control though, as referenced in the mentioned book
| "Turn the Ship Around" the further down you can push control the
| better as it leads to good developers at least having the
| opportunity to gain all the elements needed to be successful.
| omgJustTest wrote:
| While interesting, I would note that the knowledge component of
| proper terminology and venn diagram usage is lacking.
|
| Ex: Mandate-only. Diagram shows overlap in other regions. If it
| where mandate only, excluding the other regions the intersection
| should be zero.
|
| "This is a monkey with a gun scenario where one (usually the
| manager) calls the shots without a good level of understanding
| the system or being held responsible for the consequences: on-
| call, alerting, debugging, rearchitecting, etc."
|
| Clearly implies he means Mandate without intersection in other
| regions.
| rzzzt wrote:
| Well actually * _dons glasses*_ , he didn't say "mandate
| without a hint of knowledge or responsibility"...
| bcantrill wrote:
| This is interesting! Instead of thinking of people as being fixed
| in one of these archetypes, though, I think it's useful to think
| of a team as orbiting True Ownership -- with everyone needing to
| be nudged slightly differently.
|
| I also might suggest alternates for some of the labels.
| Specifically:
|
| - I would label "Knowledge without responsibility or mandate"
| (currently labeled as "Coma") as "Critic": folks who know (or
| think they know) but don't have the mandate and aren't taking the
| responsibility are on the sidelines explaining why those that
| _do_ have the responsibility and /or mandate are Doing It Wrong.
| This archetype can be really annoying on a team -- but their lack
| of responsibility + mandate makes them less harmful than other
| archetypes. In my experience, they need to be driven to take on
| more responsibility before they are given mandate.
|
| - I would label "Responsibility without knowledge and mandate"
| (currently labeled as "Babysitter") as "Worrier". This one _can_
| be helpful, but it can also result in tons of makework for those
| with mandate and knowledge. This is not an uncommon pathology in
| nice people: they know that they don 't have the knowledge, so
| they don't seize the mandate. This one needs to be guided to
| knowledge first, and then mandate.
|
| - I would label "Knowledge and mandate without responsibility"
| (currently labeled as "Teenager") as "Technical Debtor": their
| lack of responsibility (often indicated, BTW, by a lack of long
| stints in their career) coupled with their knowledge and mandate
| makes them REALLY dangerous. Specifically, people that never live
| with the long-term consequences of their decisions can be
| blissfully unaware of the wreckage that they leave behind them.
| These folks can be hard to steer -- and the ones that are
| _really_ bad will resist it to the point that they would rather
| move to their next gig than take true responsibility.
|
| That said, I love the other three labels -- and my career has
| been fortunately blessed with few firearm-bearing monkeys...
| watters wrote:
| Technical Debtor is a particularly nice refinement because it
| points toward the fact that this archetype is often exploiting
| incentives in a broken system rather than occupying an awkward-
| but-appropriate developmental phase.
| hitekker wrote:
| The latter two labels sound fine, but the first label sounds
| like a stereotypical VP punch-down.
|
| I've seen way too many people who actually do know better than
| their bosses, who actually step up to be responsible, and who
| are then told to sit down and shut up. I've seen how, after
| thing go wrong, VP blames their "critics" or "haters" for
| making them look bad. I think those with knowledge who get
| punched down, go work for places that give them the mandate
| first, and then responsibility.
|
| Why work for someone who treats your questions as critiques,
| and their failures in management as your responsibility to fix?
| lifeisstillgood wrote:
| >> Why work for someone who treats your questions as
| critiques, and their failures in management as your
| responsibility to fix?
|
| a great line and insightful - and it builds on the article
| which i also found fantastic
| Aurornis wrote:
| > "Critic": folks who know (or think they know) but don't have
| the mandate and aren't taking the responsibility are on the
| sidelines explaining why those that do have the responsibility
| and/or mandate are Doing It Wrong.
|
| This is an entire class of people who have learned how to
| thrive in companies with broken ownership.
|
| When a team gets to this point it's usually because the reward
| structure is so broken that the only way to lose is to actual
| own something. It becomes more beneficial to put on a show and
| play politics than anything else, because you can't be wrong if
| you never actually do the work.
|
| Healthy organizations recognize the people who aren't actually
| doing any work and either get them to work or get them removed
| from the situation. Bad organizations promote these people
| because their criticism and posturing are two things that help
| the status quo. The more ammunition you have to criticize the
| doers, the more you can elevate yourself over them in the
| broken political hierarchy.
| datadrivenangel wrote:
| This is a helpful framework for articulating the different ways
| in which organizations break.
|
| If team topologies are not designed to minimize these, you're in
| for a world of normality (very bad)
| lifeisstillgood wrote:
| I think having mandate gets you some form of responsibility
| anyway.
|
| I think a better terms woukd be
|
| Authority (mandate) Liability (responsibility) Knowledge (seems
| fine but might go for "ability" if I was feeling cynical and
| alliterative)
|
| I love this. Along with the idea of one dimensional and two
| dimensional code and two orders magnitude I am starting to get a
| grip on this society thing we live in.
| bonoboTP wrote:
| What a twist of language all this "product owner" stuff is. You
| own something if people can't legally take it away from you and
| you reap its fruits. The owner is the one who gets the profits.
| sanderjd wrote:
| Words often have multiple different meanings :)
|
| I have a strong memory of being very confused in a classroom in
| high school once when our teacher was trying to get us to
| understand this meaning of "ownership" over our own education.
|
| I get it now though!
| bruce511 wrote:
| The Owner in this article isn't talking about the copyright
| holder, but rather the person who drives the project forward.
|
| What he's saying is that to be a true owner (to best be able to
| drive the project forward) you need a mandate (the copyright
| owner gives you authority), knowledge (of the product, the
| domain space, the user needs and the business needs), and the
| responsibility (the buck stops here).
|
| The "owner" balances all the needs, allocates resources,
| designs, follows up, takes the heat when things go wrong.
|
| In a business sense this is different to the copyright holder
| (who puts up the resources, takes the risk, and gets the profit
| if there is any)
| bonoboTP wrote:
| The butler is no "Castle Owner".
|
| It is a cheap way to give people a strong and prestigious
| word to describe themselves, thereby smuggling in
| connotations. If you own something, you will treat it with
| lots of attention of course. People who tell you that you own
| something that isn't actually yours want to make you feel you
| own it and hence give it your 110%, while actually not owning
| anything.
|
| There is no ownership here and project lead or project
| manager would be much more appropriate. I know that it's
| jargon, but it's pure connotation smuggling. Titles are very
| cheap, and people are gullible to be satisfied with the pride
| that comes from feeling like they own something.
|
| Remember when people used to talk about "rockstar devs",
| ninjas and gurus. Or Apple customer service people being
| called "geniuses". Or "Scrum Masters". Or various wizards,
| magicians, and so on.
|
| Also I never mentioned copyright at all. Copyright may or may
| not be relevant regarding ownership. For example when
| producing physical widgets without software, copyright is a
| non-starter in the first place.
| rerdavies wrote:
| Venn Diagram people are definitely weirder than List people (the
| 7 Different Types of....). They have to come up with wise-
| sounding descriptions of all possible binary combinations of the
| circles they made up. "Monkey with a gun"??!
| mindvirus wrote:
| This is a great writeup, I think I've found myself in every one
| of those segments.
|
| One piece that feels like it could use more exploration is the
| ability to mandate. Some of it is leading through influence, but
| a place I've struggled is when stakeholders have a different
| mandate than my own.
| nine_zeros wrote:
| Very accurate. My manager is the monkey and I, with much more
| experience than him, have been reduced to a foot soldier. Can't
| wait to see services tank.
| beaviskhan wrote:
| > To know the difference between SRE and DevOps ask them what
| they do when an incident happens: > DevOps rolls back (reverts
| the changes, treating the system as a black box that should go to
| the last known good state) > SRE fixes forward (fixes the problem
| and commits a new change)
|
| Ehhhh. I don't think it's that simple, and you'd better know what
| your strategy is for incident response BEFORE one happens. By far
| the worst shitshows I've seen in production have been as a result
| of well-intentioned people trying to fix forward without fully
| understanding what is going on.
|
| Spoiler: having full understanding of what is going on in the
| heat of the moment is really, really hard, even for smart people
| who are also system experts. Rolling back as a default and then
| figuring out what went wrong in a more orderly manner is a
| perfectly sensible default behavior where such a thing is
| possible.
| sanderjd wrote:
| I would say that the best SREs I've worked with do the
| immediate revert for all these reasons, but also can and
| frequently do implement the fix :) (But I'd say that's also
| true of DevOps people I've worked with, so not sure the
| differentiation makes much sense...)
| gurchik wrote:
| I also took issue to this, but it looks like the author
| responded in a comment. If I understand their intentions
| correctly, it probably would be better phrased as: "if rolling
| forward isn't even considered, it's DevOps, otherwise it's
| SRE." While I can't disagree with the author's experience, in
| my experience the title is meaningless. At my current job some
| coworkers think I'm an SRE, some people think I'm DevOps, and
| some people think I'm in IT.
___________________________________________________________________
(page generated 2023-08-22 23:01 UTC)