Diagnosing problems in a team in four hours using an example of a live startup

The most common of the problems that I encounter in projects is what to change first of all, what to focus on. “How” everyone knows or believes that they know. I have several hacks in store that allow you to conduct an initial analysis in half a day, revealing the focal points.



This time I want to share one of them, using the example of working with the team of one successful startup last week. The specific scope of the project is not critical. I’ll just mention that they use Scrum and, according to the head, “he still doesn’t identify some problems.” By the way, I sincerely believe that there is not a single universal methodology covering all levels of management. The most effective knowledge and application of at least two or three diverse.
There is a vision of problems at the level of first person, middle management and line performers. My opinion is that the most important problems are clarified at the lower level, but are effectively resolved only through an analysis of their impact on the entire project. This is the main problem of communication between a programmer or designer with CEO. The latter often understands what the catch is, but perceives it as the pain of a specific employee, not counting that it globally affects the entire process.

Actually the method.

Stage 1.

Write down eight problems in the project that interfere with your work and most of all catch you emotionally. Do not look for the most global, do not think for others, write about what annoys you. The only limitation is that the problem must be repeated at least several times.

Step 1.

If you want to try the method on yourself, write down these problems now, without reading further spoilers.

I will give examples of such diagnostics using three members of a real team as an example:

1. Designer
2. Deputy General.
3. CEO / Founder of the project.

Problems from the point of view of the designer

Problems in the project
1. Lack of communication within the team, isolation
2. The lack of visualization of the plan where we are moving
3. The lack of a strong team leader for developers
4. Little freedom, fast pace, not even freedom, but some informal meetings at which we could discuss what kind of product could be. In fact, we are tools, and the CEO is cutting us. We ourselves don’t take part in the sawing process, maximum - we can figure out how to cut more intensively

Problems from the point of view of the deputy

Problems in the project
5. Planning is not efficient.	I would like to understand what the development team plans to do in order to plan finances, to know what the teams can promise, etc. Learning this at the planning stages of the crane is inefficient for me, as the CEO begins to manage the team and everything happens for a very long time
6. I adjust in the process of communication under the CEO and expect that they will also adapt to me (build an individual interface) until this happens.
7. The process for the sake of the process	I was somewhat bothered by situations of writing updates in activities in which I take only nominal participation, now this situation has changed for the better.
8. Creating a process for the sake of the process	Creating a description of a business process can spend more energy than gives value on the output.

Problems from the point of view of the CEO

Problems in the project
9. Many research processes need to be launched
10. A lot of manual work on setting up, receiving data, reviewing
11. Only a part of the benefits that we can bring is clear, we need a review and cases to see more benefits.
12. The money that you want to receive, while the more benefits that we see that we can provide.

Only half of the problems recorded by employees are given here, the rest reveal their inner kitchen too much. The problems do not overlap much and it is obvious that the last four will be solved first of all, simply by the right of strength and authority.
On the one hand, the problems formulated in this way look more like complaints, on the other hand, it is much more effective than trying to identify growth points in the style of “what will help us develop?” Everyone has something to complain about and it doesn’t take much time.
I met only one programmer who stubbornly kept saying "I am absolutely satisfied with everything." But he, in my opinion, was a Buddhist. They dealt with the situation by reformulating the question “what annoys you at least a little?” He has not yet reached the benefit of Nirvana.
At this stage, the problems do not need to be reformulated, take them as they are.

Stage 2.

Actually at this moment, a simple trick takes effect, which allows the collection of complaints to translate into the creation of a construct.
Invite the employee (or yourself) to reformulate the same problem into the “I'm Not” format. You need to write what is missing to get what you want. Usually it boils down to the options “I don’t have”, “I don’t know”, “I don’t know how”, “I don’t have the authority to”, etc.
It is critical at this moment to prompt possible options as tactfully as possible. So, select at least some polite people who are ready to restrain causticity and black humor for this procedure. It’s hard for a person to admit that the solution to this problem depends on him, and if you offer him the wording “I’m not smart,” “I don’t like working,” or “I don’t work there” (this is a real case), then it’ll just close and nothing useful you will not learn.

Step 2

If you wrote down the problems of your team at Step 1, now is the time to try translating them into the “I'm Not” format.

A week ago, I received the following options:

Designer

Problems in the project	I do not
1. Lack of communication within the team, isolation	1a. During work, I do not discuss design with developers, I often isolate myself and think through many things that I would have to ask
2. The lack of visualization of the plan where we are moving	2a. I do not regularly specify where we are moving, I find out in fact
3. The lack of a strong team leader for developers	3a. I cannot be sure of the adequate use of my design, because due to the low level of development, effective practices for its implementation have not been developed
4. Little freedom, fast pace, not even freedom, but some informal meetings at which we could discuss what kind of product could be. In fact, we are tools, and the CEO is cutting us. We ourselves don’t take part in the sawing process, maximum - we can figure out how to cut more intensively	4a. I do not seek informal discussion on the project, as it was when I came to Moscow

Deputy

Problems in the project		I do not
5. Planning is not efficient.	I would like to understand what the development team plans to do in order to plan finances, to know what the teams can promise, etc. Learning this at the planning stages of the crane is inefficient for me, as the CEO begins to manage the team and everything happens for a very long time	5a. I cannot organize the process of effectively informing me of development plans
6. I adjust in the process of communication under the CEO and expect that they will also adapt to me (build an individual interface) until this happens.		6a. I can not convince the CEO to communicate with me more effectively. Hear me and understand
7. The process for the sake of the process	I was somewhat bothered by situations of writing updates in activities in which I take only nominal participation, now this situation has changed for the better.	7a. I do not consider it necessary to describe activities that do not bring value to other team members
8. Creating a process for the sake of the process	Creating a description of a business process can spend more energy than gives value on the output.	8a. I do not escalate and do not convey my dissatisfaction and do not propose alternative solutions

CEO

Problems in the project	I do not
9. Many research processes need to be launched	9a. I have not yet built clear processes for all 5-6 teams for the review and analysis of how to bring more benefit
10. A lot of manual work on setting up, receiving data, reviewing	10a. I haven’t written yet or thought of whom to set the task of writing instructions for all occasions, on setting up, economics, conclusions
11. Only a part of the benefits that we can bring is clear, we need a review and cases to see more benefits.	11a. I have not yet thought up and visualized a lot of unobvious conclusions for b2b commands
12. The money that you want to receive, while the more benefits that we see that we can provide.	10a + 11a

I will not tell you here what conclusions the team came to and what it is doing now.
The examples here are for illustrative purposes only.

What you need to know:

1. If a problem in one form or another occurs at more than one level, it must be dealt with.
2. If the problem occurs in more than two linear performers, it must be dealt with.
3. The higher the level of the performer who solves the problem, the faster it will be solved.
4. The lower the level of the contractor selected to solve the problem, the more effective and independent the employee to whom you delegate the solution of the problem will become.

And finally, two problems that I meet most often:

1. I don’t understand where our project is moving now, and how my actions affect it.
2. I cannot get the leader to hear my problem, not his own interpretation of my problem. They don’t understand me, but I can’t explain.

What follows is analysis and troubleshooting, but more on that another time.