A Different Meaning of CI - Continuous Improvement, the Heartbeat of DevOps

This article is a report on my very personal experience, showing that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. I have seen this in different organisations, and have been personally affected by it two times in my career. I have seen how people’s motivation and engagement in improving their work was brutally killed by a bad culture - even before anyone could discuss these ideas. And with dying motivation and missed chances for discussing ideas, the organisation also misses the opportunity to move forward! For me it was such an unbelievable waste, that I turned the experience into a talk which I have already given at DevOps Days Tel Aviv 2018 and will give again at RebelCon.io 2019.

What does  “Culture eats improvement before breakfast” mean?

I like the well-known quote “Culture eats strategy for Breakfast” by Peter F. Drucker, because for me it is one of the essential learnings every organization has to make. If the culture is not supporting the strategy, the strategy will be obsolete from the very beginning. To create a strategy without taking culture into account is a waste of time, money and foremost, motivation.

I changed the quote a little bit, because a culture of improvement is crucial for companies, especially in our VUCA-world, where everything is changing very fast. And I also added the word "before," as people will not even think or talk about ideas that could be improved if the culture has shown that such engagement is neither respected nor wanted. This means that companies will not even get the chance to think about their employees’ ideas! Even if there is any glimpse of an idea of what could be improved, it will immediately die in people’s heads.

When I talk about “culture”, I’m referring to how managers behave, as well as departments, teammates and individuals. It is about the “unspoken rules”, organisational frameworks and processes, as well as incentives. All these things together form and change culture constantly. And sometimes the “real” culture is not what is defined in companies’ values, visions or philosophy.

But one thing is for sure: every organization has a culture - a motivating or demotivating one! This means, if you want to turn towards a more motivational and positive culture, you have to identify the old behaviors and get rid of the bad ones which hinder improvement.

The critical role of improvement in DevOps

Isn´t DevOps itself an improvement on how Development and Operations work together? Okay, let's take a look.

Organisations are not doing DevOps for “humanitarian” aspects. The idea of tearing down the wall of confusion, and autonomy for more motivation and all the other good aspects that make work more interesting and less stressful, is an important key for reaching the real business benefits: staying or becoming competitive in the increasingly faster-changing market.

Welcoming new requirements, implementing new features and reacting to customers’ behaviors within a short period are demanding tasks. In order to concentrate on the main goal - to deliver working software - we need to improve the way we work together; the collaboration. Always focusing on the main goals, identifying everything which is not working well for us and finding a solution is important, whether these are technical impediments, organizational issues like processes, or more human-centered aspects such as communication.

Here we can refer to the acronym CALMS. The “L” for “lean” implicitly demands improvement; identifying and minimizing waste, which is an ongoing process. The “A” for “automation” also hints at improvement. Automate as much as possible, as long as it is a useful means to reach a certain standard of quality and reduces the “waste” of repetitive work, which is important for having more time to focus on improvements.

The “M” for “measurement” helps us find out if things are going in the right direction, or if there is a need to improve. Here you shouldn’t only measure technical performance, but you should add, for example, A/B testing to the list, as well as Canary releases, where you can check on the one hand if everything works the way it should, but on the other hand, the user acceptance. Why? You want to find out what needs to be improved - and at an early stage, so that these issues don’t add up throughout the whole development cycle. But we can also measure the lead time of tasks to find our bottlenecks, using Kanban for example.

This means that transparency in our work also helps us to find opportunities for improvement. By taking a look at code quality and clean code - which will hopefully get checked during the development process and in the delivery pipeline - there is this so-called “Boy Scout Rule,” created by Robert C. Martin (Uncle Bob): “Always leave the code you’re editing a little bit better than you found it.” This is also a plea for improvement.

There is the same idea behind the “S” for “sharing”. Sharing means that everyone can improve their own knowledge and skills easily day-by-day, without needing many time-consuming and costly trainings. Learning as part of daily work will lead to improved solutions. It is the same with the idea of speaking openly about failure. I can add many more aspects to this list to show that “improvement” plays an important role in DevOps. But in the end, it always comes back to high-quality standards in short cycles for more competitiveness!

The Danger Zone: a culture of fear

Some years ago I worked for a company with around 600 employees. The founder of the company was like the “big boss” of everything and everyone. Whenever his secretary called one of my colleagues into his office, they were really terrified and immediately started to sweat. And “the big boss” started to play his game. He asked questions in a very rude way,  was never friendly during such interrogations, and just got a smug grin when people couldn't answer correctly or when they showed nervousness.

The problem was, he also acted like this when one of us had a good idea to improve something related to the company and our work. He always made us believe that it was a bad idea and not useful for the company. In many cases, he later took this idea and sold it as his own without giving any credit to the person who came up with it.

This is usually not a big deal if you have a collaborative and appreciative culture within the company. But our company was driven by fear. So some people avoided speaking up about their ideas because they didn't want to be interrogated by our boss. Others didn't want to give their ideas to “the big boss” without being recognized for it and getting credit.

But what happens when you realize that your ideas either lead to a very uncomfortable situation or to helping someone who you don't want to shine? First of all, you stop talking about your ideas. The next step is you stop thinking about improvement, and then you don’t even think about what and why you are doing stuff the way you do. This is a really dangerous situation for a company to be in. If the employees - the experts of all the work which is being done day-to-day - don´t think about what they are doing anymore, they will not see what is being done wrong or what could be improved. And even if they do see this, they will maybe choose not to think about it, or if they do think about it, they will not discuss it.

But who, if not the experts of their daily domains, should come up with ideas of what can be done better? Someone with a theoretical expertise, who is not sure of how close theory is to reality? This is the job of a lot of consultants. They spend a lot of time learning about the company, carrying out questionnaires, interviews and workshops. And then they come up with a solution, which is often not really accepted by the employees, yet costs a lot of money.

So “before breakfast” for me means that the company has not even had a chance to listen and discuss employees’ ideas, and has not learned from the “in-house experts”.

There is also another really negative example I described in my talk at RebelCon. I am a lecturer at a university. The university made a decision that one specific department needed to scale. One member of the organisation had traveled to countries like India, Pakistan, Nepal, Vietnam, Nigeria or Ghana and promoted studying abroad at this university, with success. Suddenly, instead of the allowed 40 students for the master course  (which in reality always ended up being 60 students), they had 260 students from completely different cultures and educational backgrounds. And with these 200 extra students - surprise - problems arose: not enough teaching rooms, not enough professors and lecturers, not enough flats, no preparation for the language gap, no preparation for the culture gap, and not taking into consideration that there might by a huge difference in educational backgrounds. So, “scaling” in this case just meant growing in numbers, without considering the whole environment. And nobody thought about individual problems due to culture clashes or the impact of, for example, the dark grey weather in autumn and winter on people who grew up in countries like India!

Some of the students decided that they could trust me and opened themselves up and spoke about their mental issues. As I have some years’ experience working with people suffering from depression and other mental issues, and as the number of students who contacted me constantly grew, I decided to inform the dean about the situation. And this was the start of a long, demotivating story.

“I haven´t heard this from any other professor, so this can't be true!”, is only one of the ignorant answers I had to listen to. There was an attempt to verbally threaten me, attempts to show me “my place” within the organisation and that I was not fulfilling the formal requirements to be a lecturer (they had asked me if I could be a lecturer). Another accusation was that I was “forcing” the students to tell me such personal things because I was always talking about soft topics!

An email was sent to numerous people, without my knowledge, discussing me and claiming I was wrong. Somehow we ended up in a first meeting two hours long, where one professor called himself the only high performer and blamed all of his colleagues. We discussed “what to do” without understanding the goals we wanted to reach, simply coming up with the idea that we need another, bigger meeting. Luckily, I had one professor who supported me. She had also experienced several times before that whenever people tried to discuss things which weren’t working well, everyone would try to cover their ass by blaming others. She told me that the political in-house games within the university were taking up so much energy, that she couldn’t really focus on what she was there for - teaching! She was just stuck in the organisational overhead waste and political games.

The second meeting took place some weeks later, with many high-paid people in the room.

Five o’clock in the afternoon, just a few cookies and some water on the table; not a comfortable atmosphere. No one felt welcome or appreciated for taking the time to be there.

Again, everyone tried to blame someone else - people who weren't there were the preferred victims of this blame. Also, the students were blamed by some of the professors, because they were not “the right ones” or “not good enough”. Beating around the bush is a way to describe how the discussion went. When I mentioned after nearly one hour that we call ourselves the experts for project management and teach the students how to run projects, and that we should now stop acting like fools and behave like experts, the vice president said, “Stop talking! I don't want to hear this!” You can surely imagine that I stopped contributing immediately. And I also quit, mentally! I listened to their discussion. I heard the lame conclusion and I also heard one professor say, “Okay, I will leave now because I have reached my personal goal!”

It was clear to me that the whole organisation was trying to avoid acknowledging issues. If you put it into the context of Christopher Avery´s Responsibility Process, they are more or less on the denial level and sometimes switch to the blame level, but really far off from taking responsibility.

I am now just doing my lectures. If students want to do their master projects with me or want to discuss problems, I just decline, because every contact with the organisational overhead is too energy-consuming and demotivating. They tried to make my job more uncomfortable, and normally I would have quit the job. But I really like teaching young, motivated people. I know that I am not the only one who is now reacting like this. As soon as I need to get in contact with some of the other professors because of information I need, I am using only one technique, which works to get an answer: putting the president and other important people on CC. I don't like to behave like this, but I feel forced to do so, just to be able to do my job. I am pretty sure that no one who has had such an experience will ever voice “bad news” again, in order to suggest improvements for a situation.

Embrace the good habits of fostering improvement and overcome the bad ones!

Mindfulness, respect, openness, appreciation, the WE, commitments on shared goals, the wish to improve, trust, psychological safety - these are just a few important aspects of a culture that strive for ongoing improvement.

The lack of transparency, political games, a cover-your-ass mentality, the blame game, misusing power and causing fear, valuing your individual goals over shared goals, saving the status quo as long as possible, and denying issues are some of the enemies of a culture of improvement.

For me, one of the most important prerequisites for improvement is that an organisation is willing to also listen to the “bad news”, no matter how bad it is. We cannot avoid all bad news. So we need to be clear about the fact that there is always potential to improve. If an organisation has a culture where people feel appreciated when they come up with an idea or an issue, where they feel safe to talk about things going in the wrong direction, they will probably become aware of things which need to be improved early on. If employees are motivated by appreciation and respect and feel safe, they will give their full expertise to improve not only their own work, but also the results and processes of the entire organisation. The employees are those who have the knowledge and the full insights. It is reckless if management is not spending enough mindfulness on these ideas and not giving credit. To give people that precious moment to shine is not only expansive, but of inestimable value for the company!

A lot of companies work with employee suggestion systems. But this is not the same as a culture of improvement. In a culture of improvement, you try to tear down the walls of bureaucracy. Improvement becomes part of the daily business. You don't need to apply with an official form. You just discuss it in your team or with the people who are involved. You come to an agreement and define the “success” of the experiment, before you start. The goal is not to change something just for the sake of changing something; the goal is to change something in order to improve it. And if it is not successful, you take it back or try something different. And yes, there are decisions which take more time. But the difference is that in a culture of improvement, management knows about the employees’ expertise and and involve them during the process.

It is my strong belief that many companies could save a lot of money if they would focus more on what their employees report or what would motivate people to speak up about their ideas, instead of paying consultants to analyze a company’s potential areas for improvement. First use the knowledge from inside the company - it is surprising how many interesting approaches are there!

The other aspect here is that if the staff brings in ideas for improvement, there is a higher acceptance of these suggestions. To integrate these improvements would be much easier and more successful, than suggestions made from the outside or top-down. Even those who try to avoid any kind of change would probably be more willing to try out something suggested by a colleague, rather than suggested by the management or a third party.

But also, employees need to learn that management has a certain role within the organisation, and sometimes they also have to bring in suggestions for improvements or request coming up with ideas. It is also important that employees accept the management’s role; this means not only does management have to trust employees, but also that employees have to trust management!

It is also a task for the team and every individual. How does everyone react when a colleague comes up with an idea? Are they annoyed by ideas, or open to discussing them? Is this a more a “This doesn´t work anyway” mentality, or more a “Let's see what we can learn from it?” approach? Reflect on your own reaction when someone bring up an idea, and also reflect on this as a team - maybe during a retrospective!

Whenever we become aware of the blame game, that someone is trying to cover their ass, or the lack of focus on a shared goal, we should address it! Don't let the elephant in the room grow into a more severe issue. But also avoid constant pessimism - because no one will take you seriously after some time.

DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital to DevOps! If we all follow these ideas, we will create not only high quality products or services, we will also create a high quality workplace and a pleasant working atmosphere where we can focus on what we really want to do: doing a great job!

About the Author

Sabine Wojcieszak, a consultant at getNext IT, and calls herself an “agile and DevOps enabler”. As a coach she helps teams and organisations improve their teamwork and their communication. She enables people to work in an agile way or to adopt the DevOps mentality, and focuses on the human part of such changes. Wojcieszak is a well-known speaker at international tech conferences, author of several articles, and one of the DevOpsDays Kiel organisers. She also lectures on the topics of APM, DevOps and Open Source at University. Twitter: @SabineBendixen