The “O A R”

If everyone understands the terms “ownership" & "accountability” then why is there a gross lack of “responsibility” & application with still a lot of room left for improvement in the world?

Sep 29, 2022

Real-world issues…!

Foreword

As of today, given the exodus of mushrooming start-ups in every nook and corner of the world and especially in the organizations practicing PLG, a product person is often expected to carry a diverse and rich set of experiences over interfacing with all the teams and their respective stakeholders both internal and external right from the time he joins the organization and takes the download from his reporting manager - mostly the leadership, and to be able to dynamically fit in at any stage right from ideation / conceptualization or the execution part which is the product build and growth.

The Issue(s)

Over the recent past I have seen a few questions about how to deal with the lack of ownership from some teams / members while playing the role of a PM. Indeed! Lack of ownership could be really bugging, almost like a cancer that starts off slow but then catches on really quickly spreading all over and impeding other team members as well.

Also related:

How to go about enforcing a sense of ownership and accountability amongst team members in a step towards making them more responsible?

Project Management for Product Managers!

One question that ought to strike anyone over any type of product organization is if engineering keeps building stuff without reaching that all-important milestone of a shippable version of a snippet / feature / part / whole product, then:

what’s the outcome of the whole build cycle?

So, to dodge such nasty situations as a Product Manager, it could become important for you to get down to doing some project management work as well, alongside your regular work that is.

Also, to think about it, it is so easy for you to let this slip off and slide as you would have built a roadmap sharing it across all internal teams and that doesn’t tend to have any dates / deadlines on it.

how do you go about firstly setting and then enforcing those deadlines?
once set, do you have to get down to tracking them all to completion all by yourself?
do tasks / deadlines / follow-ups really fall within the purview of your work?

Pinning on Outcomes!

When one talks of the DEV teams, usually the order of mid-sized to large organizations is to create positions like SEM & PO and fill for it. And, to get your hands on all the status reports your best bet is to collaborate / occasionally interface with these people in the team over a regular cadence, may be weekly.

Most organizations have this and follow it as a practice already. But in case you find that they aren’t already doing that, it ought to be the place for you to start as soon as you join. The very next step after joining & introduction is to hit it off by understanding everyone’s responsibility / directly ask each of them to share a one-page report over something that ought to be their share of work over how they are contributing and how that is adding up to epics on the roadmap.

You could also book a 1:1 session to understand these:

what’s been done thus far?
what they are doing now / what’s ongoing? &
what they’d be doing going ahead?

And then, use that information to measure alignment with the goals and see if everything is in order. Some major steps here could be:

get a download of the goals / OKRs from the leadership
break them down at your end to build granular accountability
crosscheck it against the work the teams are putting in
measure whether it is all aligned towards achieving those goals
make suitable suggestions / changes as required

NOTE: Around any of these steps if you happen to notice any sort of flippancy within teams or if you happen to spot gaps that could perhaps impede teams from inching closer towards those goals, it becomes your duty to influence them and work with them to try and restore order. Everybody is accountable in their own right, but it is the PM who’s got to take the bulk of the ownership and the blame as well if things don’t go according to plan.

Here’s an illustration of what PM work ought to look like in an ideal scenario.

To say in the least, for all the Design / DEV teams may still be inclined towards calling it a deliverable / output as that’s the way they have been programmed to function. But, it ought to be the outcomes that you need to pin on and assert as a PM.

This is a very popular image that’s been floating around the internet for over decades now. It also pictorially represents the necessity to build everything incrementally in silos and keep talking to the users / representative of the user groups emphasizing outcomes over outputs whilst also highlighting the need to collaborate effectively with internal teams.

When you look at execution phase going wrong like this and if you have the time to get into analyzing those whys, you’d find a few gaps and be able to attribute it to:

“information lost in translation”
“lack of collaboration”
“a failed attempt to build a shared understanding”

But, think about this for a while.

In this case, would it be right to say absolutely nobody within the organization had a detailed understanding of the requirements?

Well. Am sure the answer is not a blatant “YES” here.

FYI, I have had some success when I described it this way during internal meetings, so as to help guys who build the product or work on the UX get a proper hang of expectations and align better.

O & A Culture

There seems to be a fallacy that commonly prevails amongst most of the team members and I have seen this across many organizations, which is “the intentional need to find, label and associate jargons to specific roles in the hierarchy”. When some do it intentionally, it is mostly subconscious and the habit has been so deeply embedded in their ecosystem it affects the way they think, behave and function.

For instance:

As soon as someone says “strategy” – Oh! That is for the Leadership / EXECs
If someone says “culture” – That ought to be falling under the purview of leadership and I don’t need to waste any time thinking about that really
In the same vein, if someone says ownership and accountability – Ah! That’s associated with the engineering, development, design teams over their deliverables both individually and collectively as a team

But, the truth be told. That right there could be a big culture issue, and if it isn’t yet, it will become one in due course.

The thing with O & A is, it needn’t be thought of as just applying to a certain set of people in some teams. If anything, it has got to be all-round starting right at the top from the CXO levels all the way to the bottom of the organizational hierarchy.

Here’s a perfect illustration of a great O & A culture at all levels split across the number of team members at each level which increases as one goes top-down.

An interesting problem:

When it comes to upholding this whole concept of O & A, how do you quantify it across each level in the hierarchy?

And, now one may also ask:

Why? What’s the need to quantify it?

Fortunately or unfortunately we have been living under this umbrella of a culture built over rewards and incentivization that’s seems to be so deep rooted in our systems that all the while there seems to be a need to quantify everything in the world, the propensity of which keeps increasing when going from organizations with mid to large-sized teams, blame it on hypergrowth or lack of proper policy drafts.

Also, needless to mention, quantifying could make it damn easy to set expectations making it easier for everyone involved to correlate to & measure performances over individual silos / tasks. O & A could enforce a sense of responsibility too.

But quantifying O & A could be very nuanced as it ought to be relative to the quantum of work each and every individual puts in to shoulder his / her share of the responsibility and that’s typical to their level & fitting into the hierarchy chart.

Quantifying PM’s Work:

PMs are more often than not allotted highly refined goals with regard to a product. To be able to do so efficiently one ought to run over a few steps before they can think of success factors and outcomes.

To quantify success over these tasks, there are KPIs that could be defined, measured & tracked as relevant. They could be classified based on the product phase like so: