A team that walks on its own, or a Product with a Scrum Master can retire

Friends, hello!

My name is Egor Pakhomov, for the last 3 years I have been working at Alpha: developing digital products in web and mobile channels, managing several development teams. Several more teams were collected, organized and carefully handed over to colleagues. At the same time, I had up to 40 employees in my management: analysts, developers, testers, designers.

Today I’ll tell you what it takes to build a cohesive product team.

...well, yes, something like this :)

…well, yes, something like this 🙂

First, let's define what we mean by the concept of “team”. Here is a quote from Wikipedia:

Team – this is a group of people united by common motives, interests, ideals, acting together. Team members are united by supporting each other and are collectively responsible for the results of the entire team.

Is this right for us? I think so, and here's why:

— Common motives and interests: to create the coolest and highest quality software possible.

— General ideals: create the best customer experience in the bank’s digital channels.

– Let's act together? Certainly!

— Are we responsible for the result together? Of course… Hey, Sashka, where are you going? Wait a minute!:)

What could go wrong? I came up with a cool product!

Let's imagine the following. You have been preparing a vision for the product for a long time, drawing up a coherent concept, forming a development roadmap, defending it to a wide range of audiences and, inspired, came to the team to present the results, fill out the backlog and bring ideas to life.

Suddenly the speed at which ideas are implemented is not as fast as we would like. Slipping begins. Time is lost, and with it the relevance of the declared value. Customers are unhappy and the atmosphere is heating up. You are trying your best to resolve the situation, but somehow it is in no hurry to accelerate to acceptable levels. In general, something like this:

What could go wrong? Tasks were assessed incorrectly, previously unaccounted for nuances surfaced, subcontractors violated earlier commits, did bureaucracy win in some places? I’m not talking about this now, although all of the above, of course, happens. Let's talk about people, processes and interactions.

Why is there a picture of Harold on my morning coffee mug?

A case from my practice: I assembled a team of competent specialists with experience. We are fulfilling an ambitious task: to develop a solution to automate work with legal documents and transfer 100% of these operations into digital format. It would seem that everything you need for a successful project is there, but the skis don’t work. Development is going slowly; during grooming sessions, participants sit with their microphones muted. This continues for some time, and hands begin to give up.

I have identified several reasons why development is going poorly:

  1. People just don't talk to each other. Everyone sees their tasks in Jira and deals with them. “What questions are there for me, I did everything yesterday! Why didn't others know about this? And this is no longer my task, I’m telling you about this today at the Daily, then decide for yourself what to do.” Sound familiar?

  2. Expectations from each other are not defined. It turns out that there is dissatisfaction in the team, but for some reason they are silent about this at retrospectives. Why? Let's look further.

  3. To summarize as much as possible, there is no trust in the teamhence the closed position for each participant with the corresponding final result.

You can try to “set the game” for the team, attract a Scrum master, but this only aggravates the situation, since the participants have even less trust in this gentleman than in each other. In a word, sadness.

Do robots work hard, not people?

Let's rewind back to the very beginning, when nothing had started yet, the team did not exist, and the selection of candidates was open. In large corporations, the CTO, or the IT leader of the department, is responsible for hiring IT specialists. Of course, he is interested in the technical background of applicants, relevant experience, and potential for development. But here’s the problem: not everywhere the team is systematically formed as a cohesive fighting unit.

In my opinion, if the product owner is not involved in the selection process, who will interact with colleagues, we will most likely end up with a group of people (not a team) playing by the “rules” described above.

What's the end result with the project in my example? It is functioning and will continue to develop. It was made by another team, which was initially formed according to principles that have shown effectiveness in practice. Let's see what these principles are.

Laziness is the engine of progress. But only mine

