Get best of the week

What mistakes do managers on a remote site

Hello, Habr! I am not a developer, but a manager. For some time I was taught to manage people, and then I plunged into the gloomy world of development, where everything goes wrong, as they say at the university. Now I am leading the practice of managing the software life cycle and I want to tell you a few things that may be important for team leaders and PMs that relate to switching to a remote site. Because in our teams people were already starting to squint so. And then I’ll show and tell about our automation stack for remote, and how we will release releases from the chats on the phone with one button, rather than raising the VPN to a secure perimeter, and this accelerated the coordination, and this helps to coordinate day to day.

The first advice is enough to get your people!



I know it sounds very stupid, but many managers, not seeing people nearby, begin to somehow compensate for their desire to make sure that they work. Here are the chats:


Woodpecker in its pure form.

If there is a task to increase the effectiveness of the team now and in the future, leave people alone. And set the 15 minute daily in the morning. I already managed to see the general project sync once every four hours, and the daily for two hours, and the managers who fell into frustration, who were used to negotiating face to face with someone.

What happened to the remote development at CROC


We switched very simply because we already have a geo-distributed structure of development offices. In recent years, they are used to the fact that the working day of one of the developers can start from 11 pm Moscow time. Accordingly, there were almost no management problems for teams with such participants, but for those who worked in the same time zone, difficulties could arise. For example, one of my teams needed new appointments at Zoom for the synchron, and began to select the optimal time. At first they did it on Monday and Wednesday, and then on Wednesday and Friday, because some of the developers chose to work on weekends and relax on Monday-Tuesday. This is partly due to the fact that they are less available in chat rooms these days.

The second important thing is that we already had tools for connecting chats, trackers, a corporate social network and the entire CI / CD devoop stack, and all this was partially re-linked so that data from one system was automatically transferred to another. For example, we agreed on something in the chat, you can tell the bot to bring it to Jira. And he will skid. If you do it yourself, then you need to go in, pierce all the fields and so on, well, and somehow connect to the protected perimeter. A bot is easier. The most difficult thing is the authorization system. We thought it through, screwed it up and made it more than a year ago.

How it all began.First, everyone switched to a remote site and got used to it for a week. Someone has bad chairs and their back hurts, someone’s children bite their feet at home, someone’s wife was glad that her husband spends more time with his family, and asks every five minutes to open a can. A week settled down tools. Then suddenly the developers realized that they were happy that they were sitting at home. And you don’t have to go anywhere, go nowhere, but at meetings it’s immediately clear who was needed and who was appointed for the sake of the ritual. Well, meetings began to start on time, because there is no reason to be late. Then the managers began to suffer, because communication with the customer turned into hell. We started to schedule regular three-hour meetings (three to four days in a row) in the calendar, just to go through the contract with a lawyer, otherwise it would all hang for months. While it works.

The next step- the question is that developers on a remote site need motivation. Not like in the office. It is very important not to push, it is very important to pose an interesting task and give an image of the target result. Otherwise, there will be procrastination, and the leader himself will project it. Getting out of bed to do something boring is simply physically difficult. Leaders within the project should be given equal scope for decision-making. Our situation is that TK usually does not change, but the power within the sprint belongs to the team, not to the project manager.

Naturally, on the way further you can break pretty funny firewood.

What could go wrong?


Well, first you need to remember that, in spite of the emergency (and he had a lot of people after switching to a remote site), it is better to follow the processes. To one of our customers, we ship a release from our dev to its dev. Sinhro after a pull to them. We shipped the release, they had to conduct integration tests and regression. And keep it in my food. And the next day they write and ask us to roll this release to them in a test environment. Because they immediately laid it out on the prod, and then remembered that it would be nice to synchronize our surroundings. Fortunately, the release did not plop, but, from my point of view, it looks somewhat, unsafe or something.

For another customer, we restored one of the third-party projects after transferring the work to a remote site. Everything is much simpler there: the customer’s experts put the database out, at the same time for some reason set plain text with passwords, also outside. Some young kulhackers hacked it all, naturally.

You probably know about the daily digest with Zoom vulnerabilities and the end of the story with leakage of records. Not all executives (often from the business setting IT tasks) understood what Zoom is, how it works exactly, and that some confidential things are not worth saying under recording. We made a memo for customers how to use which channel. It seems to have helped. At least many older industrial engineers sighed a little looser. And they stopped adding “mydomain.ru” to general conferences, without specifying whether they know this employee.

Another of our customers forgot that there were flowers left in the office that needed to be watered. This we accidentally found out when analyzing threats. Flowers saved.

Meetings with the customer were divided into those where people still wear ties at home and those where you can afford to sit in pajamas. At one of our meetings, the lead developer came out of the bathroom, right in the foam. No one objected.



For those Agile experts who are used to talking, wall stickers, creative collapse has occurred, because now it has become impossible to do so. In many cases, Trello or Miro solved the problem. Everyone has become easier. I enjoy watching my colleagues learn to communicate in a new environment from scratch, and their sociality does not give them such bonuses as before.

A good approach is to record somewhere close the modes of each developer. We are familiar with this because of geography, but additions like “from 16:00 to 19:00 only by phone in urgent cases” help a lot. This is where the request for the request for the dock file and the results of the checks work very cool: you can even do it from the bed, if you want. Because otherwise you will have to wait for the next working morning of eight to nine hours. We try to convey the same simple stack to those customers with whom we work closely, because if we are used to the fact that the document passes from system to system, then the customer's atlasian stack may not be available and it will be necessary to send * .docx files with interim reports.

In a number of teams, there was a problem with the fact that meetings are sent to the calendar without looking at this same calendar. Three invitations can be made per slot, and the slot itself is already occupied. This is also solved organizationally and simply.

Here are our developers say:

They made a bot for the demo - plus to the one to whom everyone is plus. And fine with the children sitting.
— - . , . , , : 10 000 10 , , . , -, , . , , ! , , . : , , , - . . … , .
There is no difference with conventional development on a remote site. Well, you still work with services. A long time ago there was a case when my colleague accidentally nailed a VPN server through which he connected to maintain this VPN server ... With a five-minute window for updating the system, the load suddenly fell off when the application stopped and before the new version was launched (in the era semi-manual updates) ... Or when you run the rm -rf / data commands, and then you realize that you have it productive, and faster, faster ctrl-c.
Smoker's Chatops:



They made a re-release to a colleague who was already released. Nullifying his work. Happenes.

Are there stack examples?


Yes, here they are:

Request Link


Gitlab + timcity

Bots help

Gitlab + jira



gitlab + timcity

Assembly diagram

Development Pipeline Example

This is an example tech chat chat



The devops and CI / CD tools of normal teams have long been worked out. From the point of view of process control, it is important that at each step it is necessary to reduce the number of uncomfortable actions, leaving only useful ones. For example, above you see bots that report on the release status - such push is much more convenient than going in and watching how it is there. But the real value appears when all this allows you to create a continuous process from “discussed the problem in the chat” to “set all the tasks with links to the discussion”, “the task was attached and swept through all systems” to the build, plus all the necessary metrics were removed along the way like self-esteem marks. For developers, this project was a challenge, because usually they write code, rather than draw architectures, write concepts, etc. And if development is automated as much as possible,then for many teams the automation of the exchange of documents or documents is not very well implemented.

Here is an example. The task is considered completed when each row in the ToR will be a working link to the crosstab.

The steps are
:



, . - .

() «»:



. , . - .

- -:



( ) «» ( ). Jira . . «» , . — . . «».

I’m a manager, what should I focus on now?





An important priority is not to quickly share, but to communicate normally. The world has already changed, and now there are two important threats for companies: professional burnout (if you engage in woodpecker management and squeeze people out) and the issue of a complete restructuring of management structures, when teams understand that they can do everything autonomously and with a new informal leader . This may result in the fact that at the time of the end of the crisis the whole team, which was so hard to find and train, will stand up and leave at once for their own project. Therefore, I repeat once again - even if your productivity has fallen, do not get your people. It is in your own interests.

If it’s interesting to discuss the purely leadership process separately, then we are doing a webinar on the 27th at 16:00, here you can sign up. It will be about how you can build the process, various errors and management cases, separation of responsibilities (especially with information security), about document flow between developers, analysts, testers, a little about CI / CD. Well, even if it seems to you that you already know everything, you can do it like a real Jedi - sign up for a webinar, turn down the sound and sit there to do your job!

More articles:


All Articles