Most people that know me are aware of my passion for lean principles and that journey started completely by accident when I became exposed to DevOps, Continuous Engineering and KanBan. In fact I remember the first time I that suggested going “DevOps” and that was back in October 2011.
I was working at a large digital e-commerce company and we had a number of great B2C (business to consumer) products. In fact many of them, back in the day, were groundbreaking but Customer and Business demands were not being met and the platforms were suffering from the early onslaught of “legacy”.
Father time gets us all in the end but from time to time in Technology, one sometimes gets the chance to be re-born through the rewriting or re-platforming of products and/or systems.
We were on this journey, but the legacy systems had one major drawback…..legacy thinking. Mainly from the original architects of the original system.
How often have you heard stakeholders say, when replacing an existing system with a new one, “the minimum requirement is to have all the features of the existing platform”. And this is where the trouble begins.
Big projects, with multiple teams, in multiple locations take a long time to deliver value and the stakeholder feedback loop is near non-existent. Teams are told to speed up, work weekends and just get the job done. Developers start to clash with Operations as the demand increases and the quality (usually) decreases. Then when deadlines are inevitably missed, the Executives start to roll-up their sleeves and run remediation workshops.
This was no different for us. In fact poor old project managers and product owners were either fired or banished to the back-office.
Something had to change and I when I heard about DevOps (coupled with BDD and Automation), it was clear to me that this would improve our broken working practices and caustic culture plus give some modicum of hope.
So on a nice sunny day in a big meeting at HQ (somewhere in the USA) in 2011 the presentation about DevOps started. The graphical metaphor involved a Volvo getting maintenance and was compared to a Formula 1 car’s pit-crew. Clearly this demonstrated “speed”, “collaboration” and “delivery”.
We were chuffed, the arguments were sound, the movement was clear and all we needed to do was re-organise Global IT, defocus QA by getting Dev’s to automate tests and introduce Agile Methods. So we paused for feedback from the assembled Global technical Executive Leadership team – some of whom joined via conference call from 3 different continents.
The sound of “Crickets” could be clearly heard. Quickly followed by a tsunami of negativity. Then the global CTO shot me down in flames.
To be fair, it was 2011 and you could’ve have counted the number of DevOps adoptions on one hand (mostly in small organisations) but believe me we learned a valuable lesson. That was, no matter how right you think you are, never underestimate the challenge of when Psychology meets Technology. I’m going to blog more about this in the future but suffice to say that transformational change is hard to land when people are personally impacted.
I know this sounds blindingly obvious now but fear not. Your traditional leadership skills, not technical ones, can get you on the right track. I know that now and we are having great success at present.
So what happened to the company where I used to work?
Well, the global CTO was fired 3 months after my presentation, the new one lasted 12 months and then the lay-offs began. Soon after that the company was sold to a bitter rival. However the brand did live on but as a skin on a white labelled web-site.
Would DevOps had helped? I couldn’t say but certainly when one changes the culture, unleashes experimentation & innovation, focusses on waste & efficiency and not just empowers people but “really” trusts them…then this drives Customer value which in my opinion increases the chances of success.