To really change the way an organisation behaves you need bold leadership that are willing to “let go”
Many organisations want to move towards DevOps, Microservices, Cloud using OpenShift, Ansible and all the cool stuff we like and work with. However it takes more than a few carefully selected and well trained parts of the IT organisation to perform a digital transformation. Instead you need multiple departments to engage and agree on common goals with individual targets and milestones. This is a message most agree on and it would fit nicely in to a few catchy PowerPoint slides. Unfortunately the outcome often seem to end up in the realm of: “aha… mmm… interesting… yepp… totally agree… anyway, what’s for lunch ?”
To change people’s ways of working when they have been in a company for a longish enough time and challenge them to do DevOps instead of Waterfall (the skill they were originally hired for) feels like I’ve asked them to dig up tar from a basement room full of spiders and snakes instead of leaving them be to do business as usual which in comparison is like soaking up the sun on a beach chair while enjoying a nice cold drink.
Of course it isn’t. Developing and deploying software to legacy applications in the rapidly changing IT landscape crawling with admin rights and network obstacles is rather like a frustrating and scary journey across misty and endless moors full of lurking werewolves where communication with other teams that you urgently need help from is like shouting in to a pillow. But it is the way of working that the teams and managers are used to – so therefor they continue doing it and at the end of the month the pay check is in the mail.
If I look at the teams that have embraced DevOps and automation. They just use the platform to get their code to production. These teams are much less frustrated, they have fun, solve problems, they learn fast, move on, deploy without fear and go for lunch afterwards. So totally different from the traditional teams (crossing the moors). Why is this so hard for management to see, why is it not clear that there are other ways of doing things that is so endlessly much more productive?
Perhaps because I am part of the problem, not the solution. I am challenged to sell time, hours that can be invoiced. The more consultants in a project the better. If I automate and reduce headcount that’s bad and will reflect on my targets and there will be pain in my wallet. The more manual and complex tasks the less likely is the customer to take over or even understand what I am doing. That means manual and traditional business is good and will go on for many years. Just maintaining a traditional way of working with development team, that hand over to test team, that contact the Infra team, who send a request to the admin team, who deploy the software in the test environment (while another team were testing something else and everything crashed), and alert the application owner team who then start to configure the application and when they are done send a report to the test team that they can begin testing and…
So my ways of working and the financial metrics used to evaluate my performance actually prevent DevOps and automation – unless I do it in a complex and staff intensive way. Now instead of hosting big meetings under the banner “we have to change the company culture and move towards DevOps”. From where I am looking the fastest way to change a “culture” is to change the financial metrics for bonus, budget and KPI. This would be a basic “behave-reward” scenario that would help re-structure the company culture and make people change their ways of working. It is obviously not the only way but it will have significant impact especially since it would control how sales, middle and upper management behave.
Here’s what I would like to do (high level) to change how an organisation behaves;
Department: Human Resources
Responsibility: continuous reskill & upskill
Focus topics; attract, learn, evolve, share, retain, reward
Department: Finance
Responsibility: KPI, Budgets and Bonus metrics
Focus topics: horizontal metrics, value of automation, cloud & datacentre cost simulation/planning
Department: IT Security
Responsibility: Automate and implement security guidelines as part of the platform
Focus topics: embedded security, Live and stateful, risk AND opportunity management
Department: Business
Responsibility: time to market, continuous evolution, innovation
Focus topics: high pace innovation, leading existing markets, finding new markets
Department: IT Development
Responsibility: learn fast, feedback, DevOps
Focus topics: reusability, fast response, new solutions
Department: IT Test
Responsibility: test automation, innovation
Focus topics: fail safe , early engagement, automate everything, key to innovation
Department: IT Infrastructure
Responsibility: automation and OpsDev
Focus topics: Self service, elastic platform, proactive planning
Department: IT Architecture
Responsibility: past, present, future
Focus topics: shared services, refurbish and innovate, *I.N.V.E.S.T.
*Independent Negotiable Valuable Estimable Small Testable
Department: Production
Responsibility: digital enhancement of existing products
Focus topics: innovation, new/next product cycle
So by starting all these streams in the different departments significant changes could be achieved and I hope this is what we can contribute with to enable the most efficient use of the Red Hat software portfolio.