After the summit (#afterstack), a few of us compared notes and found a common theme in an underserved, but critical part of the OpenStack community. Sean Roberts, Allison Randal, and Rob Hirschfeld committed to expand our discussion to the broader community. Instead of sharing a single post, we wanted to bring our individual perspectives to you and start a dialog. See Rob’s post http://robhim/2014/07/01/hidden-influencers and Allison’s post http://allisonrandal.com/2014/07/01/hidden-influencers/.
Besides a long, productive week followed with an afterparty that resulted in domain procurements and a few drinks imbibed, we found a gap. There is a gap between the release management and the business outreach. It is something akin to a strategic technical leadership and product management. The coordination of multi-release, cross-project, cross company work is critical for openstack momentum. Building on the discussions from the Atlanta Summit, Rob Hirschfeld and myself dug deep during an OpenStack user group meeting the night of 05 June 2014 and we developed these thoughts on the strategic gap. These thoughts explain different aspects of getting their line management inline with OpenStack.
The “Hidden Influencers” or line management for the OpenStack committers are generally left out of the summit plans that the committers and Project Technical Leads make at each design summit. This means the intent of the committers to work is not inline with the people who are responsible for actually committing the time. This lack of alignment between committers and their line management throws a wrench into getting a timely release with the features and code promised. It important to note, that as the summit energy and collaboration happens the committer enthusiasm is high. Even if the committer line management is out of the loop, the committer will plan on using his/her own time. This is means the committer have the best of intentions to follow through and hit the milestones as promised. Reality is though, as the release cycle wears on it is harder to keep the enthusiasm up. Including the committer line management into the release cycle demands and commitments of the developers, will insure that we get more of the follow through efforts required to land the code by the milestones.
The “Flow” of the projects and their features happens due to the public OpenStack release management cycle. The developers need to get their line management in-sync with the cycle of OpenStack so the flow of effort and code does not get out of phase. The diagram is my way describing my desire to do great work and get all of my ideas to “paper”, but the reality is that between the summits my enthusiasm gets sapped by the day-to-day grind of getting things done. If my line management isn’t there helping me with that daily grind, it makes it all that much harder. Even worse, my line management may start tasking me with differently things that take me even further from success. I want my line management to be supportive and understand that I need help during the middle months in order to meet my milestone commitments.
Understanding the “time to ingest the upstream community” efforts for any company requires the line management to be involved during the very early stages of the release cycle. The line management can then understand that during the public OpenStack release cycle, when they will be able to land the features for their own distributions and releases. As a involved OpenStack committer, I should be steeping my line management as soon as possible in the features and how we can take advantage of them. This is a possible task for all of us post summit. I know I try. But recognize that the summit intents meet the lag of first post month. It may not follow through as expected. The line management will understand the process and the fall out of features that didn’t make the cut if they are involved at the very early stages of the release.
I have made a stab at explaining who has been left out of the OpenStack release management process. I then cut up the problem into a few pieces to explain why I think it is important. I also fed you some ideas on how and when to fix the problem. In summary, I believe that we can improve and balance our enthusiasm and effort by involving our line management in the OpenStack release cycle.