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.
Pingback: Hidden Influencers | sarob
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.
Thanks and I agree with you. I think we need the data and it will lead us to better insights. I’m worried about fixing the wrong problems.
Pingback: OpenStack Product Management: Wisdom Or Folly? | Accelerated Insight
Pingback: OpenStack Community Weekly Newsletter (June 27 – July 4) » The OpenStack Blog
Pingback: A forum for OpenStack-related Product Managers][ stefano maffulli | ][ stefano maffulli
Rob, how do you propose we find Rob, how do you propose we find these influencers?these influencers?
I do have a proposal. I’d like community member’s profile to include their manager and prod manager. That would let us make a graph
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.
My thought is not that managers are puppet masters calling all the shots, it’s more that they are a nexus of control in a contribution graph that we don’t see.
We miss these people when we look at commit history and project work. They have more impact than we realize. I want that exposed.
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.
I agree on the value of multiple perspectives on value. It’s hard for anyone creating the work to be objective – the creative process tends to drive myopia.
Pingback: Share the love & vote for OpenStack Paris Summit Sessions (closes Wed 8/6) | Rob Hirschfeld
Pingback: 7 Open Source lessons from your English Composition class | Rob Hirschfeld
Pingback: To improve flow, we must view OpenStack community as a Software Factory | Rob Hirschfeld
Pingback: Next steps for ‘Hidden Influencers’][ stefano maffulli | ][ stefano maffulli
Pingback: Next steps for ‘Hidden Influencers’ - GREENSTACK
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.
Roshan – that’s the comment. You are not alone in that opinion and think that you’ve got a pragmatic view. Where do you think we should be altering the governance processes?
Pingback: OpenStack Goldilocks’ Syndrome: three questions to help us find our bearings | Rob Hirschfeld
Pingback: To thrive, OpenStack must better balance dev, ops and business needs. | Rob Hirschfeld
Pingback: All About That Loop. Lessons from the OpenStack Product Mid-Cycle | Rob Hirschfeld
Pingback: Working to bridge the developer/end-user divide in OpenStack - OpenStack Superuser