I'll tell you what I do to make the team work harmoniously.

  1. I definitely hire professionals. Definitely. Otherwise, there will be no result even if the following conditions are met.

  2. I hire “stars”—specialists with a high level of skills and ambitions. But a little. Otherwise, what happened at the beginning of the 2000s with the Real Madrid football club will happen. I think the old guys remember the policy of the “Zidanes and Pavons”: we’ll buy up all the stars we have enough money for, add young talents to our academy and let them float freely. As a result, the stars quarreled, the young people sat under the bench and were afraid to stick their heads out, looking at the showdown “at the top.” There were no results and the project failed.

  3. It's already a hackneyed truth, but software is what immediately answers the question of whether to hire a candidate. The first impression is the most important. I believe that the image of a social phobe IT specialist should finally sink into oblivion; such people simply will not be able to work effectively in a team.

    What I pay attention to during interviews:

    – how much a person likes himself,
    – literacy of speech, its pace and completeness of thought,
    — honest answers to not the most convenient questions,
    – the ability to soberly evaluate oneself from the outside,
    — does the candidate ask questions about with whom and how he will have to interact in the team if we agree on hiring.

    If you're a candidate, don't be afraid to ask questions directly to get a better understanding of your prospective team's environment.

    What to pay attention to the employee:

    — Find out if it is possible to hold a meeting with the team. You will be able to ask questions of your potential colleagues.
    — If the meeting takes place, watch how people communicate with each other. Throw in a slightly provocative (but in moderation!) question and see the reaction.
    – Pay attention to how sincerely and directly they answer you. If there are not enough specifics, “pouring water” is a sure sign that you should stop communicating.
    — Ask in detail about the processes within your role. Show that you are a professional who understands the subject.
    — Clarify what is expected from the candidate. It is important to understand this at the negotiation stage in order to further avoid mutual disappointment.

  1. I don't ignore young talents. Sometimes it’s better to take a junior, who after six months will pump up and at the same time remain as “hungry” as at the start. Well, here is an obvious plus for my karma – I develop my colleagues.

    At the same time, I maintain a balance and do not allow imbalance: the level of professional skills in the team does not fall due to the influx of “young people”. Of course, everything depends on the scale of the project, the project budget, the market situation, etc. Look at your realities.

  2. I find out Is the candidate interested in the business meaning of the tasks? If a developer just wants to cut code according to the technical specifications from an analyst, the team will not be successful. It’s cool when a conditional backend shares how else you can launch a feature from the point of view of the end user of the product. High team involvement in processes = maximum synergy = great final result.

  3. I delve into development processes. Otherwise, people will look at me askance and sometimes post memes about the project manager as, uh, a layman.

  4. Whatever one may say, live human communication cannot be replaced by anything. In my team, meetings are held regularly, despite the very extensive geography. We organized a corporate party for ourselves at the end of last year, almost everyone came. We sat in a sincere, almost family atmosphere, and talked about everything in the world. It was great, we’ll definitely do it again this year!

    Holidays are holidays, and morning coffee in the company of colleagues has also become a whole event, although everyone has been completely remote for quite a long time. After several trips to the office together, we decided to make outings regularly; it’s great that this tradition is not interrupted.

  5. I give feedback. Regularly. I love it. I call the team for a demo to show the product. It’s great motivation, especially when we managed to increase the metrics through joint efforts. From the very beginning of my work, I said that I was open for communication and every participant could contact me for any reason.

    The open position bore fruit – the level of trust in each other was already at an acceptable level at the start. And when we completed the first tasks, I broadcast positive feedback on daily news and saw how important it was for the guys who had invested so much time and effort into the product to hear it.

What's the result?

Where did we start?

From the fact that Harold looked at me every morning from his mug of morning coffee and reminded me of the sad situation in the team.

Now what?

Harold is gathering dust somewhere in the closet; he has been replaced by a more positive character (which one I’m keeping secret for now). Team meetings have ceased to be routine and have become a platform for motivated professionals to work together. We have the same rules, everyone keeps team traditions. We see each other periodically in the office and plan a general meeting in an expanded format on neutral territory.

Of course, the result was not guaranteed. But believe me, it will be very interesting to go down such a path, it’s definitely worth a try.


Share your thoughts in the comments on what else can be added/improved in the team atmosphere.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *