DragonImages - Fotolia
DevOps done right: Creating a collaborative and supportive business culture
Cultivating a supportive and collaborative business culture is considered central to getting DevOps to take hold in an organisation. We take a look at what this entails
A happy, productive and high-functioning IT department, staffed with people who look forward to coming to work each day, is something all CIOs aspire to run.
It is an aspiration, though, that many are doomed never to realise unless they are willing to commit to cultivating a good working culture, says Helen Beal, a DevOpsologist at London-based digital transformation consultancy, Ranger4.
“When we talk about culture, it’s often linked to the way an organisation is structured and operates, and what IT departments should be looking to avoid are cultures led by fear, punishment or blame,” she tells Computer Weekly.
“Organisational hierarchies that are very ‘command and control’ in nature are also to be avoided, because – what you are looking to create – is a culture where people can work with autonomy and purpose.”
Central to this is giving staff “meaningful work” to do that demonstrably contributes to supporting the company’s wider growth ambitions, says Beal.
“If we have those things, it generally follows that people are happier and more productive,” she says.
For IT departments drowning in Technical debt and helpdesk tickets (as the legacy technology the business runs on lurches from one system failure to another), meaningful work can be difficult to come by.
Particularly as getting whatever system has fallen over back up and running again takes priority over projects that could improve the customer experience, and deliver real value back to the business.
Addressing problems head-on
In this type of situation, the best thing an IT department can do is resolve to address the technical debt and legacy technology problems head-on, says Beal.
“With the technical debt built into their systems, what you get is an IT department under pressure to produce more innovation while working with very fragile systems,” she says.
“It is a journey a lot of organisations need to go on. They almost have to throttle change in their organisation to give themselves the time and space they need to tackle the technical debt, but it can be a very hard thing to do.”
Not doing so can have a detrimental impact on staff morale, as the IT department gets it in the neck whenever one of the creaking legacy systems the company runs on fails.
Stuck in a cycle of firefighting
This is a situation Oliver Wood, an Amazon Web Services (AWS) architect now working for managed service provider Solarwinds, knows only too well.
“Years ago, I was trying to figure out why I wasn’t enjoying what I was doing at the time, and it was because I was stuck in that cycle of firefighting, where we weren’t actually solving the bigger technology problems or the root cause of the issue – we were simply fixing the system when it was on fire,” he tells Computer Weekly.
Getting stuck in a day-to-day rut like that can negatively affect how people feel about the quality of the work.
Hannah Foxwell, product manager at Software-as-a-Service monitoring and alerting platform Server Density, experienced this several years ago, while working as an IT programme manager at a UK supermarket chain.
The organisation was heavily siloed and operating a sizeable legacy IT environment, despite the best efforts of Foxwell and her team to keep it up and running.
“I hate failing, and we were constantly trying to work out why we couldn’t ship code into this environment reliably. You then dig a little deeper and realise the problem is technical,” she tells Computer Weekly.
Before this realisation, though, the tendency in her team was to blame themselves for any technical difficulties that arose and assume they were terrible at their jobs.
“I discovered continuous delivery and the DevOps movement when I was trying to figure out why we were so bad at our jobs,” says Foxwell.
Stopping the break-fix cycle
Getting locked in to a break-fix-style support cycle on a day-to-day basis can be physically and mentally draining too, says Wood.
“If all you are doing is fire-fighting, and the root cause is not being addressed, you will always be fire-fighting, but what organisations should want are people who are being productive, are happy with what they are doing and not half-dead because they have been up three days straight,” he says.
It is not just the operations team who find working under conditions like this a drag, says Beal.
“For the support desk, it’s horrible because they will be the ones getting the rough end of the deal, as all the annoyed employees complaining at them, while operations will are likely to have someone shouting at them to get the system back up and running.”
The pressure on operations to fix the problem can be exacerbated by the fact the root cause may be down to an errant piece of code or some other change the development team is responsible for pushing through.
“It could be down to bad communication between the developers and operations team about the configuration of the environment, but the point is the support people are getting the rough end of the deal during an outage,” says Beal.
Culture of collaboration
To prevent scenes like this, CIOs should take steps to open up lines of communication between all members of the IT department, irrespective of job role, and encourage collaboration between the developers, operations and the support staff to thrive.
“Developers are very proud of what they do, and giving them more involvement in a problem is something they’re often quite keen to do,” says Beal. “Getting them in close proximity to the support desk is really key.”
This can be achieved by breaking down the traditional IT department siloes, and reorganising people into small, cross-functional team units, paving the way for developers, operations and support to work side-by-side in a DevOps-like fashion.
“If you look at the organisational chart of a traditional IT organisation, you’ve got a CIO, you’ve got developers, the operations team and they are all very segregated, and then there is often further segregation within these silos,” she says.
“You’ll have developers separate from the people testing the code, and then the operations team who have networks, security and support all separate as well. The end result is that collaboration between developers and operation is not very good, or within the operations team itself, and that can give rise to conflict.”
In that kind of setup, it’s not difficult to see how resentment, frustration and conflict can arise between the disparate groups of people that make up a traditional IT department, which isn’t exactly conducive to creating a good workplace environment.
Working in this way can contribute to people in these silos feeling as though they are being pitted against one another, says Foxwell, particularly when it comes to apportioning blame for outages and system failures.
“You can end up feeling like everybody is waiting for someone else to fail, because you don’t want to be the ones responsible for launching something that breaks the system, and there is a lot of friction,” she says.
“Testing would wait for the environment to break, to say they could say it wasn’t their fault, and then – when the environments went down – the developers would get the blame, and it becomes a vicious cycle.”
Cross-functional career development
Depending on the size of the IT department, each cross-functional team can be tasked with looking all or part of an application, website or service, paving the way for them to create, test and deploy secure and compliant code into production environments multiple times a day.
Getting to this point, though, will require CIOs to address how the IT organisation views failure, as this can have a direct impact on the creative output of these cross-functional teams, says Beal.
This is important because innovation and experimentation are intrinsically linked, and punishing people when their efforts do not pay off may encourage them to play it safe in future.
It is a notion cloud giant Amazon Web Services (AWS) subscribes to, and is one the organisation credits with allowing it to rapidly expand the functionality of its platforms and services on a daily basis.
Read more about DevOps
- What steps should the enterprise take in adopting the DevOps approach to software development and delivery.
- CIOs and IT leaders share their advice on what enterprises can do to accelerate the spread of DevOps within their organisations.
AWS CEO Andy Jassy describes failure as a by-product of innovation, and a sign of how high productive its cross-functional teams are.
“We hope that most of the things we do aren’t going to be failures, but if you are innovating enough, you will have things that don’t work, and that’s okay,” he says.
“As long as the inputs into that initiative were executed well, the staff don’t somehow have their careers clipped.”
In a bad working culture, employees are often made to feel like failure is a “bad and scary” thing, and contributing to one occurring could negatively impact on their workplace reputation and career prospects, says Beal.
“In a good culture, failure is seen as something to embrace, as long as that organisation has built in systems that allow employees to fail safe, fail smart and fail fast.”
And by that, she means technologies that allow the reinstatement of the last known good state of system should the deployment of a new piece of code adversely affect its performance.
“There are also digital performance monitoring tools, which effectively help us to pre-empt system failures, and – when they do occur – fix it and identify the root cause fast,” she says.
Adjusting CIO attitudes towards experimentation
For more risk-adverse CIOs, getting them to adjust their attitude to experimentation and failure may require these cross-functional teams to engage in a few trust-building exercises first.
“We have to go through this process, particularly if we have nervous executives who have been in the job 30 or so years and have seen a lot of bad things happen,” she says.
“The teams will have to make an effort to showcase and prove what they can do all the time, and get them comfortable with the fact it is possible to do multiple code releases a week without a single outage occurring.”
From a technology perspective, isolating what needed to be done to shore up and stabilise failure-prone IT systems was relatively straightforward, says Server Density's Foxwell, compared to securing buy-in for her DevOps transformation plans from the relevant stakeholders.
“I became so enthused by the subject of DevOps and continuous delivery, I was given the remit to embed the principles in my team, but when it came to the human and cultural aspects of it, that’s where progress really slowed down,” she says.
Cultivating a working culture that supports experimentation, encourages collaboration and celebrates failure will take time, and is often the hardest part of any digital transformation project, says Beal.
And for this reason, it is important for CIOs not to lose sight of what it is they’re trying to achieve and the benefits they stand to realise once the process is complete.
“The cultural journey is a long one for a lot of companies because what we’re effectively saying is, here are a bunch of humans who are performing in a certain way and we want to change that. They have habits we would like to break and reform, and that can be very hard to do,” she says.
