Facebook culture makes a similar statement: "Nothing at Facebook is someone else's problem." 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.
This type of thinking stops issues from being buried when they're noticed by someone, even if it's something outside of what they are judged on in their responsibilities (and performance reviews). A good hypothetical example of this is a crash condition you may trigger as an engineer. You might not quite know what is going on but you have a reproducible testcase of a crash condition in someone else's stack, and saying it's not your job means the bug doesn't get fixed or reported. Had you submitted that crash condition and made it temporarily your problem, you could have indirectly helped patch a deserialization bug that could've led to code execution on that tier with a more malicious testcase (i.e. exploit).
In smaller companies, I think everything technical kind of ends up being your job, so your job becomes what you make of it at that moment. Do what needs to be done to ship the thing.
>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
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?
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.
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?
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.
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}.”
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?
>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.
Having worked for a tiny company, where this is pretty much inevitable, I'd say you define what your job is at the moment by what you commit yourself to do.
Spoiler: There are plenty of things that people avoid doing because it's not their job, it's just that this situation must sometimes be finessed a bit.
So, you don't avoid doing something because it's "not your job", you move it to another team who is better positioned to address the issue. Or maybe you deprioritize it because it doesn't fit in with your team's current priorities, etc. Eppur si muove.
