Running devops when you don’t know where the devs are
So devops is not a skill (despite what job titles would have you think). It’s a mindset that espouses Ops and Dev sharing their skillsets and ways of working with each other.
That’s great, and it can work really well. But it’s not so easy when your role is ops-focused, you create and manage infrastructure and.. you can’t get near the devs.
What do I mean? When you’re someone interested in getting devops running in a larger organization, it’s possible that:
- the company has employed a temporary contractor (or contractors) that have no interest in adopting a devops mindset for the time they are working at the company
- the company has employed an agency of developers that you don’t have any inroads to
- the company has a team of developers that are in another dept from you, have never seen you, will never see you and their preferred means of interacting with Ops is throwing projects over the wall like UDP, fire and forget.
These are all symptoms of groups being siloed
In siloes, there are no easy lines of communication between the groups of colleagues, no exchange of ideas, no sharing of pains or problems.
For those locked in option 1, it can sometimes be hard to embed yourself with someone, or a group of someones, who might not feel embedded in your company or invested in creating a better working environment, not caring to adopt the devops mindset and might go outside the preferred means of operation for the length of their contract. This is frustrating since “lone wolf” staff members are nightmarish to work with.
For those enjoying option 2, it’s even harder. To adopt a devops mindset with code that has been thrown your way by developers that you usually can’t really talk to at all and have no idea of what their development practices are, you don’t have to adjust your company’s practices but rather have to somehow get staff from another company to adjust their working practices to mesh with your desired devops methodologies.
For those lucky souls living option 3, it’s possibly the most frustrating and heart-breaking of all. Occasionally, colleagues in the same organization, yet in different departments, have no easy way to get visibility on each other’s work practices, their concerns, problems and how the two colleagues might benefit each other. Historically, the spark for a devops mindset might come from below but it has to be agreed and led from the top down.
How do we try and implement a link between Dev and Ops when Ops just can’t get near Dev, for whatever reason?
It’s difficult. Really difficult. In my opinion, you need to tackle it in one or both of two ways, get buy-in from management, who have the power to create initiatives to further this, and get buy-in from the creators who’ll make it happen, the people that’ll setup the tools that enable devops.
If you’re trying to implement something in a company, be it large, medium, small, you have to win the hearts and minds of the people (yes, people, not staff) who will have to choose to use it. Too many times, it’s the case that a devops-minded person will think to themselves:
“I reckon the company can be made better by everyone doing it this way. I shall make it so, and they will come, and they will use my tool, and it will be good.”
That kind of approach rarely works. Devops is best implemented by people who suffer through a lack of devops and through managers and execs who see the benefits to the company as a whole, to it’s processes and the happiness of it’s staff.
Execs will want a POC (Proof Of Concept) and metrics backing up the prospect that a devops methodology will benefit the company’s development process. Once they’re convinced, they have the power to implement processes and make room for initiatives in the roadmap, without necessarily understanding for themselves the problems and solutions involved.
Software and Systems Engineers will want to see how it works, to understand it and make a positive change, but they won’t have the power to implement it department or company wide. They’ll instead have to work small and garner support among the people who suffer the most pain points and use that to make a business case.
Summary — There’s no magic wand
Long and short of it, there’s no easy answer. It depends on the initiator’s position in the company, sway with the execs, visibility over the various processes of the company in the SDLC (Software Development Life Cycle) and ultimately their ability to empathise, understand and solutionise the problems and trials that the SDLC causes everyone involved in the chain, not just Dev or Ops, but the project managers, QA, delivery leads and release engineers.
