Managing Career Development within OSPOs

People can also download the guide infographic as PDF here

Open Source Program Offices (OSPO) provide distinct value for businesses. But it is the distinctive nature of the work that makes OSPO professionals appear highly specialized or their job role difficult to categorize into traditional role definitions. Further, the industry has a lack of consensus on job titles and job descriptions between OSPO professionals, community managers and developer relations professionals, with similar roles being more or less highly prized depending upon which business is doing the hiring. Combined, these issues can make recruiting junior professionals into OSPOs more challenging, and defining an upward career path for senior talent more of an art than a science.

The purpose of this guide is to help OSPO leaders build a sustainable and rewarding career path for their employees, including helping them gather depth of skills in particular areas so they’re well prepared to develop their careers in more than one area of the business.

career-development-infographic

Table of Contents

Guide Description

Several issues that affect OSPO performance, visibility and skill transferability necessary to career advancement are covered in this guide.

For example, this guide includes an exploration of where in an organization an OSPO belongs. Should it live in marketing, engineering or the CTO office? Also, what kind of skillsets are needed for the OSPO to function, and how do they translate to more traditional roles?

Further, how can OSPOs build staff skills within the office? Can you augment OSPO skill sets by shifting people into OSPO from their former roles, whether it’s product management or product marketing, or something else?

In any case, it’s time to have a plan to cement OSPO job roles as vital elements in any organization, and as vital skills that are fully transferable to other roles throughout the organization. This guide seeks to lend assistance in that endeavor.

Most importantly, in order to recruit and retain talent in crucial roles, OSPO leaders must proactively help staff members plan their career advancement strategy. This guide will help OSPO leaders to:

This guide aims to assist OSPO leadership in advancing their careers and leveraging the skills they have gained across these traditional roles as they seek new career challenges.

Defining the scope of work for OSPO roles

“When I think about career development for my team, and this is true about anyone who’s building an open source office within a company in general, I’m thinking about how can we be very intentional about either expanding or contracting the scope of our office in order to facilitate some of the other work that needs to be done,” said Will Norris, Open Source Lead at Twitter. Formerly Open Source Engineering Manager at Google

Alongside the OSPO scope expanding, contracting or changing over time comes the added challenge in defining the scope of work in specific open source tasks when so much of it occurs outside of traditional job descriptions and even outside the organization itself. Examples include an engineer who is contributing code to an external project, or someone who’s doing community management, or someone who’s doing other kinds of things that are more externally focused.

“When you have someone who’s doing a lot of their work externally, we’ve found that it’s a real challenge to help provide visibility for those artifacts to help those individuals get the appropriate credit for it to help grow their careers,” said Norris.

One of the ways Google addresses that is with an open source council the company started in 2019. The council is composed of representatives who are working in different open source roles throughout the company so they can collaborate on solving common challenges.

“We have a new working group right now that is focused on exactly how we can help provide visibility into the work of individuals who are doing more external facing work than internal. Some of that is actually changing the job ladders at Google, getting language in there to really give credit to community contributions and to open source,” Norris explained.

Developing a useful open source career ladder is not as simple and straightforward as listing job duties and responsibilities. And yet OSPO managers have to start somewhere.

“Part of the process we did was to identify a job class that already existed in Red Hat in technical program management. That’s because human resources couldn’t create a new job classification out of whole cloth. They have to use industry benchmarks such as those prescribed by IEEE or other industry guides,” said Deborah Bryant, senior director of the Open Source Program Office at Red Hat.

However, the path forward is further muddied by the job titles a typical OSPO uses too.

“No one really likes to use the term community manager, because we all know you can’t actually manage a community. A community has a life of its own. It has a mind of its own and a will of its own,” said Bryant.

“You’re really there to support. You’re not there to manage. So it’s always been debatable about how you name it. But we landed on community architect,” Bryant added.

While clarifying job titles is an essential starting point, pinning those jobs to existing job descriptions often remains an exercise in confusion. Yet, adding new job classes for OSPO specifically is quite commonly a near insurmountable hill to climb in many organizations. But that doesn’t mean the task is impossible.

Bryant was instrumental in developing Red Hat’s career ladder for OSPO from the outset. It didn’t exist when she joined the company in 2014, but the internal demand for it was already high. She says they used the engineering career ladder as their initial framework, but it wasn’t an exact fit.

“The most significant difference was that community managers don’t actually produce code. Sometimes they do it incidental to the work, sometimes they do it as a hobby, but their core responsibility is not producing code,” Bryant said.

“And because that’s such a critical part of an engineer’s career path, it made it difficult for a community manager then to move up through a promotional process where a part of the decision process and the requirements to be able to move in a career would have been based on, in part, not all, a code contribution,” she added.

