How to turn DevOps fakers into believers
Source – enterprisersproject.com
We recently shared some strategies for sniffing out DevOps fakers in your recruiting and hiring. By DevOps fakers, we mean candidates whose qualifications for a DevOps role might be more hype than substance.
But what if the “faker” is already on your team? Moreover, what if they’re faking not their technical skills or other qualifications – you hired them, after all – but their commitment to your organization’s ongoing DevOps transformation? They’re talking the talk but not walking the walk, perhaps. Or maybe they even balk at the talk.
A healthy DevOps culture depends on team members’ commitment. If you have too many people who are quietly hanging on to their monolithic ways – siloed thinking that produces conflicts and blame; waterfall development practices that slow the delivery pipeline to a trickle; fear and loathing of automation, and so on – then your DevOps culture is at risk.
That healthy DevOps culture is fundamentally about continuous improvement throughout the team. Everyone has room for improvement; some people might need a bit more help than others, and it’s your job as an IT leader to help them get it. We asked several DevOps leaders and practitioners for advice on doing just that. Consider these five practical strategies for converting your DevOps fakers into true believers:
1. Tailor strategy to the person’s level or role
For Anders Wallgren, CTO and co-founder at Electric Cloud, coaching a DevOps laggard starts similarly to any other scenario that requires your active leadership. First, you need to take into account the person’s specific role and level in the organization.
“A VP of engineering who can’t break out of the waterfall mentality is a very different problem than an individual contributor a few years out of school who needs coaching on how to write testable code,” Wallgren says.
The former scenario is a more urgent issue that you’ll have to address on a case-by-case (and hopefully limited) basis. The latter scenario is more likely to surface, and it’s also not usually a fire-alarm situation.
Rather, it’s a matter of helping people learn and understand what they don’t know, especially if they’re less experienced or if they’re transitioning from a legacy organization into a DevOps team. A strong DevOps leader makes DevOps processes, tools, and culture a part of someone’s ongoing professional development and goals.
“In my organization, we try to get every dev up to speed on DevOps as they progress up the career ladder,” says Nate Berent-Spillson, senior delivery director at Nexient.
It could be that an early career developer, for example, isn’t “faking it” but simply has significant blind spots in their knowledge of how software gets operated. Berent-Spillson says a dev might literally not know how their code gets deployed or runs in production, for example, or they might not know networking basics like DNS, TCP/IP, or load balancing.
“There’s a lot that I sometimes take for granted on the infrastructure side that many developers don’t know,” he says.
2. Make DevOps changes more digestible
Someone who appears resistant to your DevOps transformation might actually just be overwhelmed by the scope and pace of change. Break the issues down into smaller parts – think of it like a microservices architecture for DevOps culture – to help them get on board.
“You have to meet them where they’re at, and give them good solid working examples,” Berent-Spillson says. “Breaking down the problem space into individual slices, and having them solve each one and incrementally to build a more complex pipeline. How do you read and troubleshoot logs? How do you reproduce a failure locally first?”
This might be an especially important strategy in organizations that are shifting to DevOps from a legacy model; these teams have to keep the lights on while they navigate this significant change.
“In most IT and dev shops, individuals and teams are barely treading water with current initiatives and addressing existing technical debt,” says Chris Ciborowksi, CEO at Nebulaworks. “Finding time to pick up new something new, be it tools or processes, and get them integrated with a high degree of success is unlikely and they know this. As such, barriers go up.”
One tactic for addressing this challenging scenario, according to Ciborowski: Identify some existing piece of the team’s workload that isn’t tied to an immediately critical business goal or outcome, rip it out, and replace it with a minimum viable product (MVP) approach.
It should be viewed not as a “final-state” project, but a first attempt that can then be optimized, iterated, and – perhaps most importantly – learned from, as part of the team’s DevOps transformation, Ciborowski notes. This can lead to the kinds of early wins that build teamwork and traction that breaks down barriers and converts people into DevOps believers over time.
3. Align and optimize incentives among teams
Too often, siloed IT teams have some common goals but conflicting incentives to achieve those goals. If those are still in play, they’re likely root causes of people faking their DevOps enthusiasm while remaining stuck in old conflicts.
A common example of this kind of conflict is when developers are too narrowly focused on their time to delivery, while operations pros are solely concerned with systems stability and uptime.
“If these cross-functional teams and their management are using more business value delivery-focused ways of measuring their performance, like feature lead time, mean time to recovery, and deployment frequency, they’ll have a common definition of success,” says Justin Rodenbostel, VP, open source application development at SPR. “When that common definition exists, teams will start to experience success together, which helps remove barriers to adoption and gets the team moving in the same direction.”
Rodenbostel also notes the importance of IT leadership’s unwavering support during this transformative phase: If people are getting mixed messages from you, they’re less likely to believe in the long-term vision.
4. Give people more input and ownership
If you’re struggling to get some people to buy into DevOps, you might need to give them more power to buy-in: As in, more ownership and authority over their roles and responsibilities.
“Incentives can be good motivators, but without getting buy-in and creating a sense of ownership within the team for related goals, they can fall short,” Rodenbostel says. He offers a few tips for creating this greater sense of ownership:
- Let team members help define their performance goals and incentives together.
- Make sure early progress is attainable. (See the “make it manageable” section above.)
- Make sure that progress is measurable and avoid “success theater.”
5. Play the DevOps long game
We mentioned at the outset Wallgren’s perspective that converting your DevOps skeptics into believers isn’t all that different from other situations that require your leadership and guidance.
“It’s no different than coaching or mentoring in any other scenario,” Wallgren explains. “Focus on outcomes, learning, communication, openness.”
Indeed, while someone might indeed be “faking” their commitment to DevOps, it’s important to consider the role you play in that. Are you really offering the kind of unwavering support that Rodenbostel advises above? Are you giving people ownership and making things manageable for them?
DevOps doesn’t really have a finish line; some organizations might have a more robust or mature DevOps culture than others, but they’re never “done.” They’re always learning and getting better, and that’s the most powerful tool there is for building and renewing a successful DevOps shop.
“Fostering a culture of continuous improvement is extremely important for long-term success in adopting DevOps,” Rodenbostel says. “Part of that is creating an environment where individuals and teams can learn from each other and grow together. Organizational leaders must ensure that there are opportunities for this to happen and continue to support this type of collaboration.”