In the spring of 2008, all employees of the company I worked for gathered in the auditorium to hear about the company’s business goals. At the end of this festive event, we were asked to step out into the lobby and find ourselves on a giant organizational chart, some people seeing that they had a completely new position. It was my first major organizational change. From this experience, I learned something extremely important: how not to implement changes in an organization.

I have worked in four tech companies for a total of 17 years. In the first eight, I was an individual contributor who managed processes and projects, but not people (at least not formally). Over the past nine years, I have held various leadership roles and have been responsible for the efficient functioning of processes and structures. This means that a large part of my attention is focused on the surrounding mechanisms and less on myself.

In these cases, ideas for change do not wait long to emerge. They can be as small and defined as “Let’s switch from Scrum to Kanban, and everything will definitely be much better!” or as large and far-reaching as “Let’s merge teams X and Y, divide teams Z and W into three, and everything will definitely be much better!”

Nobody likes change

When I joined Glia, I was surprised by how well the company’s systems and team operated. Then I did a double-take, realizing the company became a unicorn for a reason. However, upon closer inspection, I began to discover potential organizational bottlenecks that could negatively affect us in the future. I dedicated a good chunk of time to assessing the state of affairs. And to that end, I had numerous conversations with people.

The company had structured its R&D so that each team had a product manager, engineering manager, and technical lead, which is a common setup. However, it quickly became clear that the responsibilities divided among these roles were not entirely fair to the technical leads or the engineering managers. Technical leads were burdened with too many tasks, while the engineering managers were left somewhat short-handed. Three months later, the engineering managers found themselves in a situation where expectations had significantly increased for them, while the role of the technical lead had become a thing of the past. Figuratively speaking, the situation looked like this:

Before

After

In software engineering, management can be divided into three broad pillars — strategy and processes, people management, and software creation. The above diagram illustrates how different roles at the company relate to these three pillars. In the “Before” diagram, it can be seen that the company had a situation where technical leads were operating in a “danger zone,” where they were responsible for a little bit of everything across all three pillars. In other words, a direct path to burnout.

Additionally, the engineering managers were quite distant from everything except people management. Further, each product team had two leaders. The engineering managers felt their role was light, and the rest of the organization didn’t quite understand why each product team needed two leaders.

In the “After” diagram, the redistribution of responsibilities is visible. In the new order, the role of the technical lead, which resided in the danger zone, disappeared, and its core responsibilities (architecture, standards, team technical coherence) were distributed among senior engineers in the team.

This created a situation where people could take more ownership of the services in the team’s portfolio. We moved the engineering managers closer to the strategy, handing them the keys to the teams and putting them in a position where they have to make significantly more decisions about the team’s direction.

How to start with implementing organizational changes?

When we talk about organizational change, it directly and significantly impacts the work lives of certain employees (but not necessarily everyone’s). It’s not a new coffee machine in the kitchen or planned team activities, but rather things along the formation and dissolution of teams, process, and structural changes. Things with a lasting impact.

When planning changes, the problem statement must be clear, unambiguous, and fact-based. The leader making changes must be 100% convinced of their necessity. Otherwise, the proposal will fail before it even starts. Even in their sleep, they must be able to answer how things will improve.

I had written down six key points for the problem statement of the change, which were detailed enough to explain them within the organization. This was followed by a specific proposal on solving the given situation and the associated benefits once the change is implemented. It is also important to identify potential risks and hidden threats that may come with it. This allows for reasoned discussions with those who are skeptical or negative about the new situation.

I am not religious about any practices and processes in my work, but I draw inspiration from various methods and sources. In implementing this change, I combined lessons from my previous experiences with elements of the Nudge theory and the ADKAR method. Both frameworks have many good ideas, but blindly following them does not always lead to the desired results based on my experience. Best practices must always be adapted to the company and situational context. Following a process for the sake of the process is the death of creativity.

Communication

After writing the proposal, I had face-to-face discussions with each individual who would be directly affected by the change to gather constructive feedback. This is the most important detail to take away from this article— if one-on-one discussions are not done, and one immediately jumps to addressing groups, the likelihood of the change succeeding diminishes, and the opportunity to build relationships goes unused.

During my conversations, I kept the door open for objections and encouraged collaborative thinking. While such discussions may only sometimes reach a complete consensus, listening to and considering feedback from people is extremely important. Based on these conversations, adjusting the proposal details and building a further dialog with people is possible.

It is important to note that, regarding the problem statement I presented, there were no significant objections from anyone; in fact, it was understood why this change is necessary. Clear and reasoned communication certainly contributed to it.

Although the process was time-consuming, arguing against the return on investment is difficult. Ultimately, all social groups are based on trust, and when executing changes, it is possible to strengthen mutual trust. In my own experience, as a new person in the organization, it allowed me to build relationships by being transparent and honest about my intentions.

Execution

For implementing any change, it is necessary to have supportive documentation and a communication plan. (As we’ve written in the past, you can’t YOLO the communications.) This change meant new job descriptions, explanatory documents outlining the reasons for the change, and a clear presentation. Sometimes, even if the idea is good, insufficient preparation and poor communication can have painful consequences for a company. I advise having different people critically review all documentation, asking them to be brutally honest and open.

It is important to explain to all stakeholders what is happening and why. Even though people who are most affected by the change have been informed in advance, public communication must also be conducted throughout the entire organization, unpacking it humanely and addressing any questions that arise.

Success criteria and measuring

To measure the effectiveness of any change, it is important to have a clear timeline, success criteria, and metrics. Five success criteria were validated multiple times over six months in this particular change. It is easy to change in a “fire and forget” manner — to announce something and then pretend it has changed. The challenging part, however, lies in quantifying the impact of the change and learning from it after several months. To assess the impact of this change, I monitored several metrics over six months. Currently, there is evidence-based material on the following aspects:

• General attitude of engineers towards the changes: I recently conducted a survey among the engineers to get an idea of how they perceive the changes daily. I asked them to assess both the overall impact and positivity. 64% of respondents rated the impact of the change as very positive, 28% as positive-neutral, and 8% as negative. I was satisfied with these results as the context of additional questions showed that for most engineers, the change has brought about daily positive effects, particularly increased engagement, and ownership.
• Stress levels of former technical leads: Four out of five tech leads (80%) have expressed in conversations that this change has positively affected their stress levels. The ability to focus more on details and worry less about the overall functioning of the team has resulted in more fulfilling work weeks.
• Capability of engineering managers to influence things: With this change, engineering managers’ role has significantly increased. We have given them clear expectations that they are responsible for 100% of team productivity (and the related strategy). Additionally, engineering managers can influence development project priorities, resource allocation, and much more. As a result, at least four teams under the leadership of engineering managers have already made changes to work processes and organization to make work more efficient and meaningful.

There is still a long way to go, but even at this stage, the change is justified.

Empathy plays a key role

Every organization strives for process efficiency, rapid productivity, high quality, the best cost-effectiveness ratio, and all that corporate goodness. Generally, changes focus on improving things and increasing growth and profit. This is true and understandable, but changes must be made on empathetic grounds, leading to longer-lasting and far-reaching impacts while minimizing the collateral damage.

I still remember the feeling of searching for my name on a giant organizational chart 15 years ago. Such situations leave a mark, even if something seems trivial to those initiating the change, it may mean a drastic change in someone else’s work life. The only constant in life is change. And in international business, change is inevitably necessary because we must adapt to the rapidly changing environment. However, the question is no longer whether changes are necessary; it is more about how to implement them to keep both people and the organization intact.

Empathy builds trust.

About the author: Martin Sulg has worked as an Engineering Manager, Product Owner, and VP of Engineering at Microsoft and Fortumo Mobile Payments (today Boku). Currently, he works as a Senior Director of Engineering at Glia.

The Role of Empathy in Organizational Changes was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.