This is the second post in a series to help your engineering team transition into a DevOps organizational model. Here we’ll discuss how to start breaking down silos in your organization. Click here to start at the beginnings of the series, Why You Need to Establish a DevOps Culture.
Introducing a DevOps culture to your company and breaking down silos isn’t like how you may make other changes in your organization. You don’t submit a proposal and neatly weigh the pros and cons. If you do, you will probably meet a lot of resistance. Obtaining buy-in from business stakeholders can feel nearly impossible. But this doesn’t mean you shouldn’t advocate for change, you may just need to be stealthy with your approach.
You’ll need lots of patience if you commit yourself to changing your peers’ mindsets. To do so you will need to start with forming strong relationships and teaching concepts before introducing them to the tools needed for testing and configuration management.
Start with What You’ve Got
People are naturally resistant to change. To business leaders, change sounds costly. To others, change feels disruptive. Your best bet is to nurture your company’s pre-existing culture. You will need to feed your company’s own values back to them and determine what everyone really cares about.
Start by assessing your culture. Does your company focus on the customer or is it really all about the money? Are you laid back or do you have a regular ol’ corporate environment. Do your office parties have red solo cups or crystal champagne flutes? Are your offsites playing paintball or hitting a round at the country club? It’s important that you take a step back and figure out how to transition to a DevOps model with your current culture. Change doesn’t happen overnight and expecting your company to rapidly do a complete 180 will be futile.
After you have assessed your culture, start reinforcing the parts your teammates like and the parts that align with your ideal DevOps culture. Next, get everyone participating in your culture. Hold events for cross-functional teams to participate in. Go bowling together, grab a beer, mix up teams and head to a paintball course. Or simply invite them to a larger brainstorming session just to hear their ideas and build relationships. Working together is the first step to share accountability so you can both succeed, and sometimes fail, together.
“Beer is the most powerful tool in the DevOps environment. Take everyone down to the bar and just let them talk.” – Ben Rockwood, Joyent [Source: Keynote Address at the 25th Large Installation System Administration Conference (LISA ‘11)]
Inspire Others by Valuing Their Opinion and Including Them.
Speaking of getting cross-functional teams together to brainstorm, inspiring and including others will do wonders to break down silos in your organizations. In a silo’d culture, it’s easy to feel like you’re not included. This leads to thinking your ideas don’t matter; you can’t change anything and eventually not being included may lead to apathy.
Start by inviting both developers and operations engineers to conversations about what is required for a project. Don’t delegate tasks, but instead let people play an active role in figuring out the best way to accomplish a goal. Having input and playing a role in the decision making for a project will create a sense of ownership and pride in one’s work. This will give you the ability to recognize people for their contribution to further reinforce this sentiment.
Beginning with a single project will pave the way for your company’s entire engineering culture. This allows people to see projects from their initial conception all the way through to their completion. This will not only make people feel pride in their work, but start breaking down the “Us vs. Them” sentiment that often runs through development and operations teams. It’s about succeeding together, not pointing fingers when something unexpected happens.
It only takes asking a question or a meeting invite to spark a conversation to make people feel engaged and form a sense of responsibility for a project’s success. You will not only find solutions for your single project, but start to identity processes and tactics to work together in the future.
Show, Then Tell Concepts
You will want to pursue a show, then tell approach when teaching concepts. By showing you are leading by example and demonstrating proof of concept. It’s important to be genuinely interested in helping your colleagues improve their work by adding to their skill set.
For example, if you are on your company’s operations team and want to help a developer be more productive you can show, then tell him or her how to run a command. By learning from your example, not just explaining it to them, they will be more likely to replicate these actions in the future.
You will also want to avoid words that may have a negative, have a vague meaning, associated with a fad or may be considered an empty buzzword, such as “DevOps.” If you want to really have a DevOps culture you will need to live it to give it meaning, not just talk about it.
Focus on the benefits of collaboration and improving overall service delivery methods, such as shipping features to customers faster so they’ll get off your backs, when you need to use words to reinforce what you have shown them.
Find Your Advocates
By now you have gotten your team to work together, inspired them and even taught them to learn a few new concepts to add fluidity into their roles. Hopefully, you have learned a few new tricks along the way as well. This is a two-way street after all.
Unfortunately, your work is far from done. Chances are not everyone was receptive to your invitations or collaborating with you. Not everyone was open to learning. If it was that easy, wouldn’t everyone be using a DevOps organizational model?
To combat their apathy for the cause, you will need to find advocates on different teams to help teach and give your ideas more exposure. In order for any culture shift to take place more than one person will need to start advocating for it. Find those whom seemed most receptive to your invitations and teachings, then recruit them.
For the naysayers, help them understand (maybe over a few beers) how transitioning to a DevOps operational model will directly impact their lives. Discuss what each team wants and needs from each other and request that they advocate from their side bringing everyone together to start solving problems from the beginning together.
Advocates can get more of their teammates on board by reassuring them that the transition will be made with everyone’s input in mind. By having people engaged in honest, beneficial collaboration you will finally be on your way for creating a true DevOps culture.
Update 4/10/14 – Continuing reading the transitioning to DevOps series: