Share The Pain, or how to make a digital team work

In this article I deal with a topic that is very close to my heart which is also one of the most counter-intuitive ones, especially in the digital field and in the management of platforms and digital products.

In fact, a concept that I often repeat is that technology is all in all easy, if we compare it to the real problem that is instead that of people.

Intended as: managing the technological aspects of a digital platform is the least problem compared to managing the people who make it work.

In spite of what many non-experts think, a digital product does not stand on its own and it is necessary to evolve and correct it continuously.

We are not yet to the point that there is an artificial intelligence that programs itself and manages the infrastructures that host the code, and in reality I do not think that in a few years we will ever see machines that do all these things alone because the digital technology is heavily based on an intellectual and creative process that is still far from being modeled in the form of artificial intelligence.

We must therefore take note once and for all that when we talk about digital, we also talk about people, with all the necessary problems: communication problems, personal problems, interaction between colleagues, team work and so on.

So what happens? That in your company you find yourself with a whole series of recurring problems, maybe you get stuck but you have a series of problems that are always present and countless technical aspects to manage in daily operations that take away time and energy hindering the development of the ‘company.

I mention a few:

  • Despite the large amount of time and money you have spent, the code of your digital products is full of errors and the systems are unreliable.
  • The new version put online breaks the parts that worked in the previous version or the same errors of months before reappear.
  • Production incidents often occur that cause traffic, revenue and reputation to be lost. And thanks to Murphy’s law, accidents often happen when there is no one else in the office to be able to solve them or the person who takes care of them is not there.
  • Or it is enough for one of your programmers or a key systems engineer to fall ill, which is a completely foreseeable eventuality, to cause serious damage: if nobody is able to decipher his unique system of work, you can find yourself facing the nightmare unprepared of technology. When it happens then you think “but where the hell did that script put it?”. In the meantime, the problem cannot be resolved.
  • Or those who deal with the development and maintenance of the technological aspects and the people who deal with the business do not understand each other, the result is that you waste a lot of time, argue and maybe the final product is not the one you want and is often full of unnecessary features.
  • And so on.

And as far as the method used to manage all these aspects can be advanced, there will always be frustration of the client in seeing a certain share of problems that remain.

The final solution is to outsource all the technology, but this does not detract from the fact that we are talking about something that is not perfect and will never be, some problem will always be there, rather the way in which these problems are addressed.

We therefore have to deal with the fact that for example bugs, that is software anomalies, are something that is part of the very nature of software development. There will always be.

Now that the role of people in technology is clear at least a little more, let’s see some useful concepts and methods to reduce a large part of these problems by focusing on human beings rather than computers, and therefore on the team in which these people work.

There are in particular some working principles and practices, some of which have been formalized several years ago in some methodologies, that is, methods to be used in one’s own working reality.

Here, too, we must realize, on the business side, that to make a digital product work, it is not enough to put together some programmers, of whom perhaps a manager cannot even understand the skills.

In other words, there are no single computer genes that are able to make everything work in a complex system such as a digital platform, a team is always necessary, often even very large.

It is therefore also necessary to properly organize the work by applying specific practices, which does not mean, however, putting activities together in a GANTT chart, thinking that it has magically solved all management problems.

Technology in computer science does not work like that at all, it is not like building a bridge with precise calculations, it is much more complex and it is also very dependent on people.

And it doesn’t even work to introduce a spot intervention with a coach or a motivator, the motivation does not introduce itself from the outside in that way: it lasts maybe a couple of days, then it becomes lower than before, as well as the typical improvement initiatives carried out in these cases they last a few weeks and are systematically dismantled.

I have seen too much of these implementations made with the best intentions, with great costs, failed miserably after a short time.

I will speak more about this on another occasion, for now it is important to know that one of these methodologies with which to organize and carry out the work in a much more productive way is called XP, that is extreme programming, which among the various practices proposes that called “Collective ownership”.

The name of the XP in turn seems rather extreme, but it is not something for software rebels, just as collective ownership does not mean code communism but something very serious.

The opposite of this concept, which is the traditional way of managing code, is to define a strong “property”: the application is divided into modules and each module has its own developer.

In this context, developers can only edit the code of the modules they own.

If someone needs to make a change to a module written by others, they must contact the programmer assigned to that module and ask him to make them.

There are also intermediate forms in which modules can be edited by other programmers, but there is always a manager for each module.

In collective code ownership the concept of individual ownership is completely abandoned. The key point is that the code is the responsibility of the whole team, and anyone within the team can edit it.

This concept should not be confused with absence of ownership, which would mean that no one is responsible for the code. The opposite is true: the whole team is responsible for it.

This works very well when tests (functional and unitary) are also provided, so as to make sure that changes made by a programmer who knows little about a certain area of ​​the code does not introduce new serious errors.

In conclusion, this is an important practice that must be adopted by every self-respecting digital team.

Now, it must be considered that these rules must also be applied more generally, not only in the code.

For example, since the technical aspects must be considered as common property of the whole team, not only must the concept that anyone must put their hand to improve or solve problems, but also the concept that when there are problems in production within a few minutes Before the lunch break, colleagues who are working on the resolution of the accident should not be left alone as soon as they take 1:00 in the clock.

Everyone must help, especially those who can somehow make their skills available.

Here, in particular, the separation between systems engineers and programmers typical of many teams, which instead must work as a single body, must be overcome.

From this point of view I like to extend the whole concept, starting from an engineering practice in the world of software such as collective ownership and coming up with a broader topic that must be part of the culture of a company, even at an entrepreneurial level.

I call it “Share the pain”, that is, sharing the effort, sharing the pain, even between separate teams and also in the relationship between customer and supplier, when IT is outsourced.

This is why in more technical terms we speak of collective ownership, that is, anyone can and must join hands with other colleagues.

The point is that a shared weight is automatically a lighter weight.

Knowing that you don’t have to face a daunting problem on your own makes you act more confidently and creatively.

The approach to work must make it easy to be able to ask for help, to rotate responsibilities among multiple people and to have company when an extraordinary effort is needed to obtain a result or solve a problem.

Even simple things matter: take away the trash, answer the phone and so on, anyone must help even with these often small and undesirable activities.

Then of course there are those who are specialized and perhaps have among their duties that of carrying out exactly those activities, but the point is to make it clear that there must be an attitude for which certain things should not be simply dismissed, maybe even in a polite way but in any case out of this spirit. At a minimum you have to support each other.

All the more reason this applies to making a digital product work.

To understand each other better, when something does not go as planned or there is a very short deadline, and this happens practically always, we should all strive together, each in the way it can contribute.

The work of each is not limited to completing their activities within the deadlines, but also includes supporting their companions in some way.

When a project is going well, we are all going well. When a project has a problem, we all have a problem.

We don’t let anyone have to endure big mange on their own. If anyone needs to work late on a project, let’s help.

In every project and in every company the job includes having to carry out frustrating, boring and other broken boxes that simply have to be done.

These are to be considered by everyone the work of each.

It also means taking time to do what isn’t necessarily your job, something that maybe another person should normally do but can’t for some reason.

And this by doing it without necessarily being asked. The work is done, although not by the person assigned to this task, and customers are not left on hold.

Sharing the effort therefore allows you to be more productive because it eliminates bureaucracy and reduces stress.

And it is essential to feel supported by colleagues, who cover you when there is some difficulty.

In this case, the spirit is like that of a group of soldiers who advance covering each other by enemy fire and act together to conquer a goal.

If you cannot trust your colleagues and you are not sure that they will cover you or help you when you are in difficulty, then there is no team.

Related Posts

Leave a Reply

Your email address will not be published.