In reflecting on my difficulties both within Snowdrift and in other organizations, I believe I have found clarity on what is missing (spoiler: project management) and what its domains are.
We’ve toyed with the project management role before, but we either executed poorly, or had the wrong conceptualization. Here is my personal take.
Here’s what we do know, and manage well enough:
Business owners are accountable for keeping the organization’s priorities and principles aligned with “customers” and “markets” (these are rough stand-ins whatever terms actually make sense for us. In short, “the outside world”).
Product owners are accountable for shaping the product vision (i.e., features) to align with the priorities of the business owners.
Technology leads are accountable for reality-checking the visionary idealism of product owners as well as aligning the product implementation with business owners’ priorities and principles.
Here’s what’s missing. Project managers have the following domains:
documenting priorities and principles
capturing product vision (features) into centralized locations and standardized formats
reality-checking changes to priorities, principles, and features: Too fast? Too much?
With a project manager owning these domains, team members are freed from the stress of scattered, changing priorities; frustration from perceived failures of communication; and distrust regarding respect of one’s time and energy.
I’m creating a post now so people can discuss the idea.
I caution against making fine-grained distinctions here. It’s all fuzzy.
The PO/PM split described here seems to be splitting up a single job. Or rather, the PO role is inadequately defined. I don’t know how “shaping” the features is different from “capturing” them in standard locations.
“Business owner” sounds like “leadership”. Just checking that’s what you actually mean there. I.e., it’s the executive role that engages with the outside world and shapes the vision, priorities, and principles.
One thing lacking in the BO/PO/PM description is managing employee health and satisfaction. That’s what PMs I know are directly responsible for, as well as for hiring staff in the first place, and negotiating budgets for all of the above.
I agree with everything you wrote. I think it would make sense perhaps to go through the driver-statement -> proposal process to get an effective definition of the accountabilities we need captured here.
I cannot claim to know exactly what is really missing, but I think more important than defining priorities etc. is to make people execute them, or executing them. I think you either need a) someone who knows how to recruit and motivate people, and knows enough of the technical matters to feel the priorities, or b) some motivated all-rounder who can get anything done if he thinks it’s important enough.
I agree with all that, but this is a slightly different framing. We need a role that has the driver you’re describing. We can figure out the range of who is the person (or multiple people) who can fill the role once we are clear what the role is.
Also, rather than make people execute, the wording I’d rather is facilitate execution. The role isn’t about pushing people to do things but about figuring out what the obstacles are so that it becomes easy for people to do things. That’s in the sense of “nudge” and behavioral economics etc: it’s easier and more effective to remove obstacles, to make the easiest default be the actions we want. That’s better than manipulating the actors themselves into acting a certain way.
All that is just wording emphasis. So: this is a role of project-facilitator maybe? A role that figures out everyone’s blockers and helps remove obstacles (often by organizing the work better, but only insofar as as that organizing is needed to facilitate progress). So, this role has an overall awareness of the people, process, and flow of the project. And they work on a human level with contributors and on an organizational level with the roadmap, issue grooming, juggling priorities etc.
I agree that “make” is probably a too strong word. But I think people’s motivation to do things is most often based on social things like “that other person asked me to do it in a very friendly way”, rather than having no technical/management obstacles. If they want to do a task, they will point out the obstacles and maybe help resolve them.
I agree that it is good if everyone has the information on priorities, what tasks there are, etc., so they can figure out how to contribute most effectively given their own skills and motivation. However, if this becomes a time burden for the project-facilitator, then it would be better not to have it.
For example, AFAIK the linux kernel didn’t use an issue tracking system for a long time, because it would not have provided much value. The only thing needed is someone to direct the incoming bugs to the right people – in our case, to tell the people who have the required skills about the current priorities in relation to their skillset, and motivate them in some social manner (this would be outside my area of competence, so my language might tell ;)).
I think a pull-based system (like a well-groomed issue tracking system) that doesn’t work because noone comes by to do things, is less effective than getting a basic flow of motivating-the-right-people-to-do-the-right-tasks working. If you want a pull-based thing alongside, a monthly “here’s what we’re doing currently, and here’s what you could help with” post would probably be more effective than grooming the issue tracker.
This sounds quite arrogant to me now – so I would like to clarify that this (i.e. motivating social behavior is more effective than issue grooming) is an opinion, not an objection.
However, I still think a regular post that invites contributions by clarifying current status and priorities would be a good idea. Not sure if this is practical/useful in your eyes?
I think they’re two sides of the same coin. Contributions happen when someone’s motivation to contribute becomes higher than the barriers stopping them from contributing. You can lower that threshold, or motivate someone above the threshold; both have the same outcome. (Note: a full time salary is a pretty good motivator).
I think it’s useful. Hits both sides of the coin. Only downside is it’s a short-term boost while issue grooming is more efficient in the long run. But given increased availability now due to covid19, probably useful. I did something similar over in Hello there, I'm Axel! - #4 by smichel17