Can you end meeting dread by having stand-up meetings? IT leaders say it's not as hard as you'd think - and delivers big benefits.
Culture shifts such as DevOps take a lot of hard work, because you need every single person to buy into the new culture. The most successful adoptions we've seen of the DevOps mindset start with an organic, bottom-up approach.
Start with a concrete, immediate problem. For example, at many cloud software companies, engineers are paged when an error occurs. Since no one enjoys being paged, the engineers who are frequently paged are motivated to figure out ways to get a more restful night's sleep. At one organization we worked with, an engineer realized that pages (errors) correlated with new releases of the application. So she decided to introduce “canary deployments:” running a new version with a small percentage of real traffic side-by-side with the old version and gradually increasing traffic over time. Other developers in the organization saw the success of this approach and adopted it for their own services.
[ For more advice on culture, see our related article, DevOps requires dumping old IT leadership ideas. ]
At this company, a developer – in search of more sleep – introduced an operational best practice that an organization then adopted.
We’ve seen this pattern repeatedly. At its core, it comes down to recognizing two facts:
Based on what we’ve observed in DevOps environments (including within our own company, Datawire), consider these steps to nurture a DevOps culture:
It’s essential to let the engineer who is experiencing the problem personally try to solve it. If that engineer doesn’t have the know-how or skills to directly solve the problem, give him or her the right resources (other people, training, time) to tackle the problem. The engineer who is closest to the problem will be able to validate that the solution actually works.
Internal DevOps Days, lunch-and-learns, regular engineering meetings, and blog posts are all good ways to share successes and create awareness.
The engineer who built the canary system wouldn’t have been able to drive adoption if she hadn’t been given time to document her approach – and coach other teams through it.
Valuable outside interaction happens through conference talks, speaking engagements, or public engineering blogs (e.g., the Yelp engineering blog or the Lyft engineering blog). External validation and recognition of an engineer’s work helps with internal advocacy (wow, all these other engineers love this person’s work!). It also gives the engineer a different type of personal satisfaction.
Cultural shifts are not successful unless they’re internalized by the entire team. So, think carefully about how you nurture grassroots efforts when adopting DevOps in your organization.