Get the reportMore
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.
April 25, 2022
by Sam Fell, VP, Product Marketing, Observability, Sumo Logic
I love technology, and I’m thrilled to work in a profession where I’m steeped in it! In my career as a developer, consultant and marketeer I've learned it’s not “the cool new tech stack” that helps win the day. It’s the “people stack.”
Gene Kim, one of the authors of the “The Phoenix Project,” once told me, “the quality of the daily work is less important than the improvement in the quality of the daily work.”
This resonated: “getting good at getting better” is a key part of the goal. The journey is the reward.
When I heard about what our customer, Michael Basil of SAP Fieldglass, and his team have done to support each other along their journey to DevOps, I knew we should share their story, for its potential to inspire and affect change. One of Sumo Logic's core values is "being in it with our customers," meaning we try to understand and support their priorities, align with their goals and learn from them. If one of you finds any inspiration reading this and can affect even a little change (for the good!) in your org, we will be overjoyed.
Tools and specific engineering practices are key components to helping organizations evolve from a traditional IT mindset to a culture of DevOps. But this dramatic change requires taking intentional steps to influence a culture open to new approaches, deeper collaboration and service ownership.
Expanding SAP Fieldglass from on-premises data centers to a multi-cloud approach to accommodate the sharp increase in the data requirements of our expanding customer base, we found ourselves at a crossroads. We decided to transform from virtual machine (VM) architecture to Kubernetes, from a traditional IT mindset to DevOps-oriented Agile delivery.
There had to be a comprehensive shift in attitudes and practices toward work to get people who operated in silos to embrace DevOps and face the challenges of drastically changing work culture. In getting people technically and mindset-ready for Kubernetes and DevOps and promoting continuous learning within SAP, we found success through the Dojo from SAP, a Community of Practice, where I am a curator.
Four years ago, SAP Fieldglass was at an inflection point, moving our TechOps from a traditional IT approach—primarily a point-and-click GUI operation—to a way of working more aligned with DevOps. With our move to a multi-cloud approach with hyperscalers, we had to break down the silos of work. Adopting DevOps meant embracing close collaboration and goal overlap between development and operations and putting the customer first by focusing on service ownership instead of the disparate functions in traditional IT.
We initially considered beefing up the headcount and hiring "DevOps engineers" but ultimately decided that the best step is to level up the existing group to learn Kubernetes, Agile and DevOps principles and paradigms. It was a significant shift. People who previously didn’t have to code now have to run Kubernetes workloads where everything is code.
People who previously didn’t have to code now have to run Kubernetes workloads where everything is code.
The key challenge was figuring out what hinders the traditional IT person from becoming a Kubernaut, ”naut” stemming from the Greek naútēs, meaning sailor. A Kubernaut, at minimum, can confidently work with containerized workloads. Formally, they’d be certified Kubernetes admins (CKA) or developers (CKAD). Some of our existing teams had coding experience, and some had Git and source control experience. To level up, we had to approach things holistically—a culture shift instead of just introducing new processes that people had to follow.
To do this, we had to have a shared determination among everyone to embrace a flexible mindset and not freak out, i.e., actively or passively resist this disruption to the status quo.
Facilitating this learning and mindset shift was among my original tasks when I joined Fieldglass, a part of the SAP family focused on managing internal and external workforces with its Vendor Management System (VMS). Along with a core group called the Disruptive 7, we methodically constructed a learning experience that emphasized developing and cultivating an open mindset and acquiring the necessary technical competencies required to evolve.
All virtual and with no monetary budget, we started with a wiki and built out the initial content on GitHub. We decided to apply the System Metaphor of a dojo the day before launch, inspired by Target’s internal learning platform, Target Dojo. A dojo captures the spirit of what we envisioned for learning: a place for exercise and conversation, where everyone levels up their technical skills while working on achieving the right mindset to maximize learning and wise application of this newfound knowledge.
The Dojo’s tagline, “Learning is a magical, conversationalized, and rewarding investment. Ride the Waves!” encompasses its spirit. Learning is not linear. People's brains work in waves, and there must be space to process and synthesize new information, embrace learning cycles. Learning and applying it is a magical feeling that may sound nebulous, but anybody who has achieved breakthroughs in deep learning can relate.
House of Santa is a popular exercise that SAP adapted to highlight Systems Thinking.
Fundamentally, the Dojo exists as a space for dialogue. A Dojo contributor reminded our community recently that while guiding another, everyone learns and a network forms. This is key to DevOps, and more generally, any cultural evolution.
Having conversation encouraged and woven throughout the Dojo is a key piece of the learning design to deepen knowledge and get people accustomed to taking ideas out of their heads and into discussions. This approach is anchored in the understanding that when people can confidently participate in conversations without the threat of blame or “losing,” i.e., feeling safe and secure in conversation, learning flows and they perform their best work.
The Dojo houses various Practices covering topics from Mindset to Kubernetes and Agile. Within the Dojo, the Mindset Practice is on the same level as technical topics, underscoring the importance and broad applicability to any situation, condition, or endeavor.
Currently, the Dojo has the following Practices:
Resilience (for SRE)
Following the martial arts theme, each Practice is broken down into belt colors that represent different learning levels, much like how new judokas and karatekas work to acquire new belt colors as they advance in learning and practice.
Beginner learners start with the Green belt and work toward the Black belt.
Green belt - See how things are done
Red belt - Do something impactful with support
Black - Apply creatively and support others
Each Practice has a general objective. For example, the objective of the Mindset Practice is to learn how to maintain a state of relaxed alertness when encountering and navigating conflict. There is also the Motivation section containing quotes akin to martial arts mottos that serve as guidance for the practice. The Communities section links to internal and external communities where learners can discuss the Practice topic with others.
To acquire a belt, members work through content—videos, articles, text, exercises, activities, courses—curated from various internal and external sources. The content is structured so that they consistently build upon knowledge and gain opportunities to use new learning about a Practice in conversation. For technical Practices like Agile and Kubernetes, learners are encouraged to complete labs and take certification courses and exams paced according to their current belt level, but even these are supported through dialogue throughout the stepwise journey.
The requirements for belt completion are outlined clearly, prompting learners to complete action items such as:
Answer questions about learning topics
Provide evidence of mentoring another person through the Dojo
Publish a video or a blog post about their Dojo experience.
Learners can also submit feedback about the Practice. An Issue is then created on Github for each submission, which Dojo curators then check.
Our emphasis is not on having the most number of belts awarded but that every single Black belter is another person within SAP who can “break through the forms” and apply knowledge creatively in their work.
From the start, the Dojo has always been an InnerSource project. This means that although the initial sponsorship was from Fieldglass, it is run on open source principles in that anybody within the company at SAP can use and contribute to the Dojo. Today, the Dojo has curation, engagement and contributions spanning dozens of departments.
Keeping it open encourages groups to flexibly use it in the ways they need. Groups also actively contribute to the Dojo, like the Resilience, Security and Virtualization Practices, which people outside the core group curate. Content also stays in the Dojo as long as it is needed. Practices that garner little interest are eventually taken down, and new Practices are added when there is a need or interest.
My current focus is developing the Resilience Practice focused on SRE with the collaboration of some of our best SREs, from SAP at large, both in technical and critical thinking ability. This is in line with how we approached the shift to DevOps from traditional IT. We use the Dojo to transform how people work and think through the SRE lens. We’re not trying to create batches of SRE people to go around and fix problems. Our goal is to level people up with SRE motivations.
Several groups within SAP have also tapped the Dojo core group about “franchising” the Dojo. Not so much as using the codebase to create new Dojos, but using the Dojo learning design to kickstart their programs and spaces for dialogue, taking from the Dojo’s beliefs, values, and emphasis on conversations.
Teams within SAP are borrowing from the Dojo to kickstart their programs.
Not infrequently, a question is posed from a frustrated individual trying to help a group move forward. To create change, we must be open to changing ourselves—first! Durable change is not directed or demanded. It is chosen and decided from within us when we are willing to challenge our comfort zones.
Durable change is not directed or demanded. It is chosen and decided from within us when we are willing to challenge our comfort zones.
Thank you to those who have directly helped and those who inspired us from afar. This keeps the "people stack" in sight. For anyone curious to engage, please reach out to me directly on LinkedIn or check out this TED Talk on "how to start a movement."
Reduce downtime and move from reactive to proactive monitoring.
Build, run, and secure modern applications and cloud infrastructures.Start free trial
Application performance management (APM) and distributed tracing are practices that many teams have been using for years to help detect and mitigate performance issues within applications—while the first one was born in the era of big single-host monoliths, the latter is especially useful for distributed applications that use a microservices architecture, in which tracing is critical for pinpointing the source of performance issues.