Collaborative Technical Governance

The evolution of a technology team often follows a predictable path: as the number of projects grows, the centralized structure becomes inefficient. This was exactly the scenario we faced when our single team, responsible for multiple projects, began experiencing coordination and focus difficulties.

The natural solution was to divide into smaller, specialized squads. However, this transition brought a legitimate concern: how to preserve the technical consistency and quality standards we had built as a unified team?

This concern was based on a fundamental observation: when different people or teams work in isolation on similar problems, divergent solutions naturally emerge. Rarely will two teams, without adequate communication, arrive at the same implementation standard. Once multiple standards are established, subsequent unification becomes extraordinarily complex.

Furthermore, top-down imposition of technical standards rarely produces sustainable results. For a standard to be truly adopted, developers need to feel part of the creation process, actively contributing to its definition and evolution. We wanted to avoid the common scenario where each attempt to establish a unifying standard only adds one more alternative to an already fragmented ecosystem.

In this context, we developed our Collaborative Technical Governance approach, a methodology that balances squad autonomy with the need for technical cohesion throughout the development ecosystem.

The Birth of Drivers: Catalysts for Standardization

During the team division process, we identified the need to establish focal points to ensure consistency of technical standards. The initiative came from our Agile Enabler during the official squad separation meeting, where we defined that some colleagues would focus on standardization and provide technical development support.

These people naturally evolved into “drivers” – professionals who, in addition to their regular squad responsibilities, take on the role of:

1. Catalysts for implementing technical standards in their respective squads
2. Points of contact for issues related to development standards and practices
3. Spokespersons who communicate the status and evolution of standards to stakeholders

This last aspect proved particularly important: drivers became responsible for giving visibility to technical standardization work, translating technical achievements into understandable business value for stakeholders. This ability to demonstrate the value of investing in quality and standardization was crucial to obtaining and maintaining necessary support for the initiative.

The Evolution of Drivers and Work Organization

The driver role evolved significantly over time. What began as intensive support and standardization transformed organically. Today, drivers focus more on project development than exclusive support activities, mainly because fundamental standardization work has been established.

A strategic decision that facilitated this transition was formalizing standardization work within the normal development flow. We established that each squad should reserve a percentage of their work capacity per sprint exclusively for MLOps (Machine Learning Operations) and standardization tasks. We created a dedicated epic and stream line for these activities, allowing any team member to contribute directly, not just designated drivers.

This model proved particularly valuable initially, when dedicated time was intensively used to eliminate code duplication, especially in Infrastructure as Code (IaC). As standards were established and the codebase optimized, the use of these story points became more specific and strategic, freeing capacity for new feature development.

Weekly Meetings: The Heart of the Collaborative Process

To structure standardization work, we established a weekly meeting that became the cornerstone of our technical governance methodology. This meeting, open to all squad members but with mandatory attendance for drivers, functions as a forum for continuous evolution of technical standards.

Structure and Dynamics

The sessions cover everything from initial brainstorming to concrete action definition. During these meetings:

1. We discuss technical issues relevant to all squads
2. We evaluate the need for exploratory investigations (proof-of-concept work or “spikes”) or specific stories
3. Drivers take responsibility for documenting decisions and transforming them into stories
4. In the following meeting, these stories are collectively refined and estimated

Evolution of Agendas

Initially, agendas had more structured and urgent topics:

• Code deduplication
• CI/CD standardization
• Implementation of security practices
• Establishment of pipeline standards

With practice maturation and resolution of fundamental topics, meetings evolved to a more flexible format. Currently, we allow greater experimentation and technical innovation, addressing emerging themes and continuous improvement opportunities.

Concrete Results

The main result is creating technical stories in a backlog shared among all squads. This common backlog ensures standardization initiatives are visible to the entire organization and can be appropriately prioritized during sprint planning, using story points reserved for MLOps.

Open Communication: Breaking Down Barriers Between Squads

A fundamental element of our technical governance approach is the open communication structure we implemented, operating on two main levels:

Central Channel for Technical Discussion

