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
- The new version put online breaks the parts that
worked in the previous version or the same errors of months before
- 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
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
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
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
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,
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
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.