Skip to content
GitHub Copilot is now available for free. Learn more

Scaling standards and community in your organization

Learn how to implement open source community ideas to spread best practices.

Artwork: Ariel Davis

Photo of Nick Penston
Fidelity Investments logo

Nick Penston // VP of Cloud Engineering, Fidelity Investments

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

Today’s ever-evolving world requires businesses to continually build and innovate at an unprecedented pace to deliver unceasing value to their customers. To succeed at this undertaking, leaders must enable agility across their team’s technical capabilities. The foundation for this kind of agility, across any size organization, begins with a culture built on continuous learning, knowledge sharing, and a passion for innovation. The key ingredient is teams empowered with autonomy, sense of purpose, continuous education, and access to the wealth of innovative technical assets available today. 

So, as you build innovative experiences for customers at speed, how do you ensure your empowered teams are aligned on best practices? How can you remove duplication and improve productivity? How do you create meaningful standards focused on reducing the cognitive load for your engineers while commodifying key aspects of your stacks for reuse? 


In this Guide, you will learn:

  • How to scale adoption of engineering best practices and organizational standards.

  • How to enable sustainable communities around common interests. 

  • The power of a culture founded in continuous learning and innovation.


The challenge

Speak to any developer about standards and commodifying technology stacks, and it often invokes a sense of dread. They are likely worried it will slow the pace of innovation. While driving the adoption of these standards is important, it can become a full-time occupation with seemingly little benefit to your business. 

So, what can you do? There are many approaches to this challenge, but my favorite is quite simple. Despite its simplicity, this model successfully enables the spread of tacit knowledge, creates transparency on best practices, and embeds important organizational standards—all while ensuring teams remain autonomous yet aligned.

Empower through federation

A key tenant to this model is to decentralize the ownership of standards and best practices to small groups focused on specific focus areas of a problem space. Your engineers and technical staff drive this process which facilitates the sharing of skills, knowledge, and measures of success. 

I call this model “empowered federation.” It is made up of three cohorts:

  • Steering Group

  • Focus Group(s)

  • Community(s)

The below diagram illustrates how each of these cohorts works together.

Steering group model

Feedback flows continuously in either direction. Each cohort is aligned and moving toward the agreed shared outcomes, while remaining empowered to act autonomously.

Let us dive into each group.

Steering Group

Like many of the concepts for this method, the Steering Group is heavily inspired by open source projects.

Under this method, each problem space you want to address will require a Steering Group. A Steering Group is comprised of 5-10 members who are passionate about the given technology problem space, knowledgeable in the focus area, and have strong relationships with key stakeholders across your organization. As a group, they are aligned to the needs of your technical capabilities, empowered to determine the overall strategy for tackling the problem space, and responsible for driving the alignment and adoption of best practices and organizational standards in their area. 

Things to consider when creating this group are:

  • Be transparent about the roles and responsibilities of members, who can join, and how they do so.

  • Establish a regular meeting cadence.

  • Create clear goals for the group to guide alignment with your organization’s strategy within a given space.

  • Create a road map, make it visible, and enable anyone outside the Steering Group to contribute to the discussion around it.

  • Recognize and reward Steering Group members for their participation and contribution to the evolution of the space in which they work.

A Steering Group can tackle both a broad or narrow problem space. A Steering Group focused on standards and practices for a given language would be a narrow focus, whereas one in a broad space may focus on infrastructure patterns or end-to-end automation patterns for a set of application types. One example where we used a Steering Group to tackle a broad space was in what we called our Paved experiences. The Paved experiences space was end-to-end experiences for developers within a given cloud technology stack. In this example, the group wanted to remove duplication across teams, improve developer productivity, and accelerate time to market when working in the serverless based stacks space. Here, the Steering Group shaped everything from the developer tooling used to build and validate serverless patterns to the ways in which developers got fast feedback locally. This also enabled the application of automation checks and balances as artifacts moved their way to production, easy adoption of new code, and much more. A successful Steering Group focusing on broad topics should consider including stakeholders beyond your engineering Community to enable buy in across all stakeholders who would be impacted by any outcomes from the Steering Group and ensure successful adoption of any standards or agreed alignment.

Focus Group(s)

