from Hacker News

Broken Ownership

by rdoherty on 8/22/23, 4:51 PM with 34 comments

• by bcantrill on 8/22/23, 5:57 PM

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

• by beaviskhan on 8/22/23, 6:25 PM

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

• by brailsafe on 8/22/23, 11:19 PM

  I think the first paragraph and venn diagram described the problem pretty well. This is why I'm a huge advocate for not giving a shit beyond the scope of what you control or are getting paid to do. Devote your day to the thing you're working on, but it's not in your favor to do more than that if you don't control any other aspects of how that hypothetical extra time is rewarded. If you get unlimited overtime pay, great, spend as much time as you want getting it, your reward is more money. If you're not, and don't have a stake in the company, and never hope to, or don't have anything but a guarantee you'll land that promotion, devoting more of your mental energy beyond the time you're paid for is just a recipe to be Jason Bateman. No amount of loyalty will be rewarded with not being laid off, so assume you will eventually, negotiate aggressively, and leave earlier than later if your work isn't rewarded in the way you feel like you can get elsewhere.

• by gurchik on 8/22/23, 8:00 PM

  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.

• by bonoboTP on 8/22/23, 6:22 PM

  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.

• by commandlinefan on 8/22/23, 6:30 PM

  > You cannot be responsible for something you don’t control

  But they sure can bring it up in your annual performance review.

• by datadrivenangel on 8/22/23, 5:40 PM

  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)

• by coderintherye on 8/22/23, 5:55 PM

  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.

• by omgJustTest on 8/22/23, 5:55 PM

  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.

• by lifeisstillgood on 8/22/23, 11:00 PM

  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.

• by withinboredom on 8/22/23, 5:55 PM

  I wish the article went more in-depth with less advertising. While this is very interesting, I felt like it was also very superficial.

• by mindvirus on 8/22/23, 6:02 PM

  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.

• by vidanay on 8/22/23, 6:30 PM

  My personal simplified version of this: You can be GIVEN authority, but you have to TAKE responsibility.

• by rerdavies on 8/22/23, 9:03 PM

  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"??!

• by nine_zeros on 8/22/23, 7:07 PM

  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.

• by physicsguy on 8/22/23, 6:32 PM

  Add to this no ownership over scope, time or resourcing.

• by BSEdlMMldESB on 8/22/23, 6:54 PM

  very nice, this is how I can now quickly say it and clearly think it:

  I've only ever worked for gamblers!