In our 2nd blog DevOps Dojo – Experiential Learning, we shared with you that we couldn’t find a better example than showcasing how our Aspires leverage all the methods listed in the blog to advance their careers and learnings. Their way of learning is disruptive, creative, and inspiring. This blog is dedicated to our Aspires and their support ecosystem!
The Aspires are the youngest employees at Microsoft who graduated recently from the university. Joining Microsoft without field experience and dealing with customers from day one is challenging, especially considering that they must often deal with customers with way more experience than themselves. However, the power of the fresh Aspires brings different worldviews to the table, unleashes their creativity and energy, and helps us discover new ways to accomplish the Microsoft mission.
Dojo Aspires came to Dojo through different circumstances but all with the common aspiration to learn and grow. As they move through the uncharted broad territory of DevOps, the Dojo journey for Aspires is not meant to be easy sailing. With relatively less knowledge and experience, how can Aspires make a difference?
Every challenge is an opportunity in disguise. Their curiosity, their courage, their passion, and their ability of quick learning helped Aspires become key members of this creative community. They try fast and fail fast with disappointments and roadblocks along the way. Meanwhile, they learn fast and grow fast in the forefront with the help of experienced Dojo coaches. With the virtuous cycle, Aspires along with the Dojo community form a strong bond and make progress together towards a promising future.
In this blog, we will first look at what drives people, what types of people we are attracted to, and what the attributes of Dojo coaches are. Then we will have a personal story from each Aspire, and finally learn how experienced Dojos and Aspires work together in Dojo teams.
Part 1: People in Dojo
In Dojo, most of us have read the book “Drive” – a book about what motivates us.
Motivation 1.0
Presume that humans are biological creatures, struggling for survival.
Motivation 2.0
Rewards and punishments: presume that humans also respond to rewards and punishments in their environment.Motivation 3.0
The upgrade we now need: presume that humans also have a third drive, to learn, to create, and to better the world.
In the book, the first chapter talks about a very interesting case study involving the first ever digital encyclopedia, which was developed by Microsoft. Microsoft was already a large and profitable company, and with the introduction of Windows 95, Microsoft was going to fund this encyclopedia. It had paid professional writers and editors to craft articles on thousands of topics. Well-compensated managers oversaw the project to ensure it was completed on budget and on time. Microsoft sold the encyclopedia on CD-ROMs and later online.
The second encyclopedia didn’t come from a company. It was created by tens of thousands of people who had written and edited articles for fun. These hobbyists didn’t need any special qualifications to participate. Any nobody was paid to write and edit articles. They worked sometimes twenty to thirty hours per week for free.
The rest is history. On October 31, 2009, Microsoft pulled the plug on MSN Encarta, which had been on the market for sixteen years. Meanwhile, Wikipedia ended up becoming the largest and most popular encyclopedia in the world.
So, what happened? The conventional view of human motivation by rewards has a very hard time explaining this result. This book reveals the surprising truth about what motivates us as the Motivation 3.0: Autonomy, Mastery and Purpose. It is those who are less motivated to pursue extrinsic rewards who eventually receive them. When the reward is the activity itself such as deepening learning, delighting customers, or doing one’s best, there are no shortcuts as the only route to the destination is the high road. The people who are if/then types (if you reward me, then I do it) narrow their breadth as well as their depth, making it hard for them to create greatness. Greatness and near-sightedness are incompatible in life and at work.
So, what does Autonomy, Mastery and Purpose mean to us in Dojo?
Purpose
When people come to Dojo and stay in Dojo, they believe in our mission.
-
- Solve the hardest problems in DevOps
- Accelerate DevOps Culture
- Make DevOps Real
They want to solve the hardest problems in DevOps, such as topics like People/Team challenges, DevOps Architecture, how to apply SRE, moving from Project-centric model to Product-centric model, how Accessibility and UX can become part of DevOps, C-level conversations in DevOps, intelligent-driven DevOps, etc.
They understand that the only way to accelerate DevOps culture is by walking the talk. The Dojo community is a safe environment in which to make mistakes or have strong opinions on doing things differently. We don’t argue and discuss endlessly, we embrace a culture of experimentation by testing anything from Intellectual Properties (IPs) to readiness, to offerings, to delivery. We let users (internal customers and external customers) help us to validate the value hypothesis.
They have seen enough from books and articles; they want to make DevOps Real by doing it, especially for the new and undiscovered areas in DevOps. Dojo was one of the earliest groups in Microsoft Services to innersource content and learn end-to-end GitHub with the unlimited imagination of using GitHub.
Autonomy
In Dojo, we can decide who we wish to work with, when to work on what, how to work, where to work, which initiative to take, and when to join or quit. Like the Open-Source community, most of our communication is done through asynchronous communication, in fact everyone is geographically distributed, and everyone has customers to serve, so it is almost impossible to meet frequently at the same time. Therefore, we truly embrace asynchronous communication and autonomy in our community.
Indeed, one of the interesting things of being part of the Dojo community is seeing how everyone innovates with every new challenge. The culture that we have in DevOps Dojo is to address every challenge as a new opportunity, and the autonomy given to the team always lets innovation overcome any challenge.
Mastery
At Microsoft, we believe in mastering through growth mindset. Growth mindset embraces every misstep as a learning opportunity, not as a failure. It is an open-minded perspective that encourages improvement, which leads to success. It never assumes that people are limited by a level of intelligence or lack of ability. People come to Dojo to learn something that they might not have the opportunity to learn in their day-to-day job. Since the Dojo community is a psychologically safe place, it allows for mistakes and flaws, thereby giving Dojo more time to learn and improve.
Additionally, this community attracts people with qualities outlined in a quote by Kingman Brewster, President of Yale University, in which he discussed the process of selecting future Yale students:
“I am inclined to believe that the person who gives every ounce to do something superbly has an advantage over the person whose capacities may be great but who seems to have no desire to stretch them to their limit.”
Attributes of a Powerful Dojo Coach & Aspires
In Gartner’s research paper “4 Steps to Create a DevOps Dojo That Accelerates Learning and Cultural Change”, it outlines the optimal attributes of a dojo coach as follows:
-
- Lean Thinker
- Agile Mindset
- Strong Listener
- Development Experience
- Hands-on DevOps Experience
- Easily Builds Trusting Relationships
- Focused on Continual Improvement
- Charismatic, Strong Leadership Traits
- High Level of Emotional Intelligence
- Experience with Organizational Change Management
Gartner’s research has shown that coaching skills are not always innate. In many cases, coaching and mentoring are skills that must be taught. As the Dojo begins to gain traction, it is highly recommended to create a Dojo master role—in essence, a coach of coaches. This role is especially critical in large organizations. The Dojo master will coach and teach other coaches to be effective and is tasked with leading pilots in the Dojo. The Dojo master will also play a key role in establishing the link between the Dojo’s experiential learning approach and cultural transformation. To maximize the impact of DevOps Dojos, Gartner suggested that we should complement this approach by creating culture hacks and communities of practice.
Even though we don’t have culture hacks yet, we have integrated lecture/role play/discussion of culture and Management of Change (MoC) in every single capability in the Dojo Orange Belt. We created “DevOps Dojo – Community of Practice (CoP)” with a weekly community lead who leads the community through various activities, updates, and learning.
In Dojo CoP, we have very experienced professionals in the following functional areas: App Dev, Quality and SRE, Infrastructure, Security, UX, Operations, Data/AI, and Adoption Culture Management. They are from various roles, such as Scrum Master, Project Manager, Architect, Consultant, Account Manager, Customer Engineer, Delivery Manager, Digital Advisor and Architect Manager.
Unlike our standard customer delivery project, which has more rules, formalities and hierarchies, Dojo development and learning is equal among all the participants regardless of your title, your function, your seniority, or your role. This provides an incredible learning and growth opportunity for our young Aspires. This is reflected in the aspects below.
Role Model: Our Dojo master coaches exhibit many of the attributes of a Powerful Dojo Coach outlined in Gartner’s research, so those master coaches serve as the best role models for our Aspires. With those experienced and high-quality master coaches, this community can teach the young Aspires how to be good human beings, and how to do things properly. This community gives Aspires time to figure out their strengths and where they want to end up—and all of that takes time. As long as Aspires stay with the Dojo community, they will continue to receive those benefits on daily basis.
Fast-Track Learning: With the help of experienced Dojos, the Aspires learned DevOps in the right way. For example, designing and writing the content for the lab guides helped Aspires to learn so much about Azure that they were able to clear their certifications with minimal reference to study materials. After six-nine months with the Dojo community, the Aspires became very productive in their customer projects, and some even became the top performers. Many of them received various recognitions and promotions in their first two years with the Dojo community.
Career Aspiration: Because of wide spectrum of topics and areas covered in Dojo, Aspires are exposed to some highly advanced topics that they would not have encountered in their first few years of normal project delivery. These topics include Product-Centric Model, Accessibility, SRE, Capability Model, Advanced Security, Management of Change, KPIs, Intelligent-driven DevOps, Innersource, experiential learning, facilitation, and coaching. This opportunity helped them to know themselves better and make intelligent-driven decisions. For example, some fell in love with product management role, some discovered their greatest talents in facilitation and coaching, some were determined to invest heavily in Accessibility, some became GitHub gurus, and some wanted to pursue leadership role.
We have seen tremendous transformations of the Aspires in our Dojo community. In DevOps Dojo, all the impactful innovations were led by or had the involvement of Aspires. Let us share some of their personal stories.
Part 2: Aspires’ Story
Aakanksha Aakanksha on Personal & Professional Growth
I want to share my story about the failure, improvement, and success of the first DevOps Dojo White Belt Train-the-Trainer (T3) Master Class and the first Master Class for the region.
Before the pandemic, DevOps Dojo Master Class was an immersive one-week face-to-face training including DevOps four pillars and eight capabilities with Objective/Key Results (OKR) and Microsoft transformation journey in DevOps.
After joining the initiative and doing the development for a few months, I had a fair idea that this was about revamping an open-source application using Azure DevOps, but I had no clue on who the audience would be and who would use Dojo White Belt solution. Once we completed our initial set of (Minimal Viable Product) MVP, we were asked to fly to Seattle for my first Dojo T3 class. We went there super excited as well as nervous. Once we reached there, we realized that Dojo was much bigger than it looked from offshore. There was so much going around those two weeks about our vision, our strategy, our culture, logistics, curriculum, and what not!
For the first T3, our hands-on labs failed miserably. People just hated the hands-on labs as they did not like the instructions, guidance, storyline and in fact the whole experience end to end. My colleague and I sat in our hotel room thinking with the solution lead on what to do next to improve the labs. We couldn’t sleep at all thinking about the labs and the unsuccessful attempt in T3. It was very hard to swallow the pain, especially when we put all our heart, soul, blood, sweat, and tears into our labs over past few months.
In retrospect, we realized that it was not about labs. It was in fact when students transitioned from presentation to labs that they missed a very important part during the Master Class called design session which was a connector between theory and hands-on labs. We introduced this interesting concept called Role-Play-Design where we gave narrated problem statement to participants, and teams came back to us with causes and potential solutions after reviewing the narration and then discussed among the team in their breakout sessions. Along with this, we improved our instructions by making them more user friendly. Additionally, we created reference branches for each day’s content, so that no one was left behind when we moved forward to the next day’s agenda. We did all this activity during two weeks of buffer time between our first T3 and first Master Class for the Americas time zones.
What were the results? We were super successful, and people loved the overall design of Dojo classes, theory, design sessions and hands-on labs! This was a moment of pride for all the coaches who developed and contributed to White Belt content.
Those 4 weeks in Seattle taught me many lessons but I will share a couple ones here:
-
- In times of adversity, always believe in yourself and keep going on in life.
- Despite how small we are as human beings, the impact made by a small group of dedicated and committed people can be enormous.
- When you are young, you might not be taken seriously, but by showing your value and delivering with excellence, you can be successful in life.
The first Master Class is always near and dear to my heart, as I have so many memories captured in the form of pictures. Here is one of them I’m sharing with all of you to cherish!
Deep Mehta on Accessibility
Accessibility shouldn’t be taken for granted, and I have learned this at a personal level.
I have had speech impediment since childhood, and in situations when I am terrified to ask for an item at the counter, I wish that the store had items easily accessible. This was my sole motivation to lead the DevOps Dojo Greenbelt for Accessibility. This is an innovation in DevOps, which ensures that every project irrespective of tech stack considers accessibility at every stage of the project.
We in the tech industry often consider accessibility as an add-on, but that shouldn’t be the case. Yes, it wasn’t easy bringing the two worlds of DevOps and Accessibility on the same page, but we knew it had to be done. We interacted with SME from both fields and devised a design to include accessibility right from the planning phase. While developing this solution, I evolved at a personal level, because I knew that my contribution to this will be a step forward in transforming the mindset of people towards the inclusion of accessibility in technology.
In the end, I want to highlight that it’s true there have been hurdles in the way, but one thing that we as a team have proved is that a positive mindset and hard work goes a long way.
In 2020, we completed our first DevOps Dojo Green Belt for UX & Accessibility. It was a fantastic experience packed with excellent and eye-opening content. The 16 topics kept this broadly world-wide distributed team awake throughout the week. As the week evolved, we dug through topics where Accessibility seems to have no place, but guess what? It does! That was an incredible eye opener that really touched our heart and soul. A comment that better describes this was, “This is the most emotive of the Dojo Master Class!”
Margarita Sanz on Making GitHub Real
Teamwork is dream work, and I know of no better representation of this than the DevOps Dojo team. Nine months ago, I was still trying to find my place at Microsoft. After almost two years of consulting, not all my experiences had been good and sometimes the teamwork had been more demotivating than anything else. Finding a real team is not an easy task, and yet it is the most important ingredient for success. Everything else can be learned. However, nine months ago, I was also about to start one of the adventures I have enjoyed the most in my professional career, but also in my personal life.
Make GitHub Real was about bringing to life a new DevOps reference architecture mostly leveraging GitHub features and solutions. It wasn’t easy. We were working with technologies that had just come out of the oven with tools that were still in Beta, while asking day in and day out when X functionality was coming out. We had to work hard, against the clock. The whole solution had to be designed, implemented, and tested in a very short time.
But what a time! I have never seen people more committed to a goal than this team. The team went from China to Madrid, passing through India and Switzerland, to multiple time zones in the US, etc. Different time zones, different languages, and different backgrounds, but the same goal, and above all, the same CULTURE. I know by heart finding a team where you feel supported, and valued is not easy, and even though the path hasn’t always been smooth, I would walk it again without doubt. We were not a team, we were friends, we were family working side by side supporting each other.
The day I joined Microsoft felt like I had fulfilled a dream. The day I joined Dojo, I felt like I was joining a new family. Today I develop, learn, and grow hand in hand with all of them, and I couldn’t be prouder and more excited about the future that lies ahead.
In a recent Internal technical event, eleven of us presented together the end-to-end Make GitHub Real implementation in two hours. It was a large operation to pull this show together by demonstrating a full-stack engineering team using GitHub and Azure technology. As much as we are proud of our innovation, we are even prouder of our amazing teamwork.
Alvaro Guadamillas on Innersource
Dojo was the first place where I met people with a clear holistic understanding of DevOps, not only about technology and, not only about pipelines, which always was the general approach to DevOps. I saw so much amazing content created by the DevOps Dojo community that from day one I felt the need to make this content as open to everyone as possible.
After two months of being part of the Dojo Community, I felt enough trust to share one idea: why don’t we make DevOps Dojo content Innersource? Why don’t we apply Pull Request to the creation of the content and collaborate at scale to have the latest and the greatest content available to everyone at Microsoft? Why don’t we avoid having multiple copies in PowerPoint distributed everywhere and having a single source of truth instead?
Without the right culture, this idea would have been immediately killed. Indeed, I suggested the same approach in other forums without success. In Dojo, this small idea was well received by all members, and I was proposed to lead this effort with the support and wisdom of all Dojo members. This took us on a journey in which we approached the GitHub team to learn the best experiences from the most experienced people on Open Source and Innersource.
Innersource takes the lessons learned from developing open-source software and applies them to the way companies develop software internally. Innersource is a cultural transformation. With consideration of the cultural impact of Innersouce, we decided to pilot Innersource first on DevOps Dojo White Belt solution. With the support of the Dojo community，including Azure DevOps engineering team, and the expertise from GitHub, we created the first Innersource pilot in Microsoft Consulting Services with enormous success.
Today, our content is continuously improved by the community, we have our single source of truth with the latest and greatest content, and we collaborate on a scale, at anytime and anywhere in the world. Hopefully, after this successful pilot we can Open Source our content soon and expand the Dojo community outside Microsoft.
Yue Sheng on ChatOps and Q&A Maker
When I learned about the proposal to add AI elements like AI Bot and QnA maker into DevOps Dojo, I was fully motivated. I have implemented Azure Bot solution for customers before, so it was a great opportunity for me to contribute and learn more in AI space. The scope of the work is basically to enable the Dojo community to ask anything in our community channel supported by AI bots and QnA Maker (an Azure Cognitive Service). Besides providing real-time answers with language supports, the solution should organically improve questions and answers by community.
However, with so many options of available products and scenarios in the Bot solutions, we kept wavering. After some deeper research, I learned more about the functionalities and limitations of various products, so I concluded that the products alone can’t solve our problems. We needed an integration strategy to bring various products to work together to support flow and scale in our community.
With better understanding of integration architecture, we finally decided to implement the solution with Innersource where everyone can contribute to the content with robust governance model. We gradually improved the solution, adding some interesting features such as Text Moderator, which acts as the police to detect undesired text and auto-correct typos. During our PoC stage, we ran into many weird issues that occurred in various environments. Since the Dojo team is a full-stack engineering team, we design, we code, we test, we deploy, and we run all within a feature team.
With all the twists and turns, we launched it on-time. Innersource QnA Bot went public at Microsoft as planned! Integrated with powerful AI capabilities, the solution is designed to help Dojos get answers related to Dojo Content, Readiness, Offerings and Delivery quickly in a conversational style in Microsoft Teams. Meanwhile, it allows anyone to contribute and improve the QnA quality through Innersource in GitHub AE. The improvement and contribution can quickly take effect through automation pipelines. Therefore, the Bot can answer more questions because of community contribution! We also enabled the Power BI Analysis Dashboard which provided insights such as the hottest questions asked, and the confidence level of the answers, etc.
With the guidelines of the Dojo community and experienced architects, we did it! Now Dojo is walking the talks in AI space gradually and steadily! The innovation will keep going and I believe we will have more AI solutions in the coming months and years to solve the hardest problems in DevOps! Through this experience, I feel like I started to think like an architect!
Giulia Cupani on DevOps Dojo Master Classes
About a year ago I moved from Italy to Switzerland, and at the same time a White Belt Master Class was getting started with a Swiss customer, and this was a perfect opportunity for me to help in the delivery while starting my journey in the new country.
I volunteered to help on the delivery of the Master Class, and I have been given the incredible opportunity to lead it from the very beginning, starting with the preparation and setup of the team. I was so excited but also so scared to fail as there were multiple challenges to overcome, first and foremost of which was the pandemic that resulted in everything having to be organized remotely.
We were delivering the first remote White Belt Master Class and therefore had to consider multiple things: How can we efficiently interact with the class? How can we create a smooth experience that makes everybody feel engaged? How can we run the hands-on labs as a team? How can we stimulate interactions? How can we divide the attendees into smaller groups to discuss scenarios and options for the design sessions? How can we enhance the collaboration between team members? Which technical tools can we use? Which tools can the customer have access to? Can the attendees access the lab environment or is there any limitation we should consider? etc.
A couple of weeks before the White Belt Master Class, I attended a Train the Trainer session for the Orange Belt Master Class where I experienced myself the challenges of being an attendee of a remote training. This experience taught me a lot and helped me to apply precious lessons learned to improving customer deliveries. Overall, there were also many advantages in a remote delivery: attendees from different time zones and countries had the chance to attend and benefit from it, which enriched the sharing experience and helped the attendees discover a different way of working within the same company as well as broaden their network. Being prepared for all the above questions and different remote scenarios was not easy, but strong collaboration with the customer and internal team support made this experience a success that led to new customer opportunities and internal readiness development.
I have been leading more remote White Belt Master Classes ever since, but nevertheless, I learned that no matter how many times you deliver it you will always learn something new to improve upon the next ones. What matters and makes a difference is the people and the different experiences they bring and share with the team.
Community, Innovation and Opportunity are the three topics that summarize my adventure in the DevOps Dojo community and in the delivery of the Master Classes. First, this team has given me the chance to prove myself and the opportunity to work on my skills while learning and growing personally and professionally. Furthermore, we are creating incredible innovations that impact our daily jobs, generating valuable outcome that empowers us and our customers to achieve more. Finally, we are a community, a group of people who support, trust, and rely on each other in every situation.
Nicolas Mays on Site Reliability Engineering (SRE)
I was approached about the SRE at Microsoft Services program after my initial onboarding for consulting. I had never heard of SRE before and it was explained to me as treating operations from the mindset of a Software Engineer. The idea of getting to make an impact to the scope of operations with my development background excited me so I quickly got to work and developed the readiness plan for SRE at Services. In SRE, Reliability is a shared responsibility between Operations and Development, which sounds a lot like DevOps. While the concepts of SRE and DevOps were developed by two different schools of thought at roughly the same time, the tagline has been Class SRE implements DevOps to explain the DevOps and SRE alignment. Since SRE and DevOps share the same ideology of cohesiveness between core development and platform operations, it only made sense to start collaborating with the Dojo and begin to include SRE knowledge in the inner sourcing for Dojo White Belt.
As mine and the SRE team’s knowledge grew from consulting engagements, the necessity for advanced SRE topics like Alerting as Code, Chaos Engineering, and fully Automated systems needed to be included with the advanced levels of Dojo. The Design team for SRE decided to pivot on the DevOps Dojo Orange belt Continuous Operations content as SRE lensed, while in parallel the entire SRE team created our proof-of-concept SRE service based on Microsoft’s demo app eshopOnContainers. With the amount of value SRE can contribute to operations, the Dojo’s Green Belt for SRE was born in 2020.
I didn’t know when I started working with Dojo that I’d meet the number of colleagues and be introduced to so many different ideologies. Microsoft is truly a global organization and Dojo is an extension of that with a community that really cares about the vision and mission of DevOps Dojo. While it’s been a lot of hard work and a long road from my introduction in Dojo to the conception of Green Belt for SRE, it’s been a privilege to be a part of this team.
Lena Pang on Customer Delivery
A few months ago, I finished the online course of DevOps Dojo White Belt. At the same time, there was a customer in Taiwan who was undergoing digital transformation and they strived to transform their organizations not only for technology, but also mindset, and establish a deeper understanding of DevOps. This was a good opportunity for me to put my learning into practices into a customer setting.
However, it was full of unknowns, and I was fearful about how to manage DevOps Dojo class room in a workshop setting. The Master Class was planned to be conducted in the form of face-to-face workshops, but was changed to remote delivery at the last minute due to the COVID-19 situation in Taiwan. The materials and delivery experience at worldwide were all in English, but in Taiwan, our native language is Mandarin. Honestly, I was so worried that I would mess up the first remote delivery in Taiwan.
However, the tremendous support from the Worldwide Dojo Community dismissed my fear from day one. During the pre-delivery planning and preparation phase, through the experience sharing of community members, I learned so much about facilitation, logistics, role play, content management, schedule, retrospectives, customer assessment, and more. We also did a lot of language translations of the presentations, Knowledge Check quizzes and the survey. During the delivery, the entire team kept in touch behind the scenes, and continued to support each other. I can honestly say this, not only I have increased my hard skills in technology, but more importantly my soft skills such as facilitation, communication and time management.
Now I not only have a different perspective on DevOps through the real-time learning from the experienced Dojos, but I also have a much better understanding of the customers’ challenges through our discussions. I am extremely pleased that this series of Master Classes, not only brought incredible growth to the delivery team including me, but also brought great value to customers in their digital transformation journey.
I joined Microsoft and focused on application development more than two years ago. It was not until I joined Dojo when I felt how empowering and exciting it was to learn and grow with members from different countries and different professional fields. As a new member of the community, I’m looking forward to bringing more innovation and opportunities from Microsoft to customers in the future.
Part 3: Dojo Team of Teams
What is a Team?
By team, it means a stable grouping of five-nine people who work toward a shared goal as a unit. It should be the smallest entity of delivery within the organization. Allowing teams to grow beyond the magic five-nine people, trust will begin the break down, unsuitable decisions might occur, and the speed and safety of delivery will suffer. High trust is what enables a team to innovate and experiment. But why does the team size matter so much?
Dunbar’s number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships—relationships in which an individual knows who each person is and how each person relates to every other person.
-
- Around five people, we can hold close personal relationships and working memory.
- At around 15 people, we can experience deep trust.
- At around 50 people, we can have mutual trust.
- At around 150 people, we can remember.
Cognitive load was characterized in 1988 by psychologist John Sweller as “the total amount of mental effort being used in the working memory.” This amount is finite. A team’s cognitive load is simply the sum of all team members’ cognitive capacities. When cognitive load is not considered, teams are spread thin trying to cover an excessive number of responsibilities and domains.
Thus, we need to restrict team responsibilities to match the effective upper limit on the cognitive load that a single team can bear. We need to keep teams small, stable, and long lived, allowing team members the time and space to develop their working patterns and dynamics.
Dojo highly embraces Team mindset in our daily culture:
-
- #1: Encourage a focus on team goal and objective & key results.
- #2: Help unblock other team members before starting on new work.
- #3: Mentor and support new or less experienced members.
- #4: Avoid “winning” arguments and instead do A/B testing.
- #5: People who are “team toxic” are not welcome.
- #6: Recognize and reward the whole team, not individual.
What is a Team of Teams?
General Stanley McChrystal provided the following definition of a team of teams:
“Everyone seems to be obsessed with efficiency. However, efficiency is not a synonym for success. The answer lies in becoming more flexible and adaptable. A company has to become a team of teams. What this means is that an organization needs to create multiple teams that communicate with each other, to be effective. This will enable you to be flexible and cope with changes and to achieve success.”
The Dojo community is a team of teams. However how can we enable organic growth (autonomy) while at the same time to achieve a common goal (alignment) in Dojo? This can only be done through transparency and openness of our Mission, Strategy, Taxonomy and OKRs.
Our Mission
-
- Solve the hardest problems in DevOps
- Accelerate DevOps Culture
- Make DevOps real
Our Strategy
-
- Strong Partnership with Product Group and GitHub Engineering
- Interdisciplinary area of Business/IT/Human-centric Design
- Live in Community of Practices and Innersource Culture
Our Taxonomy
-
- 4 Pillars: Culture, Lean Product, Architecture, Technology
- 8 Capabilities: Continuous Planning, Integration, Delivery, Quality, Security, Operations, Collaboration and Improvement
Our Quarterly OKRs
-
- An OBJECTIVE is simply WHAT is to be achieved, no more and no less. Objectives are significant, concrete, action oriented, and ideally inspirational.
- KEY RESULTS benchmark and monitor HOW we get to the objective. Effective KRs are specific and time-bound, aggressive yet realistic. Most of all, they are measurable and verifiable. You either meet a key result’s requirements or you don’t; there is no gray area, no room for doubt.
Dojo Team of Teams
So, within the Dojo Community, we had many value-stream teams who worked on various topics. The team size is about five-ten people. For example:
-
- Dojo White Belt (a team of teams)
- Dojo Orange Belt (a team of teams)
- Dojo Green Belt – UX/Accessibility (a team of teams)
- Dojo Green Belt – SRE (currently 1 team)
- Dojo Green Belt – Secure DevOps (currently 1 team)
- Innersource (1 maintainer team)
- Make GitHub Real (1 engineering team)
- DevOps Lensed Sprint 0 Assessment (1 team)
- DevOps for C-level executives IPs (1 team)
Final Thoughts
This blog is dedicated to our young Aspires, but at the same time also to our experienced Dojo practitioners and master coaches. We like to use this analogy, Aspires are good and healthy seeds, but their growth and potential have a lot to do with the soil – their daily environment. Good seeds in rich soil will bloom, good seeds in bad soil will die. Therefore, the Aspires’ success is directly linked to the nurturing, inspiration, and care of experienced Dojos in our community.
But is experience and wisdom valued in our industries? The reality is that our industries favor youth over elders. If you look at the media and entertainment industry, more celebrities become famous as teenagers or young adults. Sports are the same that star athletes become famous before their twenties. When it comes to the technology sector, experts say if you’re over forty, you’re pretty much over the hill.
If you look at the hiring practices at some of Silicon Valley’s hottest internet and social networking companies, it is hard to overlook the cold hard reality that age discrimination is prevalent. If you are over fifty, you might face some stereotypical assumptions about older workers exist, such as that the relevance and currency of your skills may not be up to par with those of younger employees, the level of compensation for older people is typically higher than salaries younger people seek, their behaviors and attitudes might become rigid and narrow-minded with age, and their energy levels are presumed to be less than that of a twenty-five-years-old. While none of these generalizations are necessarily true for any older candidate, each is a stereotypical assumption about older workers. They are all logical reasons for an employer to fire, or not hire an older candidate.
Unlike any other bias and discrimination against people with a different race, gender, or religious belief, one day we all will be forty, then fifty, then sixty, so it is everyone’s problem sooner or later. Respect your elders and learn from the people who have walked the path before you, because someday, sooner than you could ever imagine, you are going to be old too.
This blog is not intended to discuss this complex issue. However, this blog directly demonstrates the unbelievable benefits Aspires have gained from older people. In fact, this is what Microsoft did so well compared to other high-tech companies. It is very normal at Microsoft to run into technologists who are over 55 and even over 60 on daily basis because Microsoft understands that older employees’ experience, talents, and wisdom can be the greatest competitive advantages in our industry. In our case, the older and experienced Dojos are the healthy and rich soil that allow Aspires to bloom and reach their highest potentials. Who benefits from this? The community, the company, and our customers.
So far in our blogs, we have talked mostly about how we have empowered ourselves to enable DevOps by walking the talk, but the end goal is to empower worldwide customers to innovate at the speed of business. In the next blog, we will discuss customers and trust in our DevOps journey.
Special Dedications
This blog was written and reviewed by the following authors in Dojo Community.
-
- Steven Murawski Steven.Murawski@microsoft.com
- Aakanksha Aakanksha aak@microsoft.com
- Deep Mehta Deep.Mehta@microsoft.com
- Margarita Sanz del Rio Margarita.Sanz@microsoft.com
- Alvaro Guadamillas Herranz Alvaro.Guadamillas@microsoft.com
- Yue Sheng Sheng.Yue@microsoft.com
- Giulia Cupani Giulia.Cupani@microsoft.com
- Nicolas Mays nicolasmays@microsoft.com
- Lena Pang Lena.Pang@microsoft.com
- Pierre Donyegro Pierre.Donyegro@microsoft.com
- Dave Burnison daveburnisonms@github.com
- Kan Tang kan.tang@microsoft.com
The post DevOps Dojo – People & Teams appeared first on Azure DevOps Blog.
