Own it
The following is an excerpt from an email I sent to DeveloperTown in March 2017.
I've been thinking about ownership recently. A few months ago I listened to an interview of DHH, where he shared his thoughts on ownership. He's written about it in the past - a short article on assigning blame. I'll summarize DHH's thoughts - it's your fault.
This is not a new idea. It's a fairly established leadership principle. Blame always goes up the chain of command. If a team is struggling, it's likely because they haven't been given what they need to succeed. I'm a bit of a Jocko fan-boy these days (the podcast is excellent), and in his words (emphasis is mine):
“On any team, in any organization, all responsibility for success and failure rests with the leader. The leader must own everything in his or her world. There is no one else to blame. The leader must acknowledge mistakes and admit failures, take ownership of them, and develop a plan to win.”
I also like SmallBox CEO Jeb Banner's short article on the topic. Jeb relates it nicely to agency life - and talks about ownership from the customer's point of view. From Jeb:
"Why is it always our (the agency's) fault? Because if the client is unhappy, then we have failed in one, or more, of these three ways: We failed to deliver as promised. [...] -or- We failed to manage expectations. [...] -or- We should have never taken on the work to begin with. [...]"
But it's not always clear how to apply this principle. It's easy to take blame once you get used to it. Taking blame is useful, because once the leader takes blame - everyone else stops blaming each other and they start focusing solving the problem.
If you read the accounts of the most recent Amazon outage, you'll find that it was caused by someone making a typo at a terminal. A typo - brought down thousands of websites, and likely caused millions in damages. (I saw $150M in one estimate.) Amazon's response (paraphrase)? "It's our fault. We knew that issue existed. We even had a project queued up to put protections in place. We just didn't give it the right priority. And there are likely other steps we could have taken."
Over the years, I've heard Julie talk about assigning blame a lot. When teams get bogged down in assigning blame, they aren't fixing the problem. When you're focused on CYA, you aren't focused on helping your team members resolve the resulting issues. If someone on the team steps up and takes blame, it creates space for the team to focus on solutions. But there's an even better way. Have a team culture that doesn't worry about assigning blame in the first place.
If you behave like you own the outcome - you don't care how we go to this point. You're focused on what needs to happen to resolve the issue and get things back on track. Later, you might want to circle back and figure out what we need to change so it doesn't happen again. But even that's not a focus on assigning blame, that's a focus on fixing what's clearly a broken system.
Ownership isn't just about blame. Ownership is also about:
Caring about the outcome. If I own something, my first goal is to finish. To get it done. Deliver the thing that's needed. And not just to deliver the minimum, but to deliver the best version of that thing I can do with the resources (time, money, etc) that I have available to me. And to do it in the timeframe that I agreed to do it in.
Caring about the quality of the result. This is certainly similar to caring about the outcome, and could arguably be included in that statement. But it's worth focusing on as it's own aspect. When I deliver a thing to you, I own all aspects of it's quality. Even if I didn't do all the work, I'm implicitly telling you that all of the work met my quality standards.
Caring about the way in which we reach outcomes. In my push to deliver, I can't burn people out. I can't take short cuts that will undermine the long-term value I'm trying to create. I can't change the process - just this one time - because we're under pressure. When do pilots most need their pre-flight checklist? When they are rushed, tired, and not focused. They most need it when they are most likely to want to skip it.
Communicating progress. If you ask me to own something - and I accept that - then I'm also accepting the responsibly to make sure you know where I'm at in my process of delivering it. It's on me to make my progress visible. If you have to ask me for an update, I've failed.
Stepping up, without being asked. See something out of place? Fix it. See someone struggling? Offer to help. See a problem down the road that no one else sees or is focused on? Come up with a solution and pitch it to the team. If I own it, no one's going to ask me to do something. I need to know to step up and handle it.
Giving people feedback. If I truly own the outcome, the quality, and the process - and I'm working as part of a team - than that means I need to be prepared to give the team around me feedback. If you're not meeting expectations, I owe it to you to tell you realtime. If you're deviating from the process the team agreed to, I owe it to the team to step up and say something. If you're a jerk in a meeting, I owe it to you and the team to pull you aside afterwards and say something. Did you know that own and owe come from the same root word? "...before 900; Middle English owen to possess, be under obligation, have to pay;..." Owners (leaders) have an obligation to provide feedback.
What do you own right now at DT? A project? A process? A story? A feature? A client commitment? Nothing?
For the things you own, are you stepping up, caring, communicating, and providing feedback? If you aren't, who's to blame?