I'm going to stand next to you and roll my eyes with you before sharing the other thought :D I've recently made a transition from a senior-level IC (think ~Pri

I'm going to stand next to you and roll my eyes with you before sharing the other thought :D I've recently made a transition from a senior-level IC (think ~Principal/Staff level) to leading a small team of primarily fresh grads. While I haven't explicitly mentioned any of the Extreme Ownership stuff to them, I did take a lot of his points to heart when I first listened to the book. I feel like actually using and embodying those principles has worked out really well so far, especially from a lead-by-example perspective. Ideas like: - Managing up and down the chain of command. They've seen it in action where I'm taking their ideas and feedback upwards to try to figure out how to line up senior management's plans with the junior folks' good ideas. They do the same thing with me; if there's something missing in what I'm giving them (either an understanding of intent, or some kind of technical resource, or equipment, or whatever), they quickly and consistently let me know about it. - Owning mistakes. I have fucked up. I publicly admit when I fuck up in meetings with my peers and the broader leadership in the company. If one of my subordinates fucks up, I own that too, along with, if asked, an explanation of how we've modified our processes to mitigate similar mistakes in the future. My subordinates immediately come and tell me when they screw up. It's super refreshing. One of the fresh grads smoked $10,000 worth of electronics by hooking the power supply up wrong. He came and found me while I was on a smoke break to tell me. - Owning cross-team mistakes, sort of. There are other teams in the company that are notorious for shipping half-baked code or hardware designs. These are peer teams so while I can offer up design/implementation ideas, I have no authority myself to require them to listen to me. Where the issues end up manifesting themselves is during the system integration; the APIs between our stuff generally works, but their side of it has a habit of being flaky. To have overall successful outcomes, we try to "own" this by: a) pushing for early integration smoke testing early, b) pushing very hard for all code to be pushed to Bitbucket early (in which we also lead by example), and c) rolling up our sleeves and doing what we need to do to have a successful outcome (whether this is helping them debug/redesign, or doing code reviews, or whatever). Organizationally, I think my peers and layers above me have a pretty solid understanding of what my team contributes to the overall success. - Commander's intent. When upper management asks for something, whether or not it makes sense at first blush, I try to dig into the rationale behind it and how it fits into the bigger picture. On the other side of this, I don't just throw tasks or projects at the team; we sit down, I explain how it fits into the bigger picture, how it's likely to evolve based on my understanding of the situation, etc. And in return, they generally do superb work that doesn't really require much rework. While not implementing all of the "maybe happening in the future" features (thank God, that would take forever), the designs and implementations they come up with have the future plans in mind. I don't think we've ever had to scrap a module and rewrite it from scratch, because they design things with just enough flexibility given the bigger context. - "My Shit Umbrella". There's a lot of behind the scenes chaos that goes on, and I do my damnedest to isolate the members of my team from it so that they can focus on getting their jobs done. If there's a shit storm coming I let them know about it early and we brainstorm ways we can try to prevent it. - Disagree and Commit. I absolutely understand that my ideas/plans will not always be the direction we go, and I'm ok with that. During the planning stages with my peers and upper management, I will quite vocally express myself if something seems like a bad plan for whatever reason, but ultimately it's not my decision. If the CEO decides to go a direction I disagree with, I set aside my ego and do my damnedest to execute on his plan. The same goes with my team. The shit umbrella isn't 100% impermeable, and when push comes to shove, my team will push back on bad ideas, but if I do decide to pull rank and say "just do it", they roll up their sleeves and do it at full effort. This, along with "Commander's Intent" and other ideas, is very much a lead-by-example thing.