If you like this post or vaguely agree (or horribly disagree) with its ideas, feel free to share it. Share buttons are down at the bottom.
There are admittedly a couple of different things about the working world that sometimes make me want to connect a car battery to my testicles, and one of the more nuanced ones is when people consistently talk about how they own a process. Why would I call this nuanced? Well, on face, it’s important that someone owns a given process in a professional context. Hierarchy helps people clearly organize their thoughts and ideas around who needs to do what, and as a result, it’s probably not going away anytime soon.
You do need someone who owns a process, because someone’s ass needs to be on the line if things flop (Reason 1) and because everyone else on the team(s) needs to know where the decision-making power lies (Reason 2). At Wal-Mart, they call the latter “owning the D,” which is something that could get you arrested if you said it to a female.
Here’s the problem, though: most people aren’t really that intelligent, honestly, and especially not in a work context. And most people have a generally-OK understanding of their deliverables and what their team does, but oftentimes people are completely clueless about what other teams do and how those other teams could benefit their team. Phrased another way: silos.
So here’s what happens often when someone is told by someone else that they now “own” a process: they run around chasing deliverables, as we all do, and they predominantly involve their team — the people they see (face-time) and generally understand the roles of.
Here’s what that leads to: almost no work project exists completely in the vacuum of one department. So people work-work-work within the group they understand, but at some point another group — HR? Marketing? Operations? Product? — needs to become involved. They have no idea what’s going on. For “The Owner” of the process, this is Priority A. For the team getting looped in, it might be Priority J.
A natural conflict emerges, and when the latter team asks why they’re just hearing about this thing, “The Owner” invariably says “Well, I own the process, so I was working with my team…” or some shit like that. Then The Owner’s team desperately needs something from Team Priority J, and Team Priority J doesn’t understand why this thing is a priority, and they basically half-ass it, and The Owner’s team takes it and runs with it because “… we gotta get it out the door…” and then the cycle can truly begin anew.
I cannot tell you how many work teams I have been on where this exact thing happens, from HISD to ESPN to PBS to McKesson and back again. The process owner lets the fact that he/she has “ownership” of something go to his/her head, forgets to loop in the right people, causes confusion, causes a bit of anger/tension, and ultimately gets a sub-par final deliverable.
So you know what? It’s cool that you own something. I realize we’re all looking for purpose at work.
But if you want to really make a difference in terms of owning something, maybe consider starting projects this way.
Quite a few years ago now I started employing a SaaS called Teamwork Project – now called TWProfect (http://twproject.com ). The vendor[ OpenLab, referes to the system as a ‘work management’ platform,’ as it coordinate, accomodates the activities and communicates between all members of an organization whether they are conducting their interactions as part of a project, a secquential workflow, a work process, as an agile process or within the kanban workflow context and hybrids of these. Though TWProject enables activites of all these types, the primary constructs are projects. The reason I mention this, is that over the time I worked with him, the developer proved to me, that there is nothing such as a pure business process – quite a shock to me as I was and still am a business process engineer! I came to learn that all processes are likely part of a project and all projects can be thought of within the continuity of a developmental process at some level. If one simply views the work from a diferent viewpoint/higher or lower vantage point one sees the work as in a project context, or see the work within a work process. . So, I submit, that when the work being done by any memeber of the team has crossed one of these viewpoint thresholds, someone may in fact be taking responsibility for it – and in fact, there is a point where someone has to! That’s been my experience and that’s the advise I give to knowledge workers who will listen to me…
This is an interesting response, and I agree with you. There’s really no such thing as “business process.” Rather, I feel like all businesses processes kind of fit together in some way, and we should be aware that those lines will be crossed.