Every single bit of work moves through a process. It doesn’t matter if it’s a software development process, an escalation process, a communication process, a manufacturing process, or a governance process. So when I think about what I own, I don’t think about "code." In fact, it was a miracle I passed the only software coding class I took back in high school.

I think about the process. I am there to ensure those software developers and QA engineers and Scrum Masters have the best chance they can to do their job awesomely.

That’s the thing.

Along the way, I figured out that owning the outcome means understanding the process, and I’m really good at seeing the process, and then helping work move through it.

Where does the work start?

Where does it need to go?

Who needs to touch it?

What are we waiting on?

Where is it likely to get stuck?

What needs to happen next?

I don’t ever need to write a line of code to see when the code is sitting somewhere waiting for a decision. I don’t need to QA the software to notice there is a gap in the testing process. My expertise comes in the process, the persistence, the systems thinking, the coaching, the building of mechanisms.

I can tell you where the work is, what needs to happen next, who’s needed, why they’re needed, what’s getting in the way, and whether or not we’re making progress toward the outcome.

And that’s how I own the outcome.

Not by doing everyone else’s jobs. By understanding how all of those jobs connect, seeing where the work is getting stuck, and helping it move.

Own the process; own the outcome.

Has ownership defaulted to you—or are you struggling to get work to the right owner?
Leadership Mechanisms | Ownership helps you clarify who should own what and what needs to be true for ownership to work.

Need help deciding whether you should say yes in the first place?
Leadership Mechanisms | Capacity helps you make more intentional decisions about what belongs on your plate.