GitOps Fish Series — (Rib 2) Culture and Team Collaboration — An optimal blend of key profiles for the ultimate team

8 min readSep 6, 2023

Assembling the right team is crucial. Just as a gourmet dish requires specific ingredients, each bringing a unique flavour, so does the journey of GitOps, which demands a mix of diverse skill sets and mindsets that are almost impossible to find in a single person.

This blend of distinct profiles in a team is fundamental because if you aim to change culture, the first step is to achieve it at the team level. Creating a team only with new elements will create an illusion that you are moving forward in the DevOps Journey. The diagram below illustrates these.

In a nutshell, The Traditionalist values and brings tried-and-true methods (you must use all your intellectual capital/knowledge), while the Siloed Specialist dives deep, providing expertise in a specific area. On the other hand, the Doubter constantly challenges ideas, ensuring they’re thoroughly evaluated, and this is balanced by the Enthusiastic Adopter’s passion for embracing new practices. Bridging the gaps is the Collaborative Integrator, fostering connections between varied teams. When faced with challenges, the Problem Solver finds innovative solutions. Meanwhile, the Continuous Learner ensures the team remains updated, acting as the pulse of the latest knowledge. Feedback is crucial, and that’s where the Feedback Advocate steps in, championing its significance in growth. The Systems Thinker takes a step back, always approaching problems holistically and driving everyone to surpass their previous best is the Bar Raiser, motivating the team to new heights.

These profiles (or key characteristics) may or may not exist in some persons of your teams, the important aspect is to realise/identify/recognise them and blend them into your team. Let’s dive a little more into each one.

Typical Approach Story (adapted/based on true stories)

Episode 1 — Get the Technical Stars together to discover how to do it

In 2016, I witnessed an organisation dipping its toes into Public Cloud for the first time. Eager to upgrade from their legacy infrastructure management practices, they decided to assemble an elite team. The aim? To embrace automation, speed, and cost-effectiveness.

This “dream team” consisted of seasoned experts from various domains: systems administration, database management, service management, and systems architecture. Their unifying factor? Each of them was amongst the most credible members in their fields.

To create a unified vision, Design Thinking Practices were introduced. The goal was simple: refine broad objectives to align with leadership aspirations. However, the landscape of the tech industry was already undergoing rapid evolution. While GitOps was still undefined, buzzwords like DevOps, Agile, and Infrastructure as Code rapidly gained traction.

As leadership continually shifted targets, the team struggled to draft a cohesive set of MVPs (Minimum Viable Products). These MVPs addressed recurring “Hot Pains” prevalent in various projects, such as monitoring, configuration management, and backup.

However, the defined MVPs stirred unease within the team. Many felt that the root issues were being sidestepped. Worse, some members believed the MVPs were direct critiques of their competencies. This sentiment soon led to frustration and dissent.

With work underway, the team grappled with old habits. They found themselves employing familiar manual techniques and tools. The initial optimism from the Design Thinking Practices fizzled out, replaced by disagreements and indecision, much like the storming phase in Tuckman’s Stages of Group Development.

Months passed, punctuated by resistance to change, missed meetings, and unmet deliverables. The initiative, once promising, eventually met a premature end.

Episode 2 — The (New) Iceberg

Burned by previous experiences (resistance to change), leveraging on a new need (building a self-service infrastructure provisioning system for the Development Teams), the organisation tried a different approach. This time, team members were selected based on their will to learn, try and experiment with new technologies. To minimise eventual risks and cover technical ground, some members who were technically versatile (not necessarily SMEs) and good at problem-solving were added to the team.

While with limited experience in managing mission-critical environments at scale, the team got some good results. Without dealing with all the objections and concerns (some of them pertinent), the team focused on building the necessary functionalities and automation. In less than 3 months, build up a self-service provisioning system encompassing monitoring, backup, quotas management, etc.

“Managing Mission Critical Systems at Scale” refers to the processes, strategies, and practices involved in overseeing and ensuring the consistent, reliable performance of vital IT systems, mainly when they have grown in complexity, size, or user base. As these mission-critical systems expand, they might span multiple geographic locations, handle millions (or even billions) of transactions, or support vast numbers of concurrent users. Effective management at this scale often requires advanced monitoring tools, automated scaling solutions, rigorous security measures, disaster recovery planning, and coordinated deployment strategies while ensuring the system remains resilient, efficient, and meets the organisation’s core operational needs.

The problem was that the new provisioning infrastructure had some critical needs that weren’t being addressed (compliance, asset management, change management, etc.)

Episode 3 — New Islands and Heroes

Recognising both the gaps but also the good results, leadership decided to pick up some of these new team members (who had proven their ability to “automate stuff”) and moved them to other teams/areas that were missing automation, ending up in heroes scaling with all the disadvantages associated with, and, adding some of the original initiative traditionalists and doubters to provide guidance and help on covering the identified gaps.

Powered by the “ability to prove it works”, incorporating these new profiles in the team showed results, and the new “self-service provisioning system” was now covering the organisation's mission-critical system requirements, however, it was now a new island — whenever there was a problem with a resource, the usual production/operations team was clueless or took a “don’t touch approach” because those resources weren’t provisioned/managed by them.

Getting the perfect blend of Profiles

No need to continue with more episodes on the above story, it’s clear that we need to consider several “profiles” when establishing a team and in a DevOps/GitOps context because it will involve, in most cases, changes to practices, way of working, and culture, this is paramount.

The tables below present a set of generic guidelines to deal or potentiate with highlighted vital profiles.

Remember that by individual, you will find more than one profile. Ideally, your team should have all of these present, as each brings value. If you are considering only technical aspects/skills, see the previous article.

Addressing Challenges of Traditional Profiles

While at first sight, you may be considering removing them from the equation, from my experience, you won’t be changing the culture but creating a new team formed with members with a distinct culture. Worse than that, in a very authoritarian style organisation, you may be getting and yes from these but you may be trapped in the first two of “Patrick Lencioni’s Five Dysfunctions of a Team” (Absence of Trust and Fear of Conflict).

Profiles to Potentiate/Value

These profiles can be used as levers to influence others and to guide the previous ones through the necessary practices/approaches to transformation.

Conclusion and Key Takeaways

Team profile composition is pivotal in the success of DevOps/GitOps practices. Through the shared experiences and character profiles, it’s evident that there’s no one-size-fits-all approach to team assembly. However, a balanced mix of skills, mindsets, and approaches is essential to navigate the complex world of the required cultural change.

Blending different profiles can help create an environment conducive to change, growth, and constant improvement. Furthermore, understanding each profile's strengths, challenges, and values is vital for leaders to facilitate the right environment, encourage the best practices, and ensure the overall success of GitOps initiatives.

Key Takeaways:

The blend of Profiles is Vital: A successful GitOps journey requires a combination of diverse profiles. No single person can encompass all necessary attributes, thus, understanding and integrating multiple profiles is critical.
Value Legacy and New Profiles: Both heritage profiles (like the traditionalist) and newer, more adaptive profiles (like the enthusiastic adopter) should work in tandem. This synergy promotes blending, which is vital for cultural change.
Avoid Creating Heroes: Breaking a team to create new heroes can lead to a series of problems. Heroes may offer short-term solutions, but they aren’t a sustainable approach.
Understand Profile Challenges and Potentials: Each profile has its challenges and potential. Addressing the challenges of traditional profiles is as crucial as potentiating the strengths of other profiles. Investments in education, training, pilot programs, strategic planning, empowerment, and feedback mechanisms are some strategies to harness the potential of these profiles.
Cultural Change is a Multi-Level Effort: Changing an organisation's culture starts at the team level but must also occur organization-wide.

Please note that the opinions and views expressed in this article are solely my own and do not represent my employer’s official position or policies. This is a personal commentary based on my experiences and thoughts, and although I aim for accuracy, there may be errors or omissions in the content.

Articles in this series:

GitOps Fish Series — (Rib 2) Culture and Team Collaboration — An optimal blend of key profiles for the ultimate team

Typical Approach Story (adapted/based on true stories)

Getting the perfect blend of Profiles

Conclusion and Key Takeaways

Written by Alexandre Soares