We established a central channel where all squad members can be added and are actively encouraged to participate. This channel serves as:

1. A space for collaborative code review in the common repository
2. A forum for discussing bugs, technical updates, and relevant issues
3. An environment for identifying themes that deserve more structured attention

When we realize a topic discussed in the channel requires more in-depth analysis or formal decisions, it is elevated to the weekly meeting agenda.

Transparency Between Squads

Complementing the central channel, we adopted an “open channels” policy for squad-specific communications. Instead of keeping technical conversations isolated, we encourage:

1. Squad channels to be accessible to members of other teams
2. Developers to follow discussions from other squads, even if not directly involved
3. Help to flow organically between teams, without intermediaries

This transparency seeks to break the “silo” mentality that frequently emerges after division into squads. By maintaining permeable communication channels, we foster unified team spirit, where knowledge and solutions circulate freely despite organizational separation.

Concrete Results: The Impact of Collaborative Technical Governance

The implementation produced significant and measurable results, validating the investment of time and resources in this initiative.

Elimination of Duplication at Scale

One of the most visible results was infrastructure code unification. What was previously duplicated across 3, then 5, and today more than 8 distinct projects, was consolidated into a common and reusable codebase. This consolidation:

1. Facilitated maintenance, with changes needing to be made only once
2. Ensured consistency across all projects
3. Significantly reduced time needed for new implementations

Enhanced Quality and Security

The thorough refinement of shared code led to substantial improvements:

• We have achieved and maintain test coverage greater than 80% for all shared code.
• Security issues, when identified, are fixed centrally and automatically propagated to all projects.
• We established robust standards for Data Quality and Data Observability through standardized scripts.

Strengthening the Testing Culture

One of the most significant gains for our team, which initially lacked a strong testing culture, was widespread adoption of testing practices. By centralizing critical code and requiring high test coverage for shared components, we:

1. Demonstrated the value of tests in concrete situations
2. Established standards and examples that squads could follow
3. Created a cascade effect, with the testing mindset spreading to project-specific code

Challenges and Overcoming: The Path to Consolidation

Implementation was not without obstacles. The main challenge was helping teams embrace the new model initially.

Balancing Standardization and Delivery

Developers, pressured by deadlines and delivery goals, occasionally deviated from the established standardization line. The tension between “delivering quickly” and “delivering according to standards” manifested mainly in the initial phases when standards were still being consolidated.

This required a delicate balance between:

1. Standing firm on the importance of standards
2. Demonstrating understanding of team delivery pressures
3. Conducting frequent alignment meetings to recalibrate the process

Over time, as standardization benefits became evident and teams realized how initial investment translated into subsequent speed gains, resistance naturally decreased.

Beyond MLOps – A Culture of Collaborative Technical Excellence

Our journey implementing this collaborative technical governance methodology has proven transformative for the organization. Although we initially called this approach “MLOps” for convenience, we recognize it transcends those boundaries, representing something broader: a culture of technical excellence sustained by structured collaboration.

The main lessons include:

1. Separation into squads doesn’t mean technical fragmentation – With the right structures, it’s possible to maintain technical cohesion even in distributed teams.
2. Standardization must be collaborative – Top-down imposition rarely works; active developer involvement in creating standards is essential for adoption.
3. Investment in quality needs formalization – Explicit dedication of team time and effort for standardization legitimizes this effort and ensures continuity.
4. Open communication is foundational – Transparent channels and structured meetings are essential to break silos and promote technical collaboration.

The investment in standardization not only improved technical quality but also enriched the professional experience of people involved, providing more opportunities for shared learning and reducing frustrating rework. We observed greater team satisfaction when working with more consistent code and predictable processes.

This approach allowed us to reap benefits of both squad specialization and technical consistency of a unified team. By combining autonomy with alignment, we created an environment where technical innovation flourishes within a cohesive and well-structured framework.

For teams facing similar challenges, our experience suggests that investing in a collaborative technical governance structure, adapted to specific organizational realities and culture, can generate substantial returns in terms of quality, efficiency, and developer satisfaction.