How did patio11 develop these?
———
EDIT: How do you know that what you are working on is not a distraction?
I could be entirely wrong though.
I wear an insane amount of hats at my company because 1) I'm confident/stupid enough to believe I can handle it [see the part above about hubris] and 2) I actually have a track record of being able to tackle whatever has been thrown at me. My curiosity helps me from getting bored because I'm fine jumping from researching DC EV chargers to file permissions issues to tax law to.... anything.
I wouldn't have considered myself as having "hubris" but I have a kind of semi-wild enthusiasm for being able to do things that people have reacted badly to before for exactly the reason you said. I'm not sure how to signal to companies "my deal is I want to do things; I will more or less literally jump off my seat to assist anyone and no job is beneath me and I will stay up and work 16 hours straight if I screw something up; but I'm not really good at hearing no".
"I have a proven track record of executing relentlessly, rapidly delivering value, and moving between internal roles effortlessly. What challenges are you facing I could contribute to in a meaningful way?"
Be more comfortable hearing "No". Trust takes time to build.
In my experience at large companies, on teams that were technical and heavily collaborated with engineering, but were not overseen by engineering managers. Middle management was entirely focused on optimizing for metrics that were either assigned to them, or would result in career progress; instead of what was best for the company. Regardless of whether the companies claimed to have a "nothing is someone else's problem" culture. As a result, any embodiment of that principle, was either punished or perceived as creating problems by non-technical managers. Even if direct praise was often received from engineers and their managers for those actions. In that workplace dynamic, it inherently carries a lot of risk and easily puts a target on your back.
Besides posts like this that give first-hand accounts from employees. It's quite hard to identify what would be an honest signal of true dedication to that principle. Especially in interviews where you're a very qualified candidate, it's difficult to tell if interviewer is trying to selling you the idea of working there.
Instead, I think the core of it is perpetuating "beginner's mind" - that is, you approach every problem with the enthusiasm of a beginner, not with conviction that something can or cannot be done. It's not necessarily pride or self-confidence as much as it is a belief that the thing can be done by someone, and it's just the knowledge you don't have that keeps you from accomplishing it.
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.
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.
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.
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 should have been more specific and mentioned "active suppression" to imply a focus on behaviors inclusive of things like pre-emptive sabotage.
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
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?
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.
>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.
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?