I cannot remember any wildly-successful-critical-initiative that did not specifically call out each contributors’ ownership in the success.
Generally, when we look at ownership, the assignment of delivering a discrete aspect of the “whole,” implies a host of responsibilities, primarily accountability. With ownership comes the responsibility to ensure a thing is understood, that the team members align with that understanding, and that the thing is cared for.
Ownership means when things go well, the owner and their team are acknowledged and celebrated. Ownership means when things do not go well, the owner is responsible for delivering a resolution.
The benefits of ownership cannot be overstated. But here are few to get you thinking:
Deep personal connection to the mission
Accountability for the product/service - success or failure
Increased interest in the end-to-end mission
Individual commitment to higher quality outcomes
Empowerment to make decisions
Passion for the success of the mission at every stage - it's contagious
Some thoughts are best expressed through story. Here is one true story for you.
Perhaps one of the most disheartening efforts I ever worked on was revitalizing a team of bright software engineers who had been stripped of their ownership; every aspect of their mission showed it.
Each person had been systematically cut off at the knees.
Their individual expertise was ignored, the design was ascribed for every component without leveraging their expertise, and the message was “get it done” like a whip over a team of horses. The result was possibly the poorest system design, no pride in the quality of the work, a whole lot of finger pointing, and a ritual of throwing code over the wall to the next team without an understanding if it actually fulfilled the mission.
The whole ownership problem came to light in a release review… we had to roll-back. As the new girl on the block, I gathered about 20 tired engineers, business analysts, and architects into a conference room and started asking questions. Going around the room, digging into the challenges that hit the team, we landed on one particularly disappointing bug. How long would it take to resolve it?
The engineer confidently looked at me and said, “A few hours.”
What happened next was a mix of actual conversation and an internal dialog.
Inside Carrie: If it only takes a few hours to fix, why the heck was this monster missed and not fixed before rollout?
Outside Carrie: Only a few hours? No bugs?
“No bugs? Oh, perhaps a day then.”
Inside Carrie: What? You would release something knowing it might be flawed and delay the rollout even more? Why would you do that?
Outside Carrie: Cool. And does that include unit testing with QA?
“They will need another few hours to work on it, it will take a day and a half.” Lead Bug Engineer looks a little less confident and a little more tired.
Inside Carrie: Wow. This guy has been throwing code over the wall so long, he’s forgotten the value of the entire development lifecycle.
Outside Carrie - I look to the QA Lead: Do you agree?
The QA Lead says, "I don’t know, I’m not sure how it is going to change. But it might take a day."
Inside Carrie: OOOOOOKKKKKKK… these guys don’t talk to each other except to say, my next payload is heading your way.
Outside Carrie: Perhaps after this meeting you can assign someone to work with Lead Bug Engineer and walk through it together. Lead Bug Engineer, how long will it take to complete integration testing and then have the business analysts and user teams test and sign-off?
Lead Bug Engineer looks at me in sheer terror.
My heart melts on the spot. It is clear to me that he has not been accountable for more than his unit of code… not the design, the testing, the build, or the acceptance. Just. The. Code. He has been coached and trained to say “a few hours” so not to disappoint anyone. The man does not own his work.
The micro-scene ends with him glancing at his manager, dropping his head, looking at two other team mates with a shallow breath and then leveling his gaze toward me. He suddenly looks like a new person. He is pushing away all his fear, literally swallowing back tears, and standing as tall as he can muster and tells me the truth.
“It will take four days to get it resolved and ready to release into production. No bugs.” He stares at me as if he will be marched to the firing squad.
Inside Carrie: BRAVO!
Outside Carrie: Thank you. That sounds kinda reasonable. And if we discover anything new, it may add a few more days, I assume. Lead Bug Engineer, I want you to drive this all the way into production and give me updates at 11 AM and 4 PM everyday.
That meeting was literally the beginning of the transformation of their performance. For two years the team was building a monolithic piece of software that had no pride of ownership. And where there is no pride of ownership, there is no accountability. And where there is no accountability, Quality takes a dive. And when Quality takes a dive, so does usability. And finally, two things come to an impasse: Success and Speed.
When Ownership is not part of the DNA of the culture, its absence is identified in many ways; here are a few:
disenfranchisement from the mission
carelessness and low quality outcomes
disinterest in others' work
feeling unappreciated for one's potential
I encourage everyone who is a member of a team and organization to take a deep look at not only roles and responsibilities, but ownership.
What does each team member own?
What does ownership mean?
Is everyone clear on the responsibilities tied to ownership?
Ownership is a sword arming your team with a valuable tool to clear the path to deliver successful outcomes. But a sword has two edges, so keep an eye out for the shadow side of ownership: possessiveness and power-grabs. It is a slippery slope for folks who get a little heady with ownership.
Which brings us to next week’s topic: Collaboration.