As we wind down our Containers, Culture and DevOps roadshow with Gene Kim, I've had the opportunity to look back at some of the really valuable insight that we've learned from the speakers and customer panels. I wrote about a few of them in: Most Important DevOps Measurement and 7 Habits of Highly Effective DevOps, but I thought it would be even more valuable to share lessons directly from companies that have implemented the technologies, process and culture, and demonstrated significant impact to their businesses.
Before we get to those lessons, Gene and I will be hosting one more (virtual) event on September 19th. You can register here.
#1 - The DevOps team doesn't need to be called "DevOps"
One of the most frequent questions that was asked was, "How do we get our DevOps team started, and who should be on that team?" While there were many suggestions given about the makeup on the team, one great piece of advice was that the name "DevOps team" isn't always a good fit for every culture. At one customer in Southern California (Ten-X), they said that the engineers requested that they not be called "DevOps", because they didn't want the backlash from colleagues that could be perceived as "better" or "more advanced". Instead, they wanted to stick with their existing "engineer-centric" titles and focus instead on how to create a culture and set of processes that would achieve better software delivery. The goals were the same as if they were called "DevOps", but it didn't have the unnecessary baggage associate with it for that team.
#2 - Sometimes Crises Leads to Faster Change
In his keynote at Red Hat Summit, KeyBank's John Rzeszotarski (SVP, Director of Continuous Delivery and Feedback) talked about the outage/crisis that lead to the start of their DevOps journey. While it was a difficult situation to have an outage, it forced them to critically examine their existing environment and processes, and focus on how they could quickly improve to not only prevent another outage, but better prepare the bank for managing the acquisitions that were driving their growth. Their crisis allowed them to get early visibility and buy-in from executive management, which allowed them to make the breadth of changes that were needed to allow them to feel highly confident in shipping software into production during the busiest hours of their day.
#3 - There are Multiple Ways to Achieve the Same Goals
Many customers told us about how they were using DevOps principles to drive better customer-experiences for their customers. In many cases these were tied to mobile application experience, but they could also be driven by web-based experiences. TicketMaster had to scale to manage the demand for summer blockbuster events like Garth Brooks concerts. Still others, like FICO, were able to leverage their newfound agility to launch new products into market segments they had never captured before.
#4 - StoryTelling is Important for Internal and External Buy-In
Throughout the events, we shared data from the DevOps Handbook to provide a level of validation to the ideas that we were presenting. If it can't be measured, it can't be improved. But just as important as the data were the stories that customers told about their DevOps journey. Some of these stories were about how they convinced their teams to make changes at the beginning of their evolution. Other stories were about their successful as they moved from one stage to another. Many people talked about how The Phoenix Project helped them because they could relate their story to a character or problem in the book. Storytelling is an important part of these journeys, as they involve human-focused change, and people need to be able to personalize the change in the context of how it will impact them, as well as being able to share aspects of the story with their colleagues.
#5 - Changing the Face of the Company Doesn't Always Require Massive Teams
Digital transformation allows companies to rethink how they interact with their customers, partners and the marketplace as a whole. We've seen this in planes, trains and automobiles. We see it in regulated industries like banking and healthcare. But not every transformation requires a large team. We learned from Hilton that a small team was able to create their "Digital Key" service, enabled on mobile phones, which radically simplifies the check-in process for visitors to their hotel. As a frequent traveler, I know that they have been many nights when I've arrived at the hotel around midnight and just wanted to get into bed. Digital Key made a good night's rest that much simpler.
#6 - Enabling Self-Service Might Bring the Dev and Ops Teams Closer Together
Automation and self-service are powerful technologies that sometimes worry the IT team. What happens if we give up too much control, or abstract ourselves out of our day-to-day tasks? When FICO enabled self-service access for their Development team on their OpenShift platform, they actually found the opposite to be true. What they found was they the developers actually began to ask more question about how the infrastructure, platform and operations elements worked. Their questions created a new bridge between the teams, sparking a level of curiosity about what was possible, and how new ideas could get codified into new self-service functionality.
#7 - Consider Building Your Teams like the New England Patriots
One of most frequently asked questions was, "What should our DevOps teams look like in terms of skills makeup?" It's a great question, and it involves a number of factors, including budgets, location of the teams, the company culture and overall business mission of the team. Far too often managers get enamored by the "rock stars" and build an unbalanced team that isn't able to learn fast enough (unbalanced), or they aren't able to retain talent long enough (chaotic). I piece of advice I gave was to look at successful teams that have known constraints, such as the New England Patriots. While this advice didn't always go over well in certain cities, the Patriots have created a blueprint of consistent success while managing frequent changes to their team's roster and style of play (see: here, here). The Patriots have shown that you don't need a team full of superstars to win, and that culture often is more important than individual talent.
#8 - How Racing Teams and Web-Scale Companies are Your New Roadmap
Growing up in Detroit, I remember that there was always special attention paid to the racing teams that drove in the IndyCar, Formula 1 or NASCAR events on the weekends. While their cars didn't look like the ones being sold in the local dealerships, their learnings on the track would eventually translate into new innovation that would improve performance, safety or handling on future cars. I was reminded of this as our roadshow took us to the Marconi Museum in Orange County. As I walked around the cars and read about their history, it dawned on me that we're going through a similar transfer of knowledge from the "extreme" groups to the people that manage things on a smaller level. But instead of automotive knowledge transfer, we're now seeing the learnings from the last 5-7 years of the web scale companies getting transferred into the mainstream of technology communities. Kubernetes is a great example of this. Google's DNA, combined with the Enterprise knowledge of many companies, it now available in commercially available software and cloud services. This trend is only expected to accelerate, as open source has now become the defacto center of technology innovation.
#9 - Don't Be Afraid to use Technology Events to Recruit Talent
To say that there is fierce competition for software engineering talent would be an understatement. Every single company that spoke at our roadshow events either began or ended their talk with the phrase "WE'RE HIRING!". And it wasn't just that they were posting jobs on their website, they were actively making sure that they were visible in communities when engineering talent could be found. Whether this was signing up to speak at events (vendor events, community events, small meetups), or just attending event, they were actively being present in the process. TicketMaster spoke about how they open their facilities in California to host monthly community meetups for topics that are important to their projects. Just by hosting the events, they gain proximity to knowledge and talent.
Each Journey is Different
It's important to remember is that every company's DevOps journey is a little different. No two companies have identical cultures, and no two companies have identical business challenges. But the technology best practices are becoming more consistent, and codified into repeatable steps. And the technology is getting more mature and more secure, because open communities are collectively working to solve difficult challenges. I'm sure that I forgot several learnings from this roadshow, but hopefully these nine will help you find a place to successfully start your DevOps journey and find a community to help you move quickly.
Categories
