DevOps culture change fails without grassroots support. Take these practical steps to make it work
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.
Where to start with DevOps culture
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:
For IT pros, the most credible recommendation for a better
approach comes from their peers. Managers, vendors, and technical
journals are all good sources of information, but a peer recommendation
carries special weight.
Developers are biased to adopting solutions that make their immediate lives easier.
Based on what we’ve observed in DevOps environments (including within our own company, Datawire), consider these steps to nurture a DevOps culture:
1. Start small and solve specific, concrete problems
Perhaps it’s an engineer getting paged too frequently. Perhaps an
engineer is trying to get a database to be more resilient under an
enormous load. Managers, ask your engineers what are the most annoying
or painful problems: You’ll usually get an earful. Start there.
2. Support the problem-solving engineers
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.
3. Create forums to share successes
Internal DevOps Days, lunch-and-learns, regular engineering meetings,
and blog posts are all good ways to share successes and create
awareness.
4. Make time to help spread the solution
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.
5. Encourage engineers to engage outside your organization
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.
No comments:
Post a Comment