5 ms·

I don't think that's the point of the statement. Facebook culture makes a similar statement: "Nothing at Facebook is someone else's problem." I don't take it t

I don't think that's the point of the statement. 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.

plausibilities 8y ago
>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.
- itronitron 8y ago
  I don't know about weeding them out, usually the only people that can afford to have fragile egos have power in the organization.
- afarrell 8y ago
  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}.”
  - plausibilities 8y ago
    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.
    - afarrell 8y ago
      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.
jklinger410 8y ago
>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
- afarrell 8y ago
  > 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?
  - pchristensen 8y ago
    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.
  - matwood 8y ago
    I’ll second the Jocko book recommendation. His podcast is also good. Pick out the QA episodes if you want mostly leadership questions.
  - jklinger410 8y ago
    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.
kevan 8y ago
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.
- jodrellblank 8y ago
  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?
  - kevan 8y ago
    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.
afarrell 8y ago
> 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?
afarrell 8y ago
How do you actually execute this in a world where time and attention are finite?

plausibilities 8y ago

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

itronitron 8y ago
I don't know about weeding them out, usually the only people that can afford to have fragile egos have power in the organization.
afarrell 8y ago
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}.”
- plausibilities 8y ago
  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.
  - afarrell 8y ago
    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.

jklinger410 8y ago

>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

afarrell 8y ago
> 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?
- pchristensen 8y ago
  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.
- matwood 8y ago
  I’ll second the Jocko book recommendation. His podcast is also good. Pick out the QA episodes if you want mostly leadership questions.
- jklinger410 8y ago
  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.

kevan 8y ago

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.

jodrellblank 8y ago
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?
- kevan 8y ago
  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.

afarrell 8y ago

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

afarrell 8y ago

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