You probably think I'm going to talk about all the reasons why you should use open source tooling as the foundation for an effective DevOps culture in your organization, but that's not what this is about. Not to marginalize the complexity of the challenges faced by the team I work with, but I have confidence that the engineers are going to figure the tooling part out. Believe it or not, the daunting part is wrapped in cultural change.
I have spent a significant amount of time reading about cultural change, what you need to have an effective DevOps community, how you build high functioning teams, and asking the question, "How do I DevOp?" The ideas I've read have given me a few new things to stick in my tool belt. However, nothing has resonated with me as much as this:
The open source way is...
Open exchange
We can learn more from each other when information is open. A free exchange of ideas is critical to creating an environment where people are allowed to learn and use existing information toward creating new ideas.
Participation
When we are free to collaborate, we create. We can solve problems that no one person may be able to solve on their own.
Rapid prototyping
Rapid prototypes can lead to rapid failures, but that leads to better solutions found faster. When you're free to experiment, you can look at problems in new ways and look for answers in new places. You can learn by doing.
Meritocracy
In a meritocracy, the best ideas win. In a meritocracy, everyone has access to the same information. Successful work determines which projects rise and gather effort from the community.
Community
Communities are formed around a common purpose. They bring together diverse ideas and share work. Together, a global community can create beyond the capabilities of any one individual. It multiplies effort and shares the work. Together, we can do more.
That is how you get an effective DevOps culture. You embrace the open source way.
If you didn't fist pump, remember a job you have had in the past where you felt like this guy, and then read that again.
Open exchange, participation, community
My career before Red Hat was filled with statements like "just do your job" and "that's just the way it is, you can't change it." I have viscerally felt the horrible feeling of having to tell someone that they couldn't have their idea, not because it wouldn't solve many problems, but because they didn't know the right people or know the best way to get their idea across.
When you have an open exchange and everyone is encouraged to participate:
- People talk to one another and build off of each other’s collective experience.
- People earn each other's respect while working together.
- People are less likely to say, "It's so and so's job, not mine," when they know and respect each other.
No team is going to believe they are in an optimal working environment if someone is saying, "Work together or else." Yes, they will work together, but wouldn't you prefer to give them a reason to want to work together? The reason can be as simple as helping two individuals connect on similar interests, or as hard as getting teams with a long-standing history of disliking one another to work together. But the key element here is a path to empathy and having respect for those you spend your week with. At the end of the day, you need to foster an environment where it is OK to have an opinion, OK to have an idea... OK to share.
Even on the team I'm working on, where the values of the open source way are individually embraced, we have to work hard to continue to cultivate that global sense of community and collaboration. Even at Red Hat it is hard. I strive on a daily basis to provide as much visibility into what our team is working on regardless of how trivial it may seem. The result of this? People are sharing their ideas and helping to build something we can all be proud of and support.
Rapid prototyping and meritocracy
A brilliant thing happened very early on with the team of engineers I'm working with; they reminded me about the importance of just getting something done. We spent a good bit of time trying to muddle through the mountain of things we could work on and the output of that? Well, frankly—it was a lot of talking.
Being able to show someone what you are doing, and receive feedback on that thing, is so much more satisfying than the talking. Rapid prototyping? Getting to see the code, instead of an idea disappearing into a requirements hole and resurfacing at QA, is so satisfying I can't shout about that enough. In my past experience with closed source projects, I haven't seen code delivered, input received for changes, and subsequently modified very quickly. So, that continues to be transformational for me.
Don't get me wrong, this is not an easy thing to master. Early on the team made a technical decision to move forward with a custom application that could provide certain system information (like software versions running) without requiring root access to servers. I understand that there are tools that already do that, but the team wanted something quick to ease the pain. After we were done, we agreed we would start looking into longer-term solutions to help. We are still feeling the pain from that decision; meritocracy is in full-on mode here where this project is concerned, and no one is shy about sharing the details about the impact it has had on their servers. However, I can still say the work was successful because at the end of the day it delighted the people who needed it the most, and it certainly gets people talking to me.
Consider this
How hard do you think a DevOps transformation will be if employees don't feel comfortable enough to share ideas, are being told not to collaborate because it isn't their job, or it is implied that their financial well-being is wrapped around performing one function and there is no emphasis placed on whole systems thinking?
The open source way isn’t an easy button for success. However, what it can do is provide a set of values for an individual and a group to follow that can set your organization on the path towards an effective DevOps community. Do me a favor and go back and read those values again. Are you and your organization open enough to embrace the open source way?
15 Comments