Once it’s up and running, the Steering Group can be challenging to scale, especially at a large organization. This is where the Focus Group comes in. 

The Focus Group is comprised of several engineers and technologists who help the Steering Group scale across different areas of your organization, domains, etc. They work autonomously and are accountable to drive the strategy of the Steering Group in their context. You may have one or more Focus Groups depending on the scale of your problem space. A Focus Group follows many of the same principles of the Steering Group such as meeting regularly and having a visible roadmap.

When creating Focus Groups, consider the following:

  • Create them only when the need to scale arises. Groups can be created over time and do not need to be created all at once.

  • Be clear on their scope.

  • Appoint a member of each Focus Group(s) to the Steering Group to ensure alignment.

  • Recognize and reward Focus Group members for their participation and contribution to driving the strategy.

A great example where we successfully utilized Focus Groups was when we embarked on scaling up our open source contribution Steering Group. As we started out on our journey in open source contribution our focus was set on a Steering Group to facilitate this work. As we quickly scaled, we began to incorporate Focus Groups to drive open source contribution across specific areas such as, Infrastructure Technologies, Open Telemetry, etc. This approach enabled us to grow clusters of expertise, thus empowering our engineers to drive success in these focus areas while remaining aligned with our overall mission.

Community

The final piece of the model is Community. A key performance indicator for the Steering Group is the development of a rich and sustainable Community centered around tackling the problem space. These Communities become the platform upon which the Steering and Focus Groups drive education for the practices and standard they seek to adopt. This sense of community fosters consistent knowledge and idea sharing at a rapid pace and aligns the team members on the collective goals and objectives.

At Fidelity, a Community is a collective of individuals who come together based on shared areas of interest. The Community members openly share their knowledge and networks, thus growing our expertise across and outside of the Community itself.

In the example above where we used Focus Groups to scale our open source contribution strategy, we leveraged our internal community of engineers and technical staff who were passionate about open source in several key areas that we felt were paramount to our overall success. We capitalized on this community resource by running local and global events around open source contribution, coaching sessions to help other engineers get started in this space and received continuous feedback on our overall approach. As a result, our expertise grew, our groups goals and objectives were met, and our overall mission was a great success. 

As you build out your Communities, consider taking the following actions:

  • Utilize constructs like the framework for community of practices (CoP framework) to help bring like-minded individuals together around the area of focus.

  • Cater to all levels of expertise when sharing knowledge.

  • Ensure every standard or recommendation from the Steering/Focus Groups is intentionally shared with the Community, and the Community’s feedback is incorporated into any future iterations.

  • Recognize and reward the behaviors you want to see from your Community.

  • Encourage the sharing of obstacles encountered, approaches taken, successes, and failures.

Accelerating adoption

How do you take the outputs from the Steering and Focus Groups and drive adoption of their agreed upon practices and standards? One way to accomplish this is to use the model illustrated below. I refer to this model as “accelerated adoption.”

Adoption success model

In this model, everything begins and ends with education.  

  • Education sets the stage for why your team should focus on this particular topic or engineering best practice and how it can benefit your product or platform. 

  • The demonstration phase illustrates the value in a real-world setting to your engineers and technical staff. Using practical hands-on workshops are a great way to implement this phase. 

  • Next, you’ll want to build a strategy for driving the adoption of common practices and standards. The key here is to be transparent about your strategy and to utilize your Communities to convey it. 

  • Then, measure your starting point and progress made using clear metrics. Indicate what metrics matter most and how they may change over time to reflect your future outcomes. This process allows you to recognize if what you are doing is working and pivot if necessary. Without measurement, progress and impact will be difficult.

  • Circling back to education encourages innovation. It is the most useful tool to promote awareness of new technology, focus areas, and best practices for achieving success. 

Final thoughts

Encouraging a culture that prioritizes sharing knowledge and following best practices is essential for fostering engineering excellence and staying agile. Utilizing federated groups, backed by passionate Communities laser-focused on knowledge sharing, best practices, and constant improvement, is a powerful approach to encouraging such a culture.

 

As Vice President of Cloud Engineering, Nick Penston is focused on cloud engineering excellence and developing exceptional cloud engineering talent to support the enablement of Fidelity's next generation digital services.

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing