Skip to main content

Lean Culture Change

We all know culture is a huge part of DevOps.  What we don't know is how to change it.  The easy answer is change culture just like you would "eat an elephant",  one bite at a time.  What this does not tell you is where it start.  Do you start with the thigh, leg, tail or even the head?  This is where you should look at culture change just like any other lean process improvement.  Here are some examples:


  • Focus on the value to the customer
    • This will help you sale why DevOps is important to the company.  There are plenty of information and statistics of how DevOps is changing the industry.  Do your research and be prepared when a decision is made that is anti-DevOps.  Try to right the ship and stir it a little closer to DevOps.  Keep iterating through these opportunities over time.
  • Respect and Engage People
    • Culture change and job change is scary.  You will meet people who hate you.  You have to be a leader that can empathize and learn to respectfully debate new changes.  Why should a traditional engineering team want to give up responsibility to developers or a DevOps team?  They don't trust you.  They may not even like you.  Find ways to sale the customer and employee value over time.  Pick small steps like managing the dev environment, writing Chef scripts or moving all their scripts into source control.  You have to see their side of the change and show them how it helps them. 
  • Improving the value stream
    • Don't try to change everything.  Start with what the company culture will let you change.  Then, wait until you need to pull the Andon cord for other changes.  If no one can see anything wrong, they will not be motivated to change it.  A recent example is letting support teams make bug fixes.  I know, I know capital versus expense, blah, blah...  I had a short debate with the a leader who was planning to outsource bug fixes for his support team.  He was dead set on it and I could see that early.  No matter what, this will go bad.  Either support will overwrite some code, not do it right, break something else, poorly test it or not follow good development practices.  A key tenet of DevOps is have the most knowledgeable people do the work.  Enterprises seems to miss this badly.  When things go wrong, bring to light how it can be done easier or better by letting those skilled and trained in the craft do features as well as bug fixes.  Remember the first two items, but keep building your case over time and opening everyone's eyes to how the change benefits the customer. 
These are just a few examples of thinking about culture changes just like lean process improvement can help you in your journey.  Start with the easy stuff that provides value and then, focus only on things that provide value when they happen.  It will take years to change a traditional IT enterprise to DevOps.  Don't try to change what is perceived to be working until you have metrics or visible waste to remove. A huge side benefit of this is your job satisfaction.  If you take a pragmatic approach, you will not feel so depressed or beat down by not making change fast enough.

Comments

Post a Comment

Popular posts from this blog

2020 State of DevSecOps by Accurics

 This is an excellent report for all IT Pros and Engineers.   Highlights: Storage is most impacted solution Open security groups or network configuration Secrets are not so secret Unused resources are not secure. Take a look at these.  Look again.  These are not highly skilled problems.  They just need guidelines and proactive management.  The article uses policy as code as a solution for many of the problems.  I will drill into each of these more in the future.  I wanted to get the awareness out first and then, come back to solutions.  
Post a Comment
Read more

Learn Anti-Leadership from Basecamp

 There are many different articles out there and Twitter comments about the Basecamp drama.  I am not going to post any here because it might seem biased depending on the article.  Google them yourself.  In short, Basecamp made a policy to not allow political discussions at work.  Coinbase did this previously too and applauded Basecamp for it.   Apparently, for years there has been a list of funny customer names at floating around Basecamp.  This list or even the knowledge that Basecamp had a list, was disturbing to some employees.  Also, some employees tried to start a Diversity and Inclusion practice.  Despite how much the founders of Basecamp promoted DI, they didn't feel they were being taken serious.  They felt the company was only about the founders and not about employees.    If this isn't enough, the founders debated and even called out employees for their comments regarding the topics, publicly.  This is my s...
Post a Comment
Read more

Cloud Ops: The New IT for the Cloud Era

Over the past few months of interviewing and researching dozens of companies—particularly small to mid-sized SaaS businesses—one pattern keeps emerging: the desire to stand up a Cloud Operations (Cloud Ops) organization. It makes sense on the surface. Cloud is now the infrastructure of choice, so naturally, someone needs to “own” it. But what’s unfolding in practice often misses the mark. Many companies are attempting to solve growing cloud complexity by taking all their DevOps, SRE, and platform engineering talent and consolidating them into a Cloud Ops team. The idea? Share them across product teams so no one gets overwhelmed. If that sounds familiar, it should. It’s the same centralization tactic used by traditional IT for decades. And it's creating the same problems. When Cloud Ops Becomes Old IT in Disguise Here’s the playbook we’re seeing: Move DevOps, SRE, and Ops into a central Cloud Ops team. Let them handle infrastructure, CI/CD, monitoring, and cloud securit...
Post a Comment
Read more