I started my career as an administrative clerk at the major English school in Brazil's capital city, Brasilia. I had to perform a lot of manual tasks to control financial status for each student monthly. I also helped teachers fill in the student's scorecards every two months as well as at the end of the semester, which involved some different calculations for each class level. Every team member was doing their best to finalize everything on time, as all teachers were going crazy around to make sure all report cards were OK.
I did everything manually and decided that it was not the best approach. I wanted to try something different. I was 21 years old at the time and used BASIC to program games at my dad's very old computer for fun. Using that very shallow knowledge of IT, I developed a series of programs to improve the end of semester routines for the school, and it was a huge success. That's when I started my first "digital transformation": 1989.
From that moment on, my professional journey was linked to a series of transformation efforts: digital, agile, finance, strategic, etc. I learned all about project management, software development life cycle, process management, corporate strategy and control, performance measurement, team management, and change management. I collected various success cases and a lot of failed ones. It was a truly professional and personal roller coaster, emotionally speaking.
At my Accredited Kanban Trainer sessions last December in London, I had to draw my path to become a Kanban Trainer and realized that I was a Transformation Professional. Having performed numerous management roles and being labeled with all types of corporate positions, one common feature of my professional career was to participate in organizational transformations. But the major transformation was my own.
All those transformations were different from each other but had some similarities too. So, I ended up developing my own, evolutionary way of approaching change in organizations to help them endure those initiatives. I want to share with you some of the lessons I learned.
Context Is King
I found out that all functional transformations should have a clear vision of where you want to go. But the objective of the change should not drive the approach. Instead, the context of your organization should be the leading factor.
If you are in equilibrium, meaning that your organization is delivering at a constant pace, your customers and teams are happy, and the business is good, maybe you don't need a change at all. In such a stability mode, an environment of relaxation could be the case. The thing is, that wouldn't last for long, though. Maybe equilibrium is making people unhappy and you are in inertia mode. That's the start of a transition to a necessary change.
Crisis is not always dramatic when you need to promote structural changes, do things completely differently, hire consultants and leaders, and fire your current managing staff. That is a possibility, but mainly I found that the crisis comes slowly as an incremental dissatisfaction from one of your stakeholders. Here you have an opportunity to add some normative changes, review policies, and create some stress in your team so they can anticipate a real need for a change.
Start with What You Do Now
Regardless of the situation, it is best for you to keep doing what you do today. Visualize your work, your flow, your policies, and use continuous improvement mechanisms to make small controlled changes in the business. Eventually, they will cumulatively generate the big change.
No need for creating new structures, jobs, and roles. If they are needed, they will be pulled by the organization at the right time. Structural changes build resistance, and that is something you want to avoid at the beginning of your evolutionary organizational change.
The Kanban Lenses
If you are doing something, it is because you have a customer that needs it. Therefore, your job is to make sure that the execution happens in the most efficient and effective way possible.
Whenever you start a transformation, make a link with your customer and their purpose. The connection between their needs and happiness is made through a flow of networked services - the activities your teams perform to add value.
You can call it a value stream. Every single component of the value stream needs to understand the customers' needs, which it is trying to supply. Having this understanding will create a powerful effect on the productivity of your team. They will connect with the customer and take fast decisions on how to better deliver the service or product.
Stress Your Value Stream
Improvement tools should be used according to your company's maturity. Stress should be generated to the point of causing the least discomfort that causes the desire for a change.
Say you build a board that shows how the work process is flowing from request to delivery, and there is a bottleneck in the middle of it. Visualizing the bottleneck will create stress for people working on that activity. The steps before the bottleneck will have to slow down, and the ones after it will starve soon.
Beware, though, that you should not stress the process to the point it breaks. What you need is the right level of dissatisfaction, in order for the desire for a change to emerge.
After the right amount of stress is generated, it is necessary to create mechanisms for reflection so that autonomous decisions are made, and the dissatisfaction is resolved. When the people involved in performing the tasks pull changes in the work process, they will not resist them.
That is the most important aspect of the evolutionary change in organizations. You avoid resistance by going around it and letting people decide together what is best for them.
Having Agile interactions that promote mature discussions about what and how work is done should always occur. Create structured opportunities for this process of inspection and adaptation to happen in a cadence that is comfortable and does not interrupt the work at hand.
Changes don't happen because you have ideas. We need acts of leadership at any level of the organization for these changes to occur. If employees are empowered to improve their way of working, you will end up not having to escalate every decision to top-level management. Therefore, changes become natural.
Innovation comes from this safe environment, where ideas can be discussed and acted on without asking for permission. Everyone can be a leader, and the effect of that is ownership, accountability, and resilience.
Experiments to Evolve
All changes must be an experiment.
There are several models to start with, and proof tested practices for every maturity level. But they must work for the context you are testing them in. They are, in a sense, accelerators.
Use them and adapt to your reality. Focus on what needs to improve and measure before and after the experiment. This will help you separate what works and what doesn't. Experiments that work help the organization evolve, and those that don't, help it learn (and still evolve).
Continuous System Thinking
Think and analyze your service as a complex system, and do this analysis continuously. Now and then, you should evaluate and test the basic information of your network of services. The faster you change, the more the parameters of your system will move.
Maybe the customer purpose has changed, maybe your capability evolved. Maybe you have new classes of service, that is, new forms of prioritization.
You need to avoid evolutionary plateaus, continuously trying to improve separate flaws and building small J-curves to achieve a vision. Perhaps the vision changes also, or you have already achieved it.
Don't stop there. Success is a bad teacher. Evolution doesn't have a finish line.
Leverage Your Flight Levels
It is best when your transformation effort has all support from the executive team, and everyone in the company is involved. Strategy levers are powerful enough to promote big changes. But that is rarely the case.
Most of the time, your span of control over the transformation is a small team, a restricted area. Still, evolutionary change works just fine. And as soon as the smile on your team members sparkles, they will contaminate the next area or team and so on.
Team agility is different from business agility. However, we have to use the lever available to us so that we can work on the connection between the levels.
Maturity to Trust
The ultimate goal of a transformation is to build a highly reliable organization for your customers, suppliers, and employees (for the whole value creation chain). The way to do this is to evolve the organization's maturity.
Maturity to trust makes behaviors and practices endure all kinds of crises. Practices are just one aspect of a culture. If maturity is not present, practices will go back to the previous comfort level as soon as a crisis strikes.
The organization's social capital must be understood and transformed as well so that culture stays firm even in the presence of the unknown.
If you try to revolutionize your organization, it may work. I have tried it sometimes, but it worked in the right context, where revolution was the only choice. And it caused us a lot of pain, unforgettable and unforgivable pain.
It also costs a lot more in comparison with an evolutionary effort. You don't have long diagnostics and planning stages to start with. You don't have to change your change promises because you can't anticipate the future.
Eduardo Arcirio is a transformation practitioner with 25+ years of experience in management and strategic positions in IT, services and consulting industry, specializing in Lean/Agile change management and corporate strategy. A free thinker with a special taste for visual thinking, Eduardo became an Accredited Kanban Trainer and Coach Professional.