Broken Ownership | Hacker News Reader

Broken Ownership

blog.alexewerlof.com

163 pointsrdoherty34 comments

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

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.

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

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?

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

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

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.

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

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.

Can you clue me in on the Jason Bateman reference?

In Arrested Development his character solves everyone’s problems to the detriment of his personal life.

@sogen put it pretty well below, but I'm not so familiar with arrested development. His typecast character in most roles though is one who's always draining his personal life in hopes that one day he'll become partner of the lawfirm or be chosen by the woman who only thinks of him as a friend, but usually ends up being passed over for someone else, and divorced in the process. Though it's not perfectly analogous, and at-best a fanciful exaggeration, to me it exemplifies this hopeful idea of "if I try super hard at whatever I'm assigned—more than I'm asked—I'll eventually be rewarded", but it's not a calculated risk if you don't control the outcome of that stress and you're robbing yourself of your own time and energy, the company just accepts it. It might pay off, and it might be due to the merits of the work you've done, but the value you're adding should be very clear, and it should definitely end up in your pocket. There's no worse feeling that putting in those extra hours, stressing yourself off, and then arbitrarily being laid off when times are a bit tougher. Even if you're in a management position, or maybe especially so, you should be paid sufficiently for devoting time outside your regular hours to deal with the bullshit of that job, ideally in clearly defined terms.

Thanks. I figure I’ll get around to watching it next year. Although your description sounds a lot like his role in Ozark too.

That sounds about right. IIRC I saw a few episodes of Ozark and immediately thought it was appropriate.

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.

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.

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)

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.

"Owner" is not a title (I've ever seen). And the article is not about owner dispensed as z title.

Ownership is the -result- of the 3 attributes. Mandate is bestowed by management. Ownership is a state.

This article is neither about legal Ownership (which you referred to in your first post, and i simplified to copyright holder.) It's not about a job title. It's about a state of mind when mandate, knowledge and responsibility collide.

I'm guessing you've never been an owner in this sense, not yet. But look forward to it; it offers a unique satisfaction for a developer, especially when done well.

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!

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

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

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)

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.

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.

Well actually *dons glasses*, he didn't say "mandate without a hint of knowledge or responsibility"...

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.

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

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.

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

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

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.

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

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

I've only ever worked for gamblers!

which is to say only gamblers are ever willing to hire me

Reply on news.ycombinator.com