We all live in the culturescape. Our beliefs, speech, and behavior patterns are all shaped by the environment we choose to stay in. Culture creates commonalities that unite us and allow us to work collectively towards mutual goals. In business, we can think of it as a predominant mindset that elicits collaborative behavior. It is why top executives are so obsessed with communicating the company’s core values and hiring for culture fit. Culture is a force to be reckoned with.
In the previous article, I defined DevOps as an intersection of culture, processes, and tools, but just briefly covered DevOps culture as such. It is now time to dive deep into this topic and discuss the most critical factors that define DevOps culture-wise. I’m also going to point out some of the pitfalls that you need to be aware of when trying to implement DevOps culture in your organization. Cultural transformation is no joke, as it requires people to change the way they think and act.
Towards the same goal – we’re all in this together
Working together to provide business value to your customers is the single most important goal every business should be obsessed about. It is also the cornerstone of DevOps culture. Back in the old days, developers strived to maximize feature releases, while operations people were all about system’s stability. These opposing incentives created unnecessary tensions and had an impact on software quality. Instead of this false dichotomy, DevOps culture cares about how real users experience your software. Developers, QA, operations people should all be in line with this, and every incentive in your organization has to serve this cause. The role of top executives cannot be overstated in managing organizational change. People need to have a strong cause to start behaving differently, so it's essential to continuously communicate it though all available channels.
DevOps culture promotes collaboration above all else. Of course, this is easier said than done. You cannot use a top-down approach to force people into cooperation. A better idea would be to find colleagues who believe in DevOps and work with them to spread the culture within their teams. It is also worth to set-up a robust communication channel between your teams to facilitate collaboration. There’s nothing as near and dear to engineer’s heart as live chat so I would stick with that. Don’t forget live meetings as well. DevOps is very dynamic, and meeting our colleagues for a casual face-to-face meeting helps everyone stay on the bleeding edge. Try having them at least once a week.
Moreover, leveraging goal management software can be a game changer for tracking progress and ensuring that every team member knows how their work contributes to the company's objectives. Bringing all your goals into one platform facilitates transparency and keeps everyone focused on what matters the most.
Top challenges:
- No approval from top executives. It’s a strategic decision to implement DevOps culture, which won’t last unless you ensure you are in-line with upper management in your organization.
- No buy-in from people involved. DevOps culture should be instigated from the bottom up just as much as from the top down. Make sure you have DevOps evangelists in different teams to facilitate the adoption.
- The false dichotomy of incentives. You shouldn’t have competing goals for different teams since that creates misalignment and artificial friction between teams. Instead, motivate your teams by how well they contribute to making the customer’s life better.
Bridge all silos – sharing is caring
DevOps culture bridges all silos between your IT teams from idea inception to full production scale. To do so, organizations make software creation as transparent as possible. Everybody is invited to the party and has full visibility into every stage of the process. Software planning, building, testing, deployment, and improvement require everyone’s participation. Having diverse skill-sets around the table at each stage helps businesses avoid technical debt and boost employee engagement. You know what everyone’s working on and how high is the priority of their current task. It sets your mind to providing real business value to your customers, rather than merely manufacturing software features.
DevOps teams focus on competencies instead of roles. Roles are rigid and clunky, while competencies are fluid and adaptive. It is the reason why high-performing DevOps teams have a robust knowledge-sharing culture and include well-rounded IT professionals. Dev and Ops should have face-to-face interactions to learn new skills. You may use job shadowing, pair programming, or developer rotation for that. Don’t forget to have constant scrum meetings and project retrospectives to foster collective discussions.
Knowledge-sharing improves when your teams start using common DevOps tools. At a minimum, there should be access to code, logs, and postmortem reports for everyone in IT. This way, your team members can think holistically about software development and incorporate cross-functional wisdom into their everyday work.
Top challenges:
- Fear to lose power and authority. There may be some “superstars “in your company who treat knowledge-sharing as a threat to their position. Try to help them understand the limitations of such perspective and the benefits of DevOps culture.
- Fear of public speaking. Engineering is often seen as a job for introverts who may not be enthusiastic about public speaking. Try to reduce this fear by creating small teams, where everyone feels comfortable and knows each other well.
- Excessive bureaucracy. Don’t get too formal in your collaboration. You need to find the golden middle between chaos and structure in DevOps.
Autonomous teams – with great freedom comes great responsibility
Small, multi-disciplinary, loosely-coupled, product-centric teams are what makes DevOps culture so effective. An ideal DevOps team should be small enough to be fed with two pizzas. It would consist of developers, operations engineers, QA specialists, and project managers, all tightly aligned with the same goal. The work is done in small batches to improve end-to-end delivery of customer value. Any friction is eliminated along the way. Individuals are empowered to make everyday decisions that speeds up their work even more. When your teams have diverse skill-sets and all the data they need, people form well-rounded opinions, and it gets harder to go off-course.
Autonomy is freedom that requires a strong sense of responsibility. On the team level, DevOps culture holds everyone mutually accountable for how users experience your software. As Nicole Forsgren put it in her book Accelerate, DevOps teams should be evaluated by four KPIs:
- Lead time for changes – the time it takes to go from code committed to code successfully running in production;
- Deployment frequency – software deployment to production or an app store;
- Time to restore service – mean time to recovery (MTTR) your services;
- Change failure rate – how often deployment failures occur in production that requires an immediate rollback.
Moreover, autonomy in DevOps and international hiring empowers individuals to make decisions faster. Diverse teams with global talent offer unique perspectives. Everyone, regardless of location, owns their code, ensuring seamless operation.
Nevertheless, individually, you are still responsible for the piece of code you have released. The rule of thumb is “if you built it, you run it“. If your build fails, you have to fix your code as soon as possible to avoid jamming the whole CI/CD pipeline.
Top challenges:
- The structure over the community. Often people get too much focused on processes and workflows, rather than building a community of collaboration. If you do the culture right, everything else follows.
- The word game. You cannot merely name someone DevOps and hope they would somehow change. Instead, you should group people with different skillsets and assign them a common goal.
- Lack of trust. Managers are sometimes tempted to micromanage the hell out of people. Just trust your teams to do the good work and let them share their progress.
Failing quickly – a scientific approach to better software
DevOps movement raises a simple question. How can you build better quality software quicker? A software system may be thought of as an ever-changing organism. Especially today, if you are building a modern cloud-native application, there’s a horde of loosely coupled parts interacting with each other. So how would DevOps help you deal with this challenge?
Automation is an ultimate prerequisite for building up DevOps culture. Your tests, builds, deployment, environment configuration, monitoring, and even documentation can benefit from automation and the right DevOps tools. In addition to saving your time and reducing failure rate for tedious tasks, automation also lets you fail quickly. Such a mentality is essential in DevOps culture since it liberates your team to experiment more and test ideas at a much faster pace.
DevOps helps you integrate the scientific method into your workflow, allowing IT engineers to leverage the very same mindset that made sciences flourish throughout the last few centuries. First, you observe. In business, it means you are monitoring how your customers use your software (quantitative observation) and making proactive efforts to assess their opinions (qualitative observation). Next, you can make a calculated hypothesis that is based on your observations. For instance, we believe that DevOps team leaders (customer segment) want to quickly see their team members’ activity on a cloud platform (product/feature/service) because it helps them maintain accountability when promoting DevOps culture in their organizations (value proposition). Your hypothesis needs to be verifiable and have a measurable conclusion, like “we expect 30% of our user base to try this feature in the first month with a 60% adoption rate after the first 3 months have passed. Then you do your programming magic. The aim is to test your idea in production as quick and as cheap as possible, so you develop in bite-sized chunks and make frequent releases. If your code build fails, fixing it becomes your primary objective. And if your feature fails, you should remove it from your solution whatsoever. Remember, DevOps is all about continuous value delivery – you don’t want to carry waste that is a downer to your customers.
Top challenges:
- Over-automating things. If your process is flawed, automation only helps you make your faulty process happen faster. You should first cherry-pick the processes that work for you, taking into consideration what’s unique in your business.
- HiPPO (highest paid person’s opinion) effect – when there is a lack of data, and a decision needs to be made, the group often defers to the judgment of the HiPPO. People are prone to authority bias, which can lead your organization astray. Start with intuitions, experiment, and make data-driven decisions instead.
- Working around the failure – don’t delay failures or try to fail silently. If you fail, you fail – that’s your moment of truth. It helps you improve in the long run.
Experimentation-friendly environment – fail fast, learn faster
After you’ve created a robust hypothesis-driven development culture and the feedback is pouring-in, it is the time to make sense of your data. After each experiment, you want to assess what you have learned. You may want to adjust your software feature, hypothesis, or your key assumptions. DevOps culture celebrates failure as an opportunity to improve. If you make mistakes faster than everyone else, you also innovate more quickly. This is how DevOps culture adds up to the competitive advantage of your business.
For this process to work well, you need to build a blame-free culture in your organization. People are often prone to scapegoating, so you need to start rewarding failure as a way of learning. For instance, you may create a visual board for the most significant failures that are also your biggest lessons. It’s also a good idea to have retrospective reviews every few weeks, where teams could share their newest insights and learn from each other. In doing so, you have to be blame-aware and do not allow pointing fingers at each other. Remember that everyone in your organization is in the same boat and share the same good intentions towards your business success.
Having a no-blame culture removes friction, but it is not sufficient for the DevOps culture to fully flourish. To experiment a lot, you need a stream of creative ideas. The most impactful thing here is to employ the collective intelligence of all your team members. Everybody should be allowed to put their ideas on the table since no single person is smart enough to drive a company alone. The more ideas we have, the better our experiments become. To build that creative muscle companies can also dedicate some slack time once a month when team members are be paid to learn and build anything they like. If that’s not enough, you can organize a company-wide event like a workshop or hackathon to create a lasting experience of creative joy for your colleagues. All in all, creativity is a muscle that requires a positive environment and needs to be exercised continuously to bear fruit.
Top challenges:
- The blame game. Even though you may have autonomy and get praised for your wins, people may still be inclined to blame you for your mistakes. Acknowledge your failures and present your colleagues what you have learned from them.
- Fear of failure. You are going to fail a lot, but that’s part of the game. It is necessary to change the mindset from creating perfect software to continuously providing new valuable features. Reward the most critical lessons learned in your organization.
- Velocity above feature impact. Your team may get easily tempted to coin new sexy features without measuring feature impact. Avoid this, since it makes you product-centric, and leads to losing sight of your customers.
On a final note
DevOps is often considered primarily as a culture, not without reason. Collaboration, transparency, knowledge-sharing, experimenting, and working towards a single goal requires the right attitude from everyone in your organization. If you get it right, everything else follows, because, by the end of a day, good culture fixes broken processes.
