Diagnosing problems in a team in four hours on the example of a live startup

The most frequent of the problems that I encounter in projects is what to change in the first place, what to focus on. “How” everyone knows or thinks they know. I have in store several hacks that allow for a half-day to conduct a primary analysis that identifies points of focus.



This time I want to share one of them, using the example of working with a team of one successful startup last week. The specific scope of the project does not matter. I will only mention that they use Scrum and, in the opinion of the manager, “it still doesn’t reveal some problems”. By the way, I sincerely believe that there is not a single universal technique covering all levels of government. The most effective knowledge and application of at least two or three diverse.
There is a vision of problems at the level of the first person, middle management and line workers. My opinion - the most important problems are clarified at the lower level, but are effectively solved only through an analysis of their influence on the entire project. This is the main problem of communication programmer or designer with the CEO. The latter often understands what the hitch is, but perceives it as a pain of a specific employee, not counting that it affects the whole process globally.
')

Actually 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 on the example of three members of a real team:

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

Problems from the point of view of the designer

Problems in the project
1. Lack of communication within the team, isolation
2. Lack of visualization of the plan where we are going.
3. Lack of a strong development team leader.
4. There is little freedom, a fast pace, not even freedom, but some kind of informal meetings, at which we could discuss whatever product could be. In essence, we are tools, and we are sawing the CEO. We ourselves do not participate head in the process of sawing, the maximum - we can figure out how to cut more intensely

Problems in terms of alternate

Problems in the project
5. Planning is not effective.	It would be good for me to understand what the development team plans to do in order to plan finances, to know what one can promise to the teams, etc. It’s ineffective for me to learn this in planning sessions, as the CEO starts to manage the team and everything happens for a very long time.
6. I adapt to the process of communication under the CEO and expect that they will also adapt to me (build an individual interface) until this happens.
7. Process for process	I was somewhat strained by the situation of writing updates in activities in which I accept only nominal participation, now this situation has changed for the better.
8. Creating a process for the sake of a process.	Creating a business process description can spend more effort than it does on output values

Problems from the point of view of the CEO

Problems in the project
9. You need to run a lot of research processes.
10. A lot of manual work on setting up, receiving data, rewriting
11. Only a part of the benefits that we can bring is clear, we need a copy and case studies to see more benefits.
12. The money you want to receive, while more benefits that we see that we can provide.

Here, only half of the problems recorded by the staff are given, the rest reveal their internal kitchen too much. The problems do not overlap much and it is obvious that the last four will be solved first of all, just by the right of force and authority.
On the one hand, the problems formulated in this way look more like complaints, on the other hand, this is much more effective than trying to identify growth points in the “what will help us develop?” Style. There is nothing to complain about and it doesn’t take much time.
I met only one programmer who stubbornly repeated “everything suits me absolutely.” But he, in my opinion, was a Buddhist. Cope with the situation, reformulating the question on "what annoys you a little?" The benefit of Nirvana, he has not yet reached.
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 comes into force, which allows the collection of complaints to be translated into the creation of a constructive.
Invite the employee (or yourself) to reformulate the same problem in the “I do not” format. It is necessary to write what is not enough to get what you want. Usually it comes down to the options "I do not have", "I do not know", "I do not know how", "I do not have the authority to", etc.
It is critical at this moment to suggest possible options as tactfully as possible. So set aside for this procedure at least some polite people who are ready to restrain sarcasm and black humor. 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 to work” or “I don’t work there” (this is a real case), it will just close useful you do not know.

Step 2.

If you recorded the problems of your team on the “Step 1” point, now is the time to try to convert them to the “I don’t” 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 While working, I do not discuss design with developers, I often isolate myself and think of many things that I would have to ask.
2. Lack of visualization of the plan where we are going.	2a I do not specify regularly where we are moving, I find out after the fact
3. Lack of a strong development team leader.	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 worked out.
4. There is little freedom, a fast pace, not even freedom, but some kind of informal meetings, at which we could discuss whatever product could be. In essence, we are tools, and we are sawing the CEO. We ourselves do not participate head in the process of sawing, the maximum - we can figure out how to cut more intensely	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 effective.	It would be good for me to understand what the development team plans to do in order to plan finances, to know what one can promise to the teams, etc. It’s ineffective for me to learn this in planning sessions, as the CEO starts to manage the team and everything happens for a very long time.	5a. I cannot organize the process of effectively informing me about development plans
6. I adapt to 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't convince the CEO to talk to me more effectively. Hear me and understand
7. Process for process	I was somewhat strained by the situation of writing updates in activities in which I accept 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 a process.	Creating a business process description can spend more effort than it does on output values	8a. I do not escalate and end my discontent and do not propose alternative solutions

CEO

Problems in the project	I do not
9. You need to run a lot of research processes.	9a. I have not yet built clear processes for all 5-6 teams on the analysis and analysis, how to bring more benefits
10. A lot of manual work on setting up, receiving data, rewriting	10a. I haven’t yet written or thought of someone to set a task to write instructions for all occasions, on tuning, economics, conclusions
11. Only a part of the benefits that we can bring is clear, we need a copy and case studies to see more benefits.	11a I have not thought of it yet and have not visualized many unclear conclusions for b2b commands.
12. The money you want to receive, while 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 the problem in one form or another occurs on more than one level, it must be dealt with.
2. If the problem occurs in more than two linear workers, 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 performer chosen to solve the problem, the more effective and independent the employee to whom you delegate the solution of the problem.

And finally, two problems that I encounter most often:

1. I do not understand where our project is moving now, and how my actions affect it.
2. I can’t get the manager to hear my problem, not my interpretation of my problem. I do not understand, but I can not explain.

This is followed by analysis and troubleshooting, but more on that another time.