DevOps Does Not Mean Automation

In the past few months I have attended some DevOps meet-ups, I hadn’t actually had the chance to do this for a year or so. It is always really refreshing sitting and listening to others experiences and war stories at companies other than your own. It also gives a sense of perspective, allowing you to gauge how mature your organisation is, in comparison to others that are on their own DevOps or continuous delivery journey.

I also love conferences and meet-ups as I see it as an opportunity to go out and talk to people and see if anyone is doing something interesting that we could bring to our own organisation, be that a new way of working, a new technology or just something we hadn’t come across yet that would bring value.

However, I found myself a little disappointed in many aspects around general understanding of DevOps from some pretty high powered companies at recent meet-ups. DevOps isn’t really a new thing and it still seems that some haven’t grasped that it is about culture. What does “culture” really mean? Oh no DevOps bingo buzzword alert….

For me it is pretty simple, it means having a supportive organisation that does not break IT departments into traditional silos. It means having T-shaped teams that are put together to deliver different projects. It means developing a culture where a manager’s job isn’t about barking orders anymore or dictating how things are done, instead managers are there to remove blockers or impediments stopping their teams from doing their jobs.

This DevOps culture allows engineers the ability to collaborate, share ideas, talk as necessary with other teams to solve everyday problems as they don’t have line managers stating their staff don't have time or are too busy to speak and work with others when they aren’t. This requires people to champion this new way of working and it allows a work-place where innovation is at the forefront not fear of change or moving too fast.

A DevOps culture should allow the word “impossible” to be replaced with “how can we” or “when can we achieve this by”. If there is an issue or engineering challenge, it can be incrementally improved on or fixed by empowering engineers to do this.

DevOps culture is about challenging everything, prototyping new solutions, creating feedback loops in processes and implementing a continuous improvement model on every process and removing waste.

I can’t stress this more, DEVOPS DOES NOT MEAN AUTOMATION, IT leaders still seem to confuse continuous delivery or automation with DevOps. The DevOps culture you create in your organisation, for the above reasons, can mean it facilitates continuous integration, continuous delivery and automation. 

But DevOps and automation can be mutually exclusive, you can have automation and not be doing DevOps and it seems loads of companies are doing automation and not DevOps.

At a recent London DevOps meet-up I watched a panel of so called “experts” talk utter drivel for 30 minutes unchallenged on anything they were saying while some newbies to DevOps scribbled down these so called words of wisdom on notepads. Eventually I posed the question to the panel via an interactive question wall (Oh the irony, DevOps meetup, communicate via question wall):

“Does the fact that there seems to be a common misconception that: DevOps = (an automation team) not mean we see a constant creation of 'DevOps Teams' in industry and yet another silo?”

Despite the question receiving most up votes to be asked next to the panel, by an equally agitated and disillusioned audience (newbies aside), it was promptly deleted by the organisers so never asked to the panel. The shock, the horror, the (insert expletive).

Why did that happen? Probably because half the panel were talking about DevOps teams they had set-up in their organisations. At a DevOps meet-up they had failed to embrace the challenge everything mantra by asking for questions and censoring some. Upsetting yes, unexpected? No.

To quote a current colleague of mine, most big organisations will, “give the current ops team a raise, rename their ops team the DevOps team and go out to DevOps meet-ups and tell the world they are doing DevOps so they can get a pat of the back and show they are a forward thinking company”.

Technology leaders and managers in majority want to work with other managers that agree with them, so they can work in harmony, pat each other on the back and all agree how good they are doing. Here-in lies the status quo, the conformational bias, my peers agree it must be right, in truth that's because you picked them. This is where complacency sets in and company rot. A variety of opinions are required for organisations to be successful, difference in opinion, conflicting ideas and challenging preconceptions make us better as long as they are channelled in a non-destructive manner. 

In a way, we need to disrupt the notion that a harmonious group of managers that agree on everything is a good thing, before we can move forward in IT, sometimes it isn’t pretty and sometimes it can make for difficult conversations. But if we accept every persons opinion in an organisation should carry the same weight if you have recruited intelligent people then and only then can we move forward as a group.

Another annoyance for me, from the same panel at the very same meet-up, was when broaching the subject of talent retention, they talked about locking graduates or staff into the company. 

Oh how this made me mad, in my opinion when you take on graduates, as a technology company, you have a duty to help these individuals grow and mature by giving them the skills and training necessary to be successful in the IT industry. 

This means pushing graduates outside their comfort zones at all times, coaching them daily and giving them fun and interesting work that you yourself would love to do, not crap you don't want to do. Hiring graduates shouldn't mean locking them into the company.

After graduates have done in theory their apprenticeship of 2-3 years at a company, I would actively encourage them to try something different if they don’t feel they are progressing at the current company, which could mean looking elsewhere in the company or moving jobs to a different company. By that time the next wave of graduates should be doing their apprenticeship at the organisation and be ready to replace them if they do leave.

However, my main point here is that, if companies are meeting individuals needs in terms of personal development and have a created a good company culture that empowers their staff and makes them happy, they shouldn’t need to worry about talent retention, that will take care of itself.

Ideally we should be setting graduates up to be the next technology leaders in organisations and developing them all the time. It is not a company’s duty to lock in talent to the point they stay at the company despite being unhappy, as they have been told them they won’t get a job anywhere else. 

Companies that are fearful of losing talent have a far bigger cultural issue, which is a culture of fear and uncertainty from management. There should be no bus factors of one in your organisations and if your daily operations are completely automated then what are you worried about? Or was that all bluster just for the sake of those at the meetup and not in fact true? It is time for some companies to stop all the talk and learn how to walk the walk.