4 ms·

If you're managing teams, a tech-lead, a manager, startup founder, or just someone who wants to learn more about owning problems, I can recommend reading or lis

• dvtrn 5y ago
  Anecdote wrapped in a non-sequitur: It’s kinda funny to me, I had a job once full of leaders and managers who were constantly invoking Jocko, Simon Sinek and other leadership and management tomes and were just as frequently beating their chests for having read the right books on how to lead… …meanwhile the rank and file at the company were openly (at least in multiple conversations in external chat and text message groups away from the eyes of said managers and leaders) sick of it because the same managers and leaders seemed to predictably and consistently do the exact opposite of whatever they’d gloat about reading from the Jockos and Simons during All Hands Zooms to the peril and resignation of much of the workforce this summer. I curiously glanced at Glassdoor and chuckled seeing a few reviews bringing this up.
  • draw_down 5y ago
    I’ve noticed this same dynamic with regard to Rich Hickey’s “Simple made easy”. At the end of the talk he mentions concrete suggestions and examples of simplicity vs complexity. I noticed people who would always bring up this talk would also continue to do the things he mentions as examples of complexity. Talking the talk and walking the walk will always be two separate things.
  • anchochilis 5y ago
    I've never had a manager who "owned" anything, let alone to an "extreme" degree. It's ICs who are responsible for shipping quality work on time, sometimes at the expense of their health and personal lives. And it's ICs who take the heat when projects go off-track.
    • larrymyers 5y ago
      That sucks if that’s your reality. It means you’ve never had a manager that protects their team and sets them up for success. If my teams are struggling it’s my fault in the eyes of external stakeholders and I own that. If my direct reports cause an issue I expect them to fix it, but that isn’t used as a reason for the failure outside the team.
    • dvtrn 5y ago
      I've had a couple who came very close, circumstance and the usual bureaucracy precluded their ownership reaching the top of the 'extreme' spectrum. Give them credit for even doing as much as they did, to be honest.
  • tonyarkles 5y ago
    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.
• bob1029 5y ago
  I was told to read this by one of my investors. I think the central theme of "the buck stops with whomever" is very important to take to heart, but some of the delivery is a bit over the top. What would be more useful to me is a book that explains in painstaking detail how to inception these concepts into others on a reliable basis.
• wsostt 5y ago
  Thanks for the recommendation. Just purchased the audiobook.