🫱🏼‍🫲🏾 Capchase Communities Blue-print

🫱🏼‍🫲🏾 Community structures within Tech complement our squads and pods.
They are given the high stake responsibility of defining and implementing the standards and systems to deliver results for years to come.
Nowadays we have communities for Data Analytics, Data Science, Data Engineering, Software Infrastructure & Quality, and full-stack.

When I joined Capchase we had three teams: front-end, back-end and data. Each team was centered in a well-defined, stable, tech stack and expertise. Data was the world of python & bigquery, front-end defined our nodejs & reactjs architecture, and back-end had the responsibility of bridging between these worlds using go, rust & elixir. Even though we were less than 15 people then, we had 10+ repos, 7+ coding languages, and 5+ services running. We found three key limiting factors that questioned the whole approach:

• Silos
  Each team had a team lead that was both a people manager & technical lead. Strongly coupled reporting lines made it so that ownership over technology and solutions was centralized in a single team and person. Hence, looking for advice or allowing for people to collaborate outside their teams seemed out of place. Knowledge transfer across the organization was nil.
• Excruciating coordination
  Each project, feature, or new product required these teams to coordinate with each other. Hence, even though we were a small team, most of our time was spent coordinating efforts across these teams. The most challenging piece was deciding when one team was going to implement the ‘missing partial feature’ for another team to deliver. As a result, in most cases, we ended up going back to the drawing board weeks after a project started given the lack of context in early assumptions.
• Future-proof solutions
  Because each team was limited in their view of Capchase’s needs and plans, it was impossible for them to provide solutions that would actually fulfill our business on a long term horizon. They all had a partial view only informed by their backlog. As a result, we had some teams taking on large amounts of technical debt, and others spending months over-engineering solutions.

To solve these limitations we asked ourselves, what is the right balance to strike between speedy delivery and robust innovative solutions?

The answer to this not so original question, drove us to create the squad & community concept at Capchase. Today we will center in the latter.

What are Communities at Capchase?

As Andrew Grove would indicate in High-output management, communities [functional teams] are there to increase Capchase’s leverage whereas our squads [mission teams] are there for speedy deliver on short-term initiatives.

A community is a non-hierarchical team, there are no managers, only experts & leads. It’s an added responsibility to that of our squads for all members who need to actively contribute on a weekly basis. It’s the maximum expression of our builder attitude & servant leadership.

Our community approach was born from two cornerstones of our Tech culture:

1. We fall in love with challenges, not solutions.
   A community is focused on a single main technical challenge in our system, e.g our Data pipelines, our Data Analytics systems, payments infrastructure, CI/CD, customer vendor integrations, etc. That means their expertise is built around the challenge and it could change in the future. We had communities moving from Go to Elixir, from Elixir to nodejs, moving away from bigquery or maybe start using it. The challenge, however, stayed always fixed, as it is core for Capchase.
2. ‘I am because we are’
   Intellectual humility and a ‘we first, not me first’ mindset live at the core of Capchase Tech culture. Communities are teams of tech teams, individuals coming with their unique perspectives from different business concerns in mind and sharing all those to build a better Capchase. Sometimes the changes take weeks, months or quarters, but those are usually the most significant ones. We are here to enable all of us to innovate today, tomorrow, always.

How do Communities work at Capchase?

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.[2][3]

— Melvin E. Conway

Because of the challenge-led approach, communities are born when there’s an almost universal tech need, that should not have a limited time horizon; and often gets discovered through organic discussion between tech leads, community leads & managers.

Once a need is identified, we strive to move towards a ‘system thinking’ first vision and away from a ‘team delivery’-centric approach. Sometimes this results in a conflict of interest between communities and squads. Community’s plans can run counter to the short-term interests of a single squad, so it’s key to find the right initial community members that will have the ability to evaluate these tradeoffs carefully and escalate as necessary.

From those initial members we usually have one emerge as a community lead. This servant leader, which potentially rotates, is the representative for that community and they are responsible for ensuring their community delivers on their commitments, including OKRs.

Finally, participating in a community is considered a privilege, it’s not an obligation. While the community newsletters and support channels are open to everyone in Tech, community meetings are only for individual contributors who want to actively further their impact beyond their direct teams. It’s an added responsibility to that of their squad, and one requiring an equal level of effort. It shows a deep commitment to our Tech & Capchase vision.

Our community blue-print

Expected Outcomes

The single most important piece of a community is their expected outcome. A community exists with an objective, and a community that doesn’t have a vision — ie. a well crafted expected outcome — or fails to deliver on it, needs to be dismantled. It is this methodology that helps us scale & escalate in an organized manner.

So we define a community at Capchase by clearly stating expected outcomes, activities, and member behaviors that regulate the group.

We divided the expected outputs from a community into:

• 6 month+ clear roadmap for a sizable Tech area
  Communities own their OKRs, KPIs, and long term initiatives over certain Tech areas. They focus their energy on improving our systems continuously so we can move faster, with better quality, while fully aligned with the overall Tech vision. They’re often focused on long term results.
• Coordination to define & implement standards across Capchase
  Communities are expected to define standards, and also implement them. To achieve this, a community should allocate less than 5% of their time to finding new approaches, and instead invest heavily on mechanisms to further existing approaches that have already been defined as standards after a Tech-wide approval. We expect a community will invest most of its time making efforts to track, measure and iterate their solutions.
• Continuously shared knowledge, tools and practices
  Communities should provide async channels for every Tech staff member at Capchase to ask related questions and get support. In general, they should provide open community slack channels, email groups — so that others can email questions without becoming a member — and even office hours when needed.

Activities

• Follow best practices in their area of influence: these best practices are documented and shared across the company on a centralized information hub.
• Ensure the general reliability and quality levels for all related systems under the area.
• Translate Capchase’s vision to our Tech functional spaces, eg. front-end, back-end, data analytics, data engineering, data science, reliability, QA, CVI, etc, with enough thought process that it accounts for future needs and changes in our objectives.
• Define and propose extensions of Capchase best practices.
• Define code reviewers, and ensure Tech design reviews include an adequate representative of the community when needed.
• Regular meetings with all active members.
• Share updates with the wider Tech org: e.g. a newsletter or meeting minutes.

Community member behaviors

A community is its members, it’s essential that every member is an example of Capchase Tech in their values and behaviors:

• Builder attitude is the most important quality for all members
  We value action over ideas. Every community member needs to take on the responsibility of helping improve the community by making things happen while helping enforce best practices. That could look like actively validating and implementing solutions in the area, by means of pull request reviews, design reviews and contributing to new projects.
• Regularly attends & effectively contributes during weekly meetings.
  Participating during meetings is highly encouraged. But making those contributions effective is the key characteristic of each community member. Community meetings are open, but community members have to contribute their time and effort to current projects, not just check in for interest or to increase their knowledge. Communities are for the invested, not the casually interested.
• Shares knowledge and validates ideas with the whole Tech org.
  A community member needs to influence more than their direct teams. They’re responsible for sharing the knowledge acquired in the community with the wider Tech org. But as examples of the Capchase builder attitude, they have to make sure they’re influencing through their work as well as through sharing updates: they should validate ideas with the whole Tech org.

We call this our invested membership principle.

This blue-print is the end result of multiple iterations in which we had introduced small thought through changes and measured the impact that they had in Tech and Capchase.

Stay tuned for more!

Stay tuned for a detailed post on how those changes and iterations were introduced and measured.