Refitting existing career ladders for open source

Bryant said she and her team set out to create a career ladder that reflected those elements. They refitted the engineering career ladder to reflect similar skills for community managers.

“Basically, there’s a competency matrix that shows where someone’s skill level should be in leadership, in collaboration, in community contribution, in technical acumen. And then, along that matrix, it will describe what the person’s skill level should be at. So we took that very complex competency matrix and modified it to reflect what we thought some of the skills would be for community managers or what we call community architects,” Bryant said.

It took considerable and widespread collaboration to shape the career ladder from the beginning and finalize it as a fair and useful hiring and promotion tool in the end.

“It went through peer review and a pretty deliberate process to make sure that not only did it create a career path and an ability to celebrate someone’s accomplishments in community architecture, but it also corresponded with an opportunity to increase their compensation in that model within the company,” Bryant said.

Once the career ladder was completed for the OSPO team and people were promoted accordingly, other departments with open source talent showed interest in it too.

“That’s been really gratifying to see that get adopted by other teams in other areas of the company,” Bryant said.

True to open source roots and Red Hat’s culture, the company’s career guide is a work in progress, influenced by many voices working together towards an ever-changing definition of a useful tool. But whether you are just starting to develop an OSPO career guide or are working on one of many iterations, Bryant advises starting with the same focal point.

“Start with a good understanding of what you really need from your open source program team. It may not be the same for every company. Some companies work mostly on a regulatory side in terms of license compliance and some other work. My team doesn’t work on that. For me, there’s a certain core set of skills that are important to me, as there are in other offices,” Bryant says.

Integrating the unique with the standard

Organizational variances are common even though patterns in how most companies think about and manage open source are similar. For example, all companies must decide how to handle compliance with open source software distribution, code contributions and code releases. There are also security, talent recruitment, developer relations, and other functions that companies must assign to a team to ensure all goes well.

“There’s all these different things that every company deals with. But the subset of those things that happen to fall within the open source office is what’s different at every company,” said Norris. Google’s OSPO is an example of a team focused on engineering and compliance. A separate team handles the program side at Google.

Norris said that while some companies prefer the compliance and legal side of open source to be generally handled by the legal team, Google has a legal team within its open source office.

Another example: some companies choose to make their developer relations (AKA DevRel) group part of their open source office, others do the opposite. Still others, like Google, keep the two groups separate.

“At Google, we’re very closely related. And then we have a long history of those two groups working very closely together, but we’re actually not part of the same group,” Norris explained.

The relationship between standards and open source software also tends to be very close, but companies may decide to consolidate standards within their open source office, or distribute it among several teams.

“At Google, that’s actually distributed and mostly for a historical reason, since that is the way that standards have worked at Google,” Norris said.

The diversity in how companies organize open source duties and responsibilities between individuals and teams drives the development of their OSPO career ladders.

“Within our open source programs office we don’t have specific job ladders or even lenses on our job ladders that are unique to open source. Pretty much everyone in our open source office is either a traditional software engineer, or a program manager. So we use Google’s standard software engineering and program management ladders. And one of the reasons we do that is because at Google, as a company, has always valued mobility within the company,” Norris added.

Ultimately, organizing the OSPO and integrating it with related functions requires an unwavering focus on the company’s mission and goals.

For example, Google OSPO’s core mission is to bring all of the value of open source to Google, and all of the resources of Google to open source.

“That mission doesn’t change. In recruiting, I’m really looking for someone who cares about the problems of open source, and the kinds of things that we’re doing. We love adding fresh perspectives too. The tools that we use will change, the languages that we program in will change. Plus Google has a lot of homegrown systems in our engineering stack, so most new employees are going to have to learn a lot of that stuff anyway. That makes it totally okay to have some folks in our open source office who are new to open source too,” said Norris.

Whether OSPO staff and recruits are deeply experienced or brand new to open source, mapping skill categories to resemble the standard, traditional roles but that also integrate the unique skills and duties associated with open source are essential to talent recruitment, retention, and career advancement within the office specifically and in the organization and industry at large.

Mapping Skill Categories

Senior leaders need to help their reports recognize how their skills and daily work map to the work done by others in the organization, and how their work complements those functions while adding distinct value to the business.

“We classify all of our OSPO staff as technical program managers because that’s a well-understood skill set in technical organizations and because our OSPO lives in engineering. And so there are CDs of steps within that, from PM-1 all the way to PM-6, which is like a senior director,” said Nithya Ruff, Executive Director, OSPO at Comcast.

Indeed, Ruff advocates for OSPOs to report to the CTO or the SVP of engineering, rather than to marketing or legal.

“OSPOs should have a very high reporting structure because it’s a pretty big cultural change and you cannot do that without having support from the top. It must be a strategic and important initiative for the company. Having that kind of air cover is important,” said Ruff.

In any case, the first step is breaking down the skills an OSPO staff member uses in their daily functions and fitting those into well understood skill buckets in other company departments or divisions.

“From there, employees can work with their managers to grow their skills in domains that support OSPOs service work within the company while deepening their own expertise in a particular area,” said Leslie Hawthorn, Senior Principal Technical Program Manager, Open Source Program Office, Office of the CTO at Red Hat.

Example: Mapping the Skills of a Community Manager

Job titles at Comcast are closely equated to more traditional roles in engineering to assist in identifying skill sets in easily recognizable terms. The succession steps are also similar. For example OSPO staff are classified as technical program managers and progress on a scale starting at entry level PM-1 and ending at PM-6, the equivalent of a senior director.

“We can pass people through that route but unless there are big divisions in a company where you can say, okay, you can go be the OSPO leader in division A, then it’s very hard to find a role for yourself beyond just being at that top end of your community manager role or top end of your compliance manager role,” said Ruff.

Internally, the job title is always program manager at Comcast and closely tied to engineering roles, but externally the titles are aligned with other OSPOs, according to Ruff. The external titles are commonly community managers, compliance managers, or devrel, which is short for developer relations.

“It is important to parse the newer title of dev rel out and determine what it means to OSPOs and in terms of traditional role counterparts. Is it the same or different as a community manager? Can the OSPO charter be broadened to include developer relations or to help developers be more effective on different fronts, not just on open source? What about DevOps and agile and other things of that nature? Can the OSPO expand its capacity to fit all that and to encourage the growth of those skillsets too?” asked Ruff.

For the moment, many companies employ community managers to focus on program management for their open source activities. The tasks for each community manager vary from organization to organization, but the work falls into well understood skill buckets.

  1. Product Management, Marketing and Sales: Product management requires knowledge, use and management of metrics, user feedback and feature requests, and bridge building between power users and developers for product improvement and innovation. Product marketing requires raising overall awareness of the project, developing and implementing content strategy (blogs, social media, YouTube videos, etc), and measuring reach and engagement. These are the same skills used by many Community Management professionals in managing and promoting an open source project.

Community management professionals also use skills similar to those used in product sales. These professionals are “selling” a very discerning audience on the nature and virtues of the project and the reasons their “prospect” should contribute to or use this project rather than another. Many community management professionals must be successful at collecting leads at events, ensuring their presentations and content comes across as genuinely educational rather than as a blatant sales pitch, and that their one-on-one relationships are supportive of deal flow, be that deal onboarding a new contributor or executing a new sales contract.

  1. Strategic Partner Management: Open source communities may include many volunteers, but that doesn’t mean they don’t function on business principles. Corporate partners are an important part of a project’s success, and they expect mutual benefit. Community management pros must be attuned to the goals of corporate partners and how they align with the goals of the community as well as with other corporate partners. Management issues can be delicate to handle but they also must be resolved to the benefit of all and not just a few. Preferably without losing a partner or sponsor.

  2. Evangelism and Sponsor Relations: Evangelism differs from sales in that it is focused on promoting the community and the work of others rather than directly on the project. It involves, among other things, developing coordinated community and project messaging, determining the best means to get the messaging distributed internally and externally, and actively promoting the work of other people and organizations who are advocating for the project. Managing sponsor relations to aid with fundraising for project activities or an affiliated Foundation is a top priority. This requires a near-constant external sponsorship search to support events and a pressing need to develop protocols and policies to determine which sponsors are most appropriate.

  3. Field Enablement and Support: Many community management professionals also provide support for project members ranging from technical assistance to dispute resolutions. A big part of most community management professionals’ duties is resolving conflicts between the various volunteer members. This requires both policy-making skills and conflict resolution skills. Further, new members need to be onboarded, welcomed, and encouraged so that they stay interested and contribute to the community in meaningful ways. Talent recruitment and retention are also important functions to ensure the community thrives and the project gains market respect and broad support.

Community managers also provide field support as technical experts for customers. Further, they develop processes designed to provide educational services to Solution Architects and solicit code contributions from customers. These skills are currently in high demand in every organization.

Documentation is essential to the success of any project. The skills necessary to provide or oversee documentation include writing, vetting, distribution, and delineating corporate value versus community value within the documentation. Community management professionals may also find themselves to be proficient editors and good at finding and recruiting writers to focus on documentation.

  1. Finance and Budgeting: Most community managers are responsible for budgets that cover everything from convening events to T&E (travel and expenses) for the talks they give at conferences. Budgets must be balanced and allocated fairly. Some examples of tough budget provisioning are determining how to reimburse community contributors globally, maximizing return on spend for marketing and other activities, and maintaining a financial cushion to enable a fast response to opportunities as warranted.

The various professional roles in community management entail some or all of these functions and skills. Yet their skills are rarely itemized so that they can be recognized, developed and promoted separately as noted accomplishments worthy of job advancement. By itemizing these skills and experiences, the resulting buckets labeled with traditional job roles will give each report a very good idea where their strengths and weaknesses lay, and where their preferences are in particular task categories.

This information will go far in selecting and directing a path aimed at progressing up the career ladder. It will also be valuable to the OSPO senior leader looking to build out a job ladder for those in their organization.

Retaining and Promoting Your OSPO Professionals: Job Ladders

OSPO staff are in high demand. Yet it is often easier for them to change employers in order to advance their careers than to move ahead where they are. While such career moves are understandable, they are counterproductive for the organizations that are left behind.

“A lot of us tend to circulate in the industry. That’s because currently the main way to grow is to move to a position of open source program office leader in another company, typically one that is just beginning to start their open source office. And that’s a great jump because then you become the leader and you start your own team,” said Ruff.

Ultimately it is the companies that offer the highest rungs in the career ladder that tend to net big talent.

“In my case, I came in as a senior director and then was promoted to executive director, and then the next path becomes vice-president and chief open source officer,” Ruff explained.

But most organizations, a chief open source officer or a VP type of role isn’t merited. More often the top positions are director or senior director roles.

“You can also broaden these roles to take on open source standards, or join other open innovation work at universities or at other research projects that the company invests in externally. That then becomes a nice meaty role,” says Ruff.

“I believe that at Microsoft, legal counsel has open source standards as well as open source work under the same umbrella. So I can see that kind of consolidating becoming a broader charter for the open-source program office,” Ruff added.

But even when OSPO professionals do move to a new organization, opportunities to advance to executive director, VP or Chief Open Source Officer are few.

“I’ve seen OSPO members go on to become executive directors at foundations like Guy Martin did. He went from being an OSPO leader at Autodesk to being an executive director at Oasis Open. And Shubhra Kar went from Samsung to the Linux Foundation. Those are the two routes I’ve seen work, but I haven’t seen anything else beyond those,” said Ruff.

Guide reports on building their personal brand

It’s no secret that open source professionals are in high demand across industries. But that doesn’t mean individuals or their projects can necessarily prosper without active and sustained promotion.

In order to gain the recognition and visibility needed for opportunities to find any given individual – or for that individual to promote themselves to higher opportunities, they must actively promote their personal brand.

The returns from OSPO leaders guiding reports on how to build their brand are equally strong for the team, project, and company too. When OSPO leaders actively and visibly demonstrate an interest in their reports’ career development, individual and team morale and performance improve significantly. As reports become more recognizable and respected brands, the project’s brand rises too.

Further, a large part of any project’s success is attributable to its ability to attract and retain developers and other professionals. Having professionals on your staff with highly visible and respected personal brands will go far in attracting more talent to your project.

OSPO leaders can also lighten their own workloads and multiply project and company branding efforts by sending their reports out on speaking opportunities and for public appearances representing the company. By actively assisting reports in building a strong public persona, OSPO leaders ensure everyone wins.

OSPO Leader Networking

Successful OSPO leaders network with their peers to promote themselves, mentor other leaders, and discover new ways to support their own reports. The TODO Group is “the great watering hole for OSPO leaders and frankly all OSPO members,” said Ruff.

The focus in this type of networking is on common issues, challenges, and successes. Competitors not only work together, they seek out such opportunities to advance their own projects in the most efficient way possible. Open source competencies are viewed as separate and apart from core intellectual property (IP) or protected IP.

“Just recently, three or four OSPOs came to me wanting to compare notes. Disney, one of our competitors, asked to compare notes on our respective OSPOs. Verizon Media, another competitor, did the same. And so did JP Morgan Chase & Co and Office Depot, both of which were just setting up their OSPOs. We’re happy to mentor and support them.” said Ruff.

“I think that’s wonderful. And we were very candid with each other because there is nothing secret about it and we want them to succeed. We want this whole industry of media and entertainment to succeed” Ruff added.

Mapping futures

OSPOs win on several fronts when they crystalize career paths for staff. Skill sets within the office expand making it possible to do more with more, even if the head count doesn’t grow too. Employee experience improves dramatically which in turn improves both recruitment and retention rates. Professional networks grow larger and stronger as more reports come into their own leadership roles later. Succession plans become easier tasks. Organizations benefit from expanding and maturing skill sets as they move forward with their open source projects and plans.

When OSPO managers take the time and make the effort to shape clear career paths for their staff, everyone wins.

Acknowledgements

Contributors to this guide: