I’ve always enjoyed the cultural aspect of the DevOps movement just as much as the technical tooling side. You’ve likely heard that DevOps is not just a role or a toolset, but an actual movement or a culture.
In this post, I’m going to dig into the idea of a DevOps culture and explain why it is fundamental. I’m going to highlight why a DevOps culture and the idea of operating in a “State of Grace” share so much in common. In this case, when I say DevOps, I mean both the practice of DevOps and the products that the practices of DevOps create. Finally, I’m going to dig into what a successful DevOps culture aiming to operate in this graceful state looks like, examining what I’ve seen work and what I’ve seen fail. Alright, let’s go.
Read the “State of DevOps” Reports
First things first, you owe it to yourself if you are working in any industry, as an individual contributor or in a management capacity, to read some literature. Stop right now and go read one of the State of DevOps Reports. Both Google and Puppet publish a version. I do call it literature purposefully. I think I might have heard my colleague Jamie Phillips use that term, pointing out that the DevOps reports are sourced as well as any academic paper. You see, both reports present empirical evidence that the most successful companies across industries are embracing DevOps and that their peers who are not are being left behind.
You may have noticed the tooling side of DevOps receives plenty of attention nowadays. Spoiler alert: it’s because tooling can be easily attached directly to you and your company being sold DevOps branded products. Sprinkle some DevOps on any problem with <insert magic toolset here>.
Let’s stop right there and acknowledge that tooling is critical in any digital or DevOps transformation. No amount of good feelings, culture, or best intentions in a vacuum will ship your software, tune your query, or make your boss happy. Not coincidentally, DevOps branded out-of-the-box tools ill-fitted into archaic systems will not make your technical debt disappear, or improve shareholder value. Pay attention to the data in the reports and you will see that successful DevOps transformations happen holistically and iteratively, eating the elephant one bite at a time, solution by solution.
In fact, the people at the end of the value chain for what you are delivering probably don’t care if you’re practicing DevOps, what tools you’re using, or if your culture sucks. You see, it’s not quite common knowledge yet that DevOps practices are empowering the most successful companies. But the users at the end of these value chains—even if they have never heard the term DevOps—do live in modern society, so they are starting to expect that their experiences when interacting with software and technical solutions will be easy-to-use, seamless, routine, on-time, continuously improving, and 100% supported cradle-to-grave.
I would venture to say that your customers are fully expecting graceful experiences. If you’re not training your customers to expect as much, your competitors will be.
We’ve established that DevOps is fundamental for the modern business because end users’ and customers’ expectations demand the value it delivers. We know that we can’t do it with tooling or culture alone.
So, What’s Fundamental to DevOps?
The culture is fundamental. Every DevOps project or digital transformation initiative you start on, every bit of toil you banish or automated process you implement, builds on the foundation of your company’s culture, full stop.
Before we go further, let’s do the required this-is-a-DevOps-blog-post unpacking of what DevOps is. As I live and breathe in a .NET shop, I will use Microsoft’s definition. I like this definition, and if you’ve been following Microsoft’s trajectory with .NET core, VS Code, ADS, and Azure, you’ve seen them walking the walk and delivering high-quality products at speed.
Microsoft’s Definition of DevOps
DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.
Let’s deconstruct this and cherry-pick some key words out:
- People
- Process
- Products
- Value
- End users
Guess what? It seems most of these concepts are more people- or humanity-focused than tooling-focused. Out of those five concepts, only one (products) is arguably tool-centric. I’ll pause here for a moment to have that mental argument with myself (and possibly you).
Yes, any given product is just a tool, but a good product—a really good product—is more than that.
- A decent product might be useful under the right circumstances.
- A good product can transform a process in many circumstances.
- A great product can consistently save you and your team time in an even broader set of circumstances.
- A truly great product has a bigger impact. A truly great product can actually make your life better every time you interact with it.
A truly great software product can actually make your life better because it introduces a momentary state of grace into your life.
Grace you say? That might be a bit much for some people. Give me a chance and I’ll break down what I’m after. While we can acknowledge the etymology of the word “grace” in theology, I want to focus on a couple of the other uses, definitions, and quotes to illustrate where I’m going.
Grace
I bet you didn’t expect to see a Pinterest quote about grace in a “What is DevOps” post!
I’ve also heard grace described as not simply an absence of fear, but a presence of trust. Several definitions also focus on acceptance over resentment. You see, grace is hard to pin down. It means a little something different depending on the context and your own perspective. Much like grace, the idea of DevOps is not easily constrained or boxed in. And much like grace, DevOps is explained just as much by describing what it’s not, as what it is.
Back to our original definition of DevOps for a moment. Let’s go ahead and rightfully concede that a great product is human-centric and bring it into the fold. You see, all the descriptions in Microsoft’s definition of DevOps (people, process, value, end users, and product) are ultimately about actual people. They’re not about tools.
Let’s go a bit further and say that these DevOps tenants are not just about an ordinary state of people. Those concepts actually capture a loftier goal of having people operate in a better state, in a graceful state.
State of Grace
Let’s revisit our definition of DevOps again and talk through some patterns and anti-patterns as it relates to a company’s culture, its people, and the concept of a graceful state.
DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.
People in a graceful state share ideas freely because it’s safe to do so, with some healthy awareness of the possibility of failure, but with agreed-upon guardrails to protect them from absolute failure. Conflict exists, but it’s a conflict in which the best ideas win. My colleague Melissa Connors recently gave a great internal S1 Academy presentation on psychological safety that crystallized this concept for me.
People in an ungraceful state are afraid of new ideas. New ideas bring conflict with pre-determined outcomes, and when a new idea is generated, it’s siloed, shamed, stolen, or polluted. Conflict is won purely in the politics of hierarchy and favor trading. Allow your people a free exchange of their creativity by making available and encouraging the use of platforms that allow the sharing of new ideas and information, such as internal wikis, Slack channels, peer-led training, and town halls. Reward and incentivize participation. Be pragmatic when bootstrapping a culture change. It needs a safe space to grow.
A DevOps Mindset
A company can’t buy DevOps, but you can encourage and grow a culture of autonomy and solution creators. Empowering people reflects a company’s intent to foster trust up and down the chain of command. Engagement will breed from this culture of autonomy. Engaged people operate with intent, creating just enough process to be successful together. Operating with intent is a graceful state for your employees.
Engaged people exposed to a DevOps mindset adopt it. Engaged people acknowledge, reject, and then banish toil through their own creativity, not due to edict. You see, engaged employees can only exist if leadership—from the frontline supervisor to the board—welcome criticism, hide no sacred cows, and admit mistakes. Pattern the behavior you expect.
DevOps tools or processes that are handed down from above and lack the context of how people and teams operate ultimately fail. Authenticity isn’t for sale at successful companies. Un-engaged people and teams will accept broken processes, nod, smile, and move through the day without intent. Make it a standard practice that teams (at the individual contributor level) have the power to make decisions about what processes and tools they adopt.
It’s a false dichotomy to say that a company is or isn’t doing DevOps. It’s not an either/or system. Even the most successful companies have pockets of failure. Even the most graceful stumble. Acknowledging the areas where you’re coming up short and working toward improving them is fundamental to the process! If you feel like you’re starting from nothing, you might be. Remember to eat the elephant one bite at a time, vertical slice by vertical slice.
As an Individual Contributor or Front-Line Supervisor, Own the Culture
If you’re in an individual contributor role or a frontline supervisor, guess what? You have responsibility for the culture. Start by understanding the difference between your area of concern and your area of influence. Focus on the solutions in your area of influence over the problems in your area of concern.
Of course, there are problems. Problems are why jobs exist. Joining a chorus of people complaining about problems takes zero unique talent. Fight the urge. We all need to vent sometimes; it’s human. Complain up. Don’t complain down. Complaining down is not graceful. Frontline supervisors complaining down will poison your culture quicker than anything else. Your employees’ areas of concern should be smaller than yours, and their areas of influence even smaller. Consistently dishing out your area of concern in a negative fashion can erode any sense of ownership your team has over their own area of influence. Don’t rob them of their power of intent.
Think about solutions in your area of influence. Find a broken process and go back to the problem for which it was originally created. Chances are the fidelity of the problem might not even be clear. Work to understand the problem, then solution a process that’s simply better than the current state. Don’t just automate the broken manual process! If the process is full of toil, it’s a great goal to get to the point where you can script it, automate it, document it, and\or find a tool that’s a good fit that will save you time. But before you do that, allow the time and mental energy to decompose the problem before just automating the legacy solution.
If the process involves your team at large, evangelize for the change. Come to a consensus with your colleagues and find allies by showing them the time savings and quality of life increase. It doesn’t have to be perfect, it just needs to be better! On that note, not everyone always needs to, or will, buy in. Sometimes you will reach a consensus, but not always. In the absence of better data, weigh action over inaction. In a healthy culture, a “not best” idea will be iterated on to become a better idea and then eventually become the best solution. Work toward perfect, but acknowledge and implement progress. Expect to see continuous delivery of value.
If You’re an Executive, Protect the Owners of Your Company’s Culture and Set the Example
If you’re in a director or executive leadership role, be someone’s champion. Roll up your sleeves and protect the risk-takers from the fear of failure. Educate your Director, VP, and C-level peers about the state of DevOps. Practice what you preach by acknowledging not only what is going well for you, but what is not. Talk about your failures, make them real, be vulnerable, and earn a reputation of authenticity. Budget time and mental energy toward continuous improvement projects.
Invest in tools that allow you to communicate transparent goals company-wide. Align your departments to own the goals as partners, and leave room to adjust along the way. Be as transparent downstream as is practical regarding business decisions driving tech. Employees get it, just give them a chance. A pivot because the boss said so usually sucks, but a pivot to solve a customer’s problem is the most well-understood pivot in tech.
You may find success using a Center of Excellence model. However, long-lived swat teams can be an anti-pattern or a choke point for approving ideas, thereby deteriorating the creative capacity that exists outside that special team, and turning that special team into a classic bottleneck. As a leader, you have unique visibility and influence over the entire value stream. Aim to make your Center of Excellence the culture itself. If your culture is treated as the foundational ingredient, it will naturally protect itself and will consistently produce positive results.
Wrapping It Up
All right, that’s all I have for now. I hope you found it valuable! If you want to talk DevOps (tools or culture), feel free to send me an email or connect with me on LinkedIn. I could credit a lot of people at the individual level for many of the ideas in this post, but I think it’s fitting to just credit the culture at SentryOne.
I’ll close by restating that a successful DevOps culture and the idea of operating in a “State of Grace” share a lot in common. Remember doing DevOps isn’t really about using DevOps tools; it’s about investing in your company’s culture. It’s about your engaged employees (people) operating with autonomy and intent under processes that they craft and own, and continuously creating products with real value for your end users. Empower your employees and they will create and share those momentary states of grace with your customers—that is DevOps.
