Linux is the largest and most pervasive open source software (OSS) project in history, and it’s but one of 70+ important projects hosted by the Linux Foundation. This nonprofit really understands the business side of open source, and how that can create market traction around a project — be it Kubernetes or OpenAPIs. Despite being a dominance force, the Linux Foundation sells memberships, so it still faces a familiar challenge: churn.
Program Managers are the heart and soul of the Linux Foundation. They liaise between a project, its members, and its community. The high level of service they provide to their projects — a quality which has been instrumental to the Foundation’s growth and member retention — cannot scale.
The Linux Foundation needed a solution that would automate admin processes wherever possible, freeing up talented Program Managers and other staffers to spend less time on low-level tasks and provide greater value to projects.
My challenge was to envision what the Linux Foundation’s services would look like as self-service products, prioritize them, release, support, and iterate. Alongside this standard product work, I was working with an organization that had never built its own products before, so there was going to be a lot of leadership required to introduce the organization to a new department and its initiatives.
I interviewed users, documented business processes, gathered requirements, hired and managed UX/UI designers, and managed a remote engineering team transitioning from Drupal development to greenfield product engineering.
In addition to various Agile scrummaster-ish duties, I ran end-of-sprint demos for stakeholder feedback, and owned the recording and distribution of the team’s agendas and demo videos. Since this was to eventually be a large suite of staff-, project-, and member-facing tools, I was also responsible for collaborating with the Linux Foundation’s IT and infrastructure teams to ensure application security and performance.
The Linux Foundation is in the process of building this product.
This product had major dependencies on elements of the organization that were undergoing major changes, particularly on the CRM side — I learned what a challenge it is to build and paint the plane while it’s flying ?. When I realized I was too at the mercy of behind-schedule projects, I narrowed our options to two paths.
Path 1: Carve the platform up into individual components (with the understanding that they’d need to be refactored, perhaps significantly, for integration later).
Pros: we’d be able to practice delivery (test our pipelines, build process, etc). Potential to build trust with execs unused to building their own products.
Cons: users wouldn’t really need or use what we’d be shipping. Potential to lose staff trust that we are building useful stuff, hindering future attempts to get high adoption.
Path 2: Continue moving the entire suite of components forward as an integrated set. Assume CICD and be ready to deliver the moment dependencies go live.
Pros: Staying tightly integrated with in-development process or tooling changes enables product and engineering to get our requirements baked into others’ projects. Version 1.0 would provide business value in the form of efficiency gains.
Cons: Not a lot of agency. Potential to lose exec goodwill — depends how they want to measure work output.
Because we weren’t staffed to fully support this product, I didn’t want to double my staff training and onboarding burden just to ship for the sake of shipping.
If I had to do it over again, I’d spend more time selling the benefits of the selected delivery cadence throughout the organization. I’d also make changes to how I presented my roadmap — I defaulted to PowerPoint since it was an executive favorite, but I suspect I could have gotten even the most hardcore PowerPoint fan clicking around something like Aha or ProductPlan.