Sir, your team is not a team

In my 12 years of experience in software development, I was lucky enough to work in a team only twice. Although I changed about ten jobs. But having tried it once, eat it now ... Since I'm not greedy, and I am ready to share my achievements with the community, then I decided to make an attempt to disbalance stupid managers who still did not realize the importance of the team, as well as those leaders who professionally engage in self-deception - they say, they build a team, and really - ugh, not a team.

The context of this article is the development of your product.

Your team is not a team

• If no one has ever called - the director of the goat or PM - a - dead ballast or company - a bunch of parasites - you are not a team. In each company there are problems, because of which many are itching, but if these “many” do not talk about problems, then the fourth industrial revolution will pass you by. The lack of free expression of opinions leads to the adoption of problems for granted and the loss of critical thinking. Do you spend retrospectives at all? Nooo? I would be ashamed to call you a leader.
• If you decide for the employees how to work for them - you are not a team. Are you running a git flow on top, a list of task statuses, working hours from 9:00 to 18:00? It seems that you simplify your life by not trying to find the right solution in a particular situation? Or maybe to report to the leadership on the transition to git flow? Ohhh ... yes you are a formalist. Only the team itself knows under what conditions it can work efficiently and only the team itself knows what tools they need for the job. If you impose your rules against the will of the team, you are not a manager.
• If your employees do not know the mission of the product and / or the immediate goal - you are not a team. Your employees cannot take a step without you, they just sit exactly on the pope until you find out about it and give them an extremely precise task. Well, perhaps your strength in micromanagement. Just kidding, there is no such force. Please have fun. Make room for a professional.
• If you do not know the goals and interests of your employees - you are not a team. Vasya Pupkin quit? Do not know why? Money, probably, somewhere more offered? Understood. Petya Lastochkin is watching anmeshka for days? Do not know why? Maybe because you gave it up to nowhere? How are you going to motivate your employees if you do not know what they need? None? Ah, you pay them a salary, but they must motivate themselves ... well, pay further.
• If you are afraid of trusting employees with responsible functions , you are not a team. Yes, we already understood that your power in micromanagement. But it seems you have another reason for it. That's what I think - dismiss everyone and file the product yourself. After all, to do everything right - you need to do it yourself?

What stage of failure are you at?

And now I will help you to imagine what it is like to work in a “team”, the leader of which gathered all the features of the great generals mentioned above:

• The efforts of employees are aimed at covering their ass, instead of working for a common cause.
• Initiative? Creation? Pfff ... I will sit on the priest exactly until PM comes and gives me a clear task. Even if there are problems in its wording, I will not tell anyone anything, because these are PM problems, not mine.
• A responsibility. Why I did not inform anyone about the problems in the formulation of the problem? I am not required to do PM work. Find a PM that always does everything right and roll me away — I’m the code.
• Making great decisions. Why I did not provide for scaling? Was it necessary?
• Guys, we have force majeure, will you be able to linger for two hours, is it very necessary? I do not want. Your force majeure - your problems.
• Deadlines are not met. They are reduced to the limit. After all, the harder you hit, the faster the programmer writes the code.
• Terms are unpredictable. internal quality ... And what is it?
• You get a hat from your leadership and hit the cap of subordinates.
• Death no longer seems like a punishment.

A wonderful world in which you will never live

I lived in it, and many of you will not even see it with my own eyes, but I will try to help you look at this world with my eyes:
')

• We are not afraid and even love to express our opinion. Yes, it hurts, but pain makes us move forward.
• We are not silent about the problems. If someone tries to hush up the problem - we stop respecting him and we can easily step over his head when solving a problem.
• Our actions are subject to a common goal. If tasks run out, we always know what should be done and when. We set ourselves the tasks themselves. Although there is no such thing that tasks end.
• The overall goal is formulated in a way that takes into account the goals of each. More or less. If there is a person whose goal hinders the achievement of a common goal - he leaves the team.
• Leader is just one of the project roles. His main task is to create conditions for work. Orders are allowed only in force majeure cases. But in general, no, they are never allowed.
• Cult of quality. Quality is free if you do not save on it. Let me explain: it is the poor internal quality of the product that gives a slowdown in work and unpredictable timing. Therefore, the leaders who drive horses - well, you understand.
• Continuous development. The person who stopped development is not needed in such a team. Even reading articles is no longer the key to your successful existence. Reading books has long been mandatory.
• Do you guys come to work again on Saturday? And Nuk went to rest! And ... orders are not allowed? Well, as you please, but try not to save fatigue.
• Deadlines are always met.
• Get a hat? For what? I am the second person after the gene. a director who thinks about the good of the company. He appreciates that.

findings

• Products that are not developed by teams will die a painful death sooner or later. Yes, all products die sooner or later, but some of them - a natural death, and some - from diseases.
• It's nice to work in a team. Less energy spent on the experience, more - to work.
• A team is an inexhaustible source of strength and motivation.
• A person working in a team is constantly increasing in value. Teamwork is beneficial for each participant.
• Learn or lose.

Let off steam

The article describes the ideal cases that do not exist in the real world. But I still say that I worked in an almost perfect team. And I built one very good team with my own hands (and head).

I hope I touched the subtle fibers of your soul and you feel uncomfortable - rejoice, you can use the current state to look at yourself from above and see the path for development. If you still do not conduct personal retrospectives, then start right now: the last project, the last job, you may want to look at your whole life.

PS: I confess, I also once created a “team”, practically ideally disgusting. I described some of my negative experiences in my first article .

On read

• The human factor: successful projects and teams. Tom DeMarco, Timothy Lister.
  This book made it clear that the main task of a manager is to create working conditions, and not to distribute commands.
• The perfect programmer. Robert Martin.
  Uncle Bob is very categorical in defining the concept of responsibility, but is it possible not to believe him?
• Help them grow or watch them go. Beverly Kay, Julia Giulioni.
  This book helped me keep my focus on motivation.
• Scrum and XP: notes from the front. Henrik Kniberg.
  Very brief and practical book, she told how specifically you can build agile.
• Impact mapping. Gojko Adzic (I can't imagine how to write in Russian).
  Here I learned the importance of goals, and also received information on how they can be used.
• I highly recommend to pay attention to the Aristotle project - Google research on effective teams.