Post navigation

After the summit (#afterstack), a few of us compared notes and found a common theme in an under served but critical part of the OpenStack community. Sean Roberts (HIS POST), Allison Randal (her post), and I committed to expand our discussion to the broader community.

Lack of Product Management¹ was a common theme at the Atlanta OpenStack summit. That effectively adds fuel to the smoldering “lacking a benevolent dictator” commentary that lingers like smog at summits. While I’ve come think this criticism has merit, I think that it’s a dramatic oversimplification of the leadership dynamic. We have plenty of leaders in OpenStack but we don’t do enough to coordinate them because they are hidden.

One reason to reject “missing product management” as a description is that there are LOTS of PMs in OpenStack. It’s simply that they all work for competing companies. While we spend a lot of time coordinating developers from competing companies, we have minimal integration between their direct engineering managers or product managers.

We spend a lot of time getting engineering talking together, but we do not formally engage discussion between their product or line managers. In fact, they likely encourage them to send their engineers instead of attending summits themselves; consequently, we may not even know those influencers!

When the managers are omitted then the commitments made by engineers to projects are empty promises.

At best, this results in a discrepancy between expected and actual velocity. At worst, work may be waiting on deliveries that have been silently deprioritized by managers who do not directly participate or simply felt excluded the technical discussion.

We need to recognize that OpenStack work is largely corporate sponsored. These managers directly control the engineers’ priorities so they have a huge influence on what features really get delivered.

To make matters worse (yes, they get worse), these influencers are often invisible. Our tracking systems focus on code committers and completely miss the managers who direct those contributors. Even if they had the needed leverage to set priorities, OpenStack technical and governance leaders may not know who contact to resolve conflicts.

We’ve each been working with these “hidden influencers” at our own companies and they aren’t a shadowy spy-v-spy lot, they’re just human beings. They are every bit as enthusiastic about OpenStack as the developers, users and operators! They are frequently the loudest voices saying “Could you please get us just one or two more headcount for the team, we want X and Y to be able to spend full-time on upstream contribution, but we’re stretched too thin to spare them at the moment”.

So it’s not intent but an omission in the OpenStack project to engage managers as a class of contributors. We have clear avenues for developers to participate, but pretty much entirely ignore the managers. We say that with a note of caution, because we don’t want to bring the managers in to “manage OpenStack”.

We should provide avenues for collaboration so that as they’re managing their team of devs at their company, they are also communicating with the managers of similar teams at other companies.

This is potentially beneficial for developers, managers and their companies: they can gain access to resources across company lines. Instead of being solely responsible for some initiative to work on a feature for OpenStack, they can share initiatives across teams at multiple companies. This does happen now, but the coordination for it is quite limited.

We don’t think OpenStack needs more management; instead, I think we need to connect the hidden influencers. Transparency and dialog will resolve these concerns more directly than adding additional process or controls.

¹ as opposed to Release Management. Product Management determines what’s going into future releases while Release Management herds the cats for current and immediately pending releases.

About Rob H

A Baltimore transplant to Austin, Rob thinks about ways of building scale infrastructure for the clouds using Agile processes. He sat on the OpenStack Foundation board for four years. He co-founded RackN enable software that creates hyperscale converged infrastructure.

Rob – Agreed. In my opinion OpenStack doesn’t need (and it shouldn’t contain) the Product Management function that makes feature IN/OUT decisions. Connecting the influencers, as you suggest, makes lots of sense. I think, however, there are other Product Management functions that may be of benefit to the OpenStack ecosystem. I’m thinking of user persona and user story definition – so developers have a very clear vision of who is using the code and how. I know there is persona work going on now. I’d like to see that not only continue but possibly expand to provide more reference/context for the projects.

You mean managers they report to? Would love to chat more; this is a good start, but i’m afraid might indicate “Managers = Influencers” & worse “influencer only if manager”. May be I am missing something.

Rob: I’m a PM and tend to agree with you. I sometimes see what looks to be engineering work for the sake of writing cool code. Am not saying that the cool code is not useful, just that I’m not sure what specific customer need is being fulfilled.

Rob, I am extremely pleased to see this initiative to bring product management more into the conversation in OpenStack. I think it is broken that OpenStack measures contributions purlely based on code contribution. I like to Cloud Foundry governance model much better (for this specific aspect) where product management is a recognized role in the community governance, and owns the definition on WHAT gets done, and the engineers owning HOW stuff gets implemented. It is the lack of similar role definition in OpenStack that causes it to not have a clear user/customer focus.