WTF is… DevOps?
It was 2007. I was fortunate to land a job as a developer at a swish international firm — the type that had beautiful offices with huge receptions, burly security guards, marble-lined bathrooms, huge canteens, healthcare on-site, and a fancy gym. Perhaps something reminiscent of Suits. I was a small fish in a big pond and surrounded by incredible people, and I was grateful to be there.
The firm was Lehman Brothers, and it was one year before bankruptcy.
However, something interesting was brewing within the technology teams. Like a zygote, each tech team was subdividing into two parts: one part was to focus on ‘running the bank’ — keeping the systems online, managing the underlying infrastructure, fixing bugs and taking calls from users— whilst the other part was to focus on ‘changing the bank’ — developing new features.
Now, at the time — and for many years after — this sounded a logical separation to me. It would bring focus — one set of developers could focus on writing new software features (Dev), whilst the others kept the lights on (Ops). There’d be no more developers scurrying around to try to do both at the same time.
I admit, it took me years to realise this separation was an anti-pattern that transforms a single team into two silos: the “Dev” and the “Ops” that DevOps is now trying so hard to merge back together.
Unfortunately, this anti-pattern has been followed by many organisations in an attempt to increase efficiency. It grasps at inspiration from Victorian factory lines in which each individual was focused on narrow, repeatable tasks to allow them to build speed and efficiency in that one small area.
Software development is not like a factory line: the outputs that need to be created are ambiguous to begin with — only through exploration do teams find what new features need to be created to solve the problems their user faces. This in turn requires curious teams with diverse skillsets and a creative approach.
So what is the impact of separating Dev and Ops?
Firstly, lower morale and productivity. Most developers are creative beasts — they want to make things. By encouraging some developers (‘Ops’) to solely focus on keeping the lights on, their ability to grow can become limited. This can lead to lower morale, and also lower productivity — we are not taking full advantage of what these individuals can offer now, or in the future.
Secondly, reduced reliability. There is no longer an incentive for the developers writing new software features (‘Dev’) to do it well. They won’t be the ones suffering the implications — the ones writing bug fixes or talking to angry end users should things go wrong — this will be ‘Ops’. The ‘Dev’ team will likely instead be measured on meeting deadlines, and therefore become increasingly focused on creating anything — even the wrong thing — quickly.
Thirdly, reduced outcomes. By not being the ones talking to end users, the ‘Dev’ team’s feedback loop has been removed — they no longer have an understanding of their users, and are less able to create the right solution for the job.
DevOps is about reducing the structural and cultural fragmentation in software teams, and the use of technology to automate the time-consuming mundane. By doing this, we increase creativity and accelerate the ability to create better things sooner.
I recognise, in my interpretation, I’ve simplified a very deep and important subject.
This interesting division of software teams is nothing specific to Lehman Brothers, but seems commonplace in larger organisations where efficiency is directly sought after.
I must also say, my time at Lehman Brothers was some of my most enjoyable years of employment — with incredible people, and lots to learn. I am grateful.
Other stories in the WTF series:
