Get best of the week

Why do people resist change and how can they help them rebuild

June 8–9 TechLead Conf . This is an online conference on engineering practices and processes. We will discuss in detail how to develop without bugs, how to work with legacy, how to ensure that MVP does not become a technical debt, how to choose practices depending on the problem.

But we know that the most good undertakings are broken about the power of habit. You do not need to be a developer in a technology company to experience this. Remember how annoying changes are in the interface of your favorite applications, even if later they turn out to be convenient features.

To come up with a process that will improve the quality of a product is one thing, and implement it in such a way that it really benefits is another. It’s not enough to say: “Guys, I know how! Do so, so and so. ” In order to understand what technical tricks can be expected on the path to implementing change, we talked with Dmitry Maslennikov from Tinkoff . And already at the conference Dmitry will tell what needs to be done so that the changes take root in the team.



- What is the problem with the implementation of changes in general, why is it not enough to say how to do it?

We constantly have to implement something. Whoever you are, starting from an active team member to a tech team or manager, you have to influence your colleagues all the time so that they do something differently, and often also synchronously. Most often this is done on a hunch, because engineers mainly study technology, nuclear physics, algorithms, mathematics, but very rarely learn how to work with people.

And indeed this sphere is incomprehensible. There are no exact answers: all people are different, everyone has a different background and cultural characteristics. Therefore, it often doesn’t work out very well.

From my own experience I want to tell you how to implement changes as efficiently as possible. I have a lot of practice, and now I do just that: I force teams to do something differently.

“Are we talking not only about processes, but also about tools?”

Yes, I include the introduction of tools here. For example, once upon a time I implemented Git. Now this is the mainstream, and there seems to be nothing to introduce here. And once there was SVN, and to implement Git was that still a task.

A tool for me is a broad concept. In my understanding, pair programming or code review are also tools. I also include practices here, because, it seems to me, these are approximately the same thing. A tool is the practice of using this tool.

- So, the introduction of a process such as daily meetings is not very different from the introduction of a development environment?

Right. For example, I promoted environments on Google because it’s more convenient to write code with them. But when it is more convenient for the developer to use vim and emacs, try to convince him to change the environment.

- Why do people so dislike change? And even in those cases when, it would seem, best practices are designed to save time and energy.
There is always resistance - this is a basic principle.
There are changes that go easily: on the thumb track. But sometimes the changes will be just to stop the changes that are on the thumb. But to jump from one track to another, change direction, it is very difficult.

And this is true in everything. If a person is used to running, then he runs, and try stopping him. And the other is used to not running, so try to force him. Both that, and another are changes. Despite the fact that the one who runs regularly, probably without any problems will be able to go in for some other kind of sport and this will be an easy change for him. And for someone who wasn’t running, an easy change, for example, is to start playing a new video game. But it will be very difficult to get the runner to play this game.
I understand the changes in how a task jumps from one path to another.
Of course, changes on the thumb, when people only need to be pushed, are much simpler than changes that significantly change the usual way. But sometimes the latter are needed, and gradually they will not succeed.

The way people in the company respond to innovations, including the culture of the company. For example, in the West quite often it is in the company's culture that all opinions are important and everyone needs to be heard. It really helps change. And in Russia it often happens that when you propose to do something in a new way, a ton of criticism immediately falls upon you. If a person does not know how to withstand criticism, then he simply becomes silent, and no changes occur. In the West, change is usually easier because at least proposals are heard.

- Is it always possible to build an iterative process for introducing changes? And will the movement in small steps only interfere, because it will be easier to slide back to the old order?

Sometimes it’s very difficult to take a big step right away and you have to break the implementation process into small stages. For example, now we want all teams to automatically and automatically read SLA. I gave them a start-up training, but only the three strongest teams out of eight made the SLA calculation for themselves. It became clear that you need to help teams and first develop tools, give a technique.

Again, it very much depends on the teams that are mastering the new. You can again bring a sporty analogy. If an athlete, a swimmer starts to run, his progress and steps on distances and loads will obviously be greater than that of a person who has not been involved in sports before. There is no point in referring both of them to the same category of “novice runners” —they have different training.

So in development. If this is a cool team with highly professional engineers, who also have well-developed soft skills, they most likely understand the need for change, and implementing anything will be faster and easier.

When making changes, you need to understand who you work with, which team, how ready it is, what they already know how to do.

- Who should initiate changes, and who should introduce and maintain? Necessarily the same person?
I believe that everyone who cares, regardless of job level, should initiate the changes.
I highly encourage any innovations. Western companies do this with a new sauce, but our culture has historical roots - rationalization proposals. Any employee could make a suggestion, and if it was beneficial, then the employee was encouraged.

If a person is sure that this will be better, he should try to achieve change. Not the fact that it will really be better - everyone is mistaken. But if there is a desire and energy to do this, then you need to try. And with my report I want to tell you what you need to think about before proceeding.

- In order to implement something, is it necessary to have special powers and use the administrative resource?

An administrative resource is simply one of the tools that can also be used sometimes. If you use it too often, it will lose power, there will be a lot of discontent. But sometimes you can’t do without it.
It is rather important to note here that in any case, the introduction of changes needs control.
If you implement something only in your team, then it’s easy to control - you immediately see how everything goes. And when the changes are more extensive, control becomes costly, but without it in any way. At least because they will understand incorrectly, they will not apply as intended, and without control it will not even be clear.

I often observe the law "If something can go wrong, then it will go wrong" in action. On the contrary, glimpses when everything went this way are so rare and perceived as a miracle. And normally you need to prepare to control.

Control is not in the sense of administrative endless reports (although sometimes it is). It is necessary to check whether everyone understood that whether everything is done and whether it is done at all. If you do not invest in it, then everything will definitely go wrong.

- How to track that, for example, colleagues seem to show the fixation of something in a special form, but for themselves, as they wrote in Google docks, they write like that? That is, the proposed tool is used only to report, but not to make it more convenient for ourselves.

Google Docks win by convenience, and I myself use them with pleasure. But, if necessary, you can replay this convenience with small tricks.

A great example of such a trick that imperceptibly allows you to change people's habits, you can peek at Google. When the company wanted their employees to consume less harmful sweets less, they replaced the refrigerators with those in which the lower part of the door was opaque and the upper part transparent. They put juices, plain water and fruits upstairs, and removed all the chocolates and soda so that they also had to bend down. Of course, this worked, and people themselves changed their behavior.

With working tools, you can also apply such tricks. Google docks are essentially the same refrigerator you don’t have to bend into: it’s very easy to fumble, it’s convenient to edit, etc. This convenience works against the introduction of any new products. But you can apply the same tricks.

For example, now many have begun to work remotely. Almost all of our employees also work remotely, and the question arose of how best to follow them: to understand whether they are busy or whether they are busy. This was not necessary in the office, but it was needed here. We considered different options, and among other things, I suggested writing daily reports.

I suggested a specific format for reports, wrote a small toolkit that this format would then beautifully display, I tried to make it convenient to use. I introduced this practice in teams that I control. I read all the reports at least once a week, gave feedback to everyone, what’s so, what’s wrong. And in two weeks the process got into a rut: everyone writes everything, no complaints.

Then I proposed the same scheme to my superior leader, and he lowered it to other teams, but did not control. As a result, everyone reinvented their formats, no one began to adhere to a single format, even within the team. Due to the fact that there were no tools to control the format, moreover, no one complied with any format. As a result, it didn’t work for anyone, only my employees continue to write reports, without negative.

It's all about control - it was not in other teams, so nothing happened. Moreover, the control is not to punish for non-compliance, but that I did not care, I gave feedback. Therefore, some of my team even liked this practice, and the rest did not experience any inconvenience and said that it was more convenient than in Jira would make worklovers write.

Another favorite example of mine is how we implemented post-mortem. In Google postmortem written in google docks. They don’t need anything else, because post-mortem is essentially a document that is necessary to be convenient to read and fumble, easy to assemble in a directory with links. We implemented postmortem writing on wikis - in principle, this is about the same. But everyone was ready to offer something, tell what is inconvenient, and say what needs to be improved. Only no one has improved.

In this case, in the end, we had to use the administrative resource and push those who disagree. The administrative resource was that in the event of any major malfunction, the technical director was ready to explain to everyone why post-mortem is important in principle, why in this format, using such tools. This was a serious matter and we took a tough stance.
In some cases, a tough position is indispensable.
Otherwise, there will be a booth, the details will be discussed until everyone gets tired of doing this at all and everyone returns to their usual rut.

- It seems that if the changes are significant and greatly change the usual order, then they require effort from all participants in the process. Have to tolerate or is there another way?

Almost always have to be patient. It seems to me that, therefore, my report will also be useful to those who are the “victims” of change. So that they think that everything is not just and that sticks in wheels are not good. I myself used to be like that, but now, when they tell me that something needs to be done differently, I try to first understand why this might be necessary. And how to help, or at least not to interfere.

- Is it possible that you endure, endure, when at last it will become more convenient or better, but it still doesn’t become? When is it time to stop and decide that the idea did not work?

Of course, some changes have to be discarded. For example, Elon Musk has been trying for a long time to create a robotic plant, so that Tesla will collect mainly robots. This went on until all the deadlines were broken. As a result, Musk admitted that he was in a hurry that the technology was not ready yet, and made a little more traditional production.

The specific criteria at which point you need to abandon the changes, in each case their own.

In my opinion, there are interesting cases when it is known for certain that for others it works well. I believe that when there is such data, it means that it will definitely work for you too. Often cultural characteristics are cited as an argument, but I do not like such reasoning.

It seems to me that if a person does not like something for religious reasons (in the sense of a fanatical belief in the correctness of certain approaches), then he shows hidden resistance. Then everything will be done so that the idea dies. But if you implement a really useful practice, then time will squeeze.

For example, I recently watched how quite a bit of time helped radically change my mind. One young employee with foam at the mouth argued that it was convenient for him and his teammates to receive a huge pile of alerts on slack. Allegedly, looking at a board with 1000 events a day allows you to quickly understand what is happening with the system. And we tried to convince him that alerts should not work like that: they should be rare and really important. And for ordinary events there should be a separate board that you can see when you need to read something like logs. We argued for a long time and came to such a compromise: we help to make a board, and he tries to use it for a week. After 2-3 weeks, the one who resisted the most, already convinced his lead with my own arguments. There was only enough time to realize that the proposal was really useful.

Of course, political moments can turn on here: how long to experiment, how much pressure can be put on, what maximum negativity are we ready to go, if any. These are gray areas.

I am not talking about such complicated cases. I want to tell you what you should think about when introducing changes to those who have just become a leader. My report will be a good help for those who only yesterday had excellent communication with colleagues, and now his ideas are not very well accepted. There will still be difficulties, but it will be easier to deal with them if you think about the problem points in advance.

- TechLead Conf 2020 8 9 . - , . ++ TechLead Conf -. — :)

More articles:


All Articles