Hacker News Reader

>I don't take it to mean that you are supposed to be the Atlas of the organization, but rather that when you see problems and issues that might arise, you don't ignore them because it's "not my job" or "not my problem" - you embrace it, escalate or forward it to the correct people, and then go back to what else you have to do.

Trying to really educate around this at my workplace.

I call it "throwing your hands up." If you run into a problem, or notice that something isn't working, what-have-you, if you throw your hands up instead of working to fix it, or find the person who should fix it, you are on my shit list.

It's hard to explain this part of ownership. But it's very obvious when you see someone doing it. Their first response is often to say something like "not my job," and they often think that Extreme Ownership or Question Behind the Question mentality covers it, but after it all shakes out in the wash, it's actually the opposite.

Maybe people need to do a better job of explaining ownership up front, or choose different words. IDK

> on my shit list

What would you tell a junior engineer who feels so overwhelmed with the tasks he is supposed to be focused on that he decides not to switch task to solving this other thing that may-or-may-not be a real problem?

Also, are the phrases “Extreme Ownership” and “Question Behind the Question” from a US Navy SEAL book by Willink and Babin? Would you generally recommend that book?

I can highly recommend the book "Extreme Ownership" and Jocko's podcast. I haven't read his subsequent books but I assume they're also great.

I’ll second the Jocko book recommendation. His podcast is also good. Pick out the QA episodes if you want mostly leadership questions.

Correct on the book for extreme ownership. The other book is "QBQ! The Question Behind the Question: Practicing Personal Accountability in Work and in Life" by John G Miller.

I call it "throwing your hands up." If you run into a problem, or notice that something isn't working, what-have-you, if you throw your hands up instead of working to fix it, or find the person who should fix it, you are on my shit list.

My problem with this is that everything is always not working, or barely working, and nobody wants to hear about it. You're going to say "of course I mean important things", but wherever you look, if you look for problems, you see problems, there aren't a few things which are problems, there are oceans and oceans of problems and potential problems.

The only coherent response to this is blinders - do what everyone else does, and pretend everything is fine - until an incident forces people to face it. Then face the smallest possible case of it, and reassure each other it's fine now. I think you really mean "intuit the same judgement of importance that I have", but either you're so used to not-seeing-problems that you don't see how many there are, or you aren't willing to say that outright because it leaves the person with an escape from you putting the blame on them, and you don't want them to have an escape and you need someone to shitlist for .. I dunno what reasons. Why /do/ you have a shitlist instead of a "training" list?

"Everything broken, or barely patched together" is the norm.

Cynical people reading this, give a couple of minutes thought how many things you've experienced just today, which aren't right or could be a problem. I bet you'll pass a dozen in that time, right?

> and nobody wants to hear about it

Then the rest of the organisation, including leadership hasn't embraced the approach. You can't do it unless the culture really baked in, or else you will break yourself.

>you embrace it, escalate or forward it to the correct people

This here is key.

There are plenty of seemingly-intelligent individuals out there who refuse to acknowledge gaps in their knowledge.

They instead favor suppression and/or deflection over escalation because their own fragile egos could not handle the fact.

Full ownership mentality tends to weed these people out.

I don't know about weeding them out, usually the only people that can afford to have fragile egos have power in the organization.

Note that isn’t the only cause of Suppression. In fact, suppression is the default as it requires mere inaction.

So another way that suppression can happen is, “oh that seems like it could be a problem. But is it? Who would I ask? Would asking about that be a distraction? {switches back to original task}”

Yet another way is, “this error email seems like this is a problem. But I’m new and nobody else is responding to it and there are like 30 of them. I should probably filter them out so as to avoid getting distracted. I wish I knew why we weren’t allocating time to dealing with these alarms. {switches to remain focused on original task}.”

Sure, what you are describing I would consider "passive suppression".

I should have been more specific and mentioned "active suppression" to imply a focus on behaviors inclusive of things like pre-emptive sabotage.

I think what you call “passive suppression” is more important to pay attention to because I assume that sabotage is pretty rare but not-knowing-what-to-do and being-overwhelmed happens occasionally.

> you embrace it, escalate or forward it to the correct people, and then go back to what else you have to do.

How would you maintain this habit in a world where:

1) Time is limited.

2) Context-switching has a high time cost (see “manager time vs maker time”).

3) Communication takes effort. Describing issues conherently takes at least 15 minutes of focused time.

4) “Noticing an issue” is an event which happens at least 4x per hour? This includes seeing an alert come in via your error-reporting infra and determining if it is or is not spurious.

Your attention would be jerked this way and that. If you are in the process of reporting one issue and see another issue, do you report that first or second? How do you find time to defrag your working memory and to focus on your original task for the day?

We live in a tremendously noisy world.

Without a commitment to focus for 2 hours and ignore things other than your current task, How do you accomplish anything?

Very similar sentiment at Amazon.

>Leaders are owners...They never say “that’s not my job".

You own your entire problem space, not just your solution. If something unexpected comes up, you're still ultimately responsible for dealing with it with the goal of solving your actual problem

In a large company it's tempting for people or teams to put up walls around what they think their job description should be. Invariably there are gaps no one wants to own and it turns toxic pretty quickly.

It's still surprisingly common for comments from ex-Amazon people to say how shoddy their infrastructure is, and for real-world outages to happen. From the outside, that doesn't seem like the result of an environment "everyone takes responsibility, and fixes the root cause of every problem" working well, does it?

I feel that in the past (present is TBD) Amazon under-indexed on developer experience, tooling, and infrastructure but I think it was caused by lack of investment, not lack of ownership. There's nuance between "Oh no, <shared_resource> broke, not my problem", and "<shared_resource> broke, I want to fix it but can't because <XYZ reason>". In my experience it's usually closer to the latter here.

How do you actually execute this in a world where time and attention are finite?