This guide is about implementation organisational change in a team, taking into account the fact that people resist changes, even necessary and justified changes. The team is faced with a problem, but instead of solving it, people try to ignore the problem, postpone the solution until later, claim that the problem is not important enough to deal with. People may not like the way things are working right now, but they do not want to change it either.

We are writing this guide for team leaders regardless of whether the team is developing a new product, working on a project, doing process work that needs to be improved, building a business or playing football. However, football is too much. Teams are very different, and if you use TDF to teach children in a classroom, form a football team or implement changes in a family, you will not be happy with the results. So it is best not to.

A team leader is the person who needs results the most. But if only one interested person is involved in the project, the fate of the project will be tragic. Therefore, this guide will help teams whose participants also care about the result and are ready to sacrifice something and go beyond the minimum requirements to achieve it.

Who we are and why we are writing this guide?
We are Kite:Project, which was created in autumn 2016 in Saint Petersburg to apply the developments of Denis Silvers' PhD thesis in business, namely in developing and implementing a solution for effective management of business teams. It is now called the Team Development Framework (TDF).

We have been working within Agile, focusing on the psychological part – the part where Agile uses theories from the 70s, many of which have never been tested, and those that have been tested are often wrong. However, when it comes to the psychology of people, there are few good theories: the better the theory, the more inapplicable it is to real business or team management.

Basically, we worked not with development teams, but with management teams: teams that included team leaders and could include company management or client representatives. Such a team is the closest to the distributed leadership model, but it is also the most difficult to work with such a team.

Our clients have been IT companies, telecoms, fuel and energy companies, pharmacology, research teams, charity and HoReCa.

This is not a Basic Guide.
For beginner team leaders it is better not to choose between many alternatives – there is no experience for that yet – but preferably to use the solution that the team leader has read in a book or that the Agile coach has advised.

This guide is written to help experienced team leaders who have hit the "glass ceiling" and are already convinced that books and articles are mostly rehashing each other, and that out of the box solutions do not work as well as they say in the preface.

Mental Models.
We have come to the conclusion that one should focus not on changing behaviour, values and beliefs, but on changing Mental Models. Therefore, this guide is written with a focus on the Mental Models that we would like to change in our employees.

A team leader has a mental model where they realise that if an employee has a task to be completed in a week, the employee should be monitored every two hours – otherwise they will not do anything. This mental model may cause indignation today: an employee need to be trusted, allowed to take initiative and intervene only if they ask for help.

Letting employees do as they see fit or controlling them are two different mental models and one cannot be said to be better or worse. It depends on the situation. Understanding that management tools should be chosen based on the conditions is in turn a mental model There is no Silver Bullet.

'M There is no Silver Bullet. People often expect some simple marketing tool that will dramatically increase sales, or a simple technique for a manager that will immediately fix most, if not all, problems. This guide is unlikely to contain any such thing. A successful leader differs from an unsuccessful one not by a single technique, but by the skilful application of ten thousand small techniques, each of which is simple, obvious and yet quite useless if not applied in a system with others.

Foundational Principles. Despite what the Agile manifesto says, in our opinion the core principles of Agile are Value Delivery, Focus and Continuous Improvements. Sociocracy is very specific about its foundational seven principles. Among them is Empiricism – testing hypotheses under real-world conditions. This principle is not core to Agile, but an Agile practitioner will quickly understand and agree with it. There is also the principle of Accountability – this is Agile's blind spot. If Agile uses the concept of responsibility, it is only in the sense that a self-organised team is responsible for everything.

Since this is an obvious blind spot, we will address responsibility in this guide, but it still will not be our underlying principle. We do not want to repeat what others have already said well, so we focus on what other theories cover poorly: Balance, Systems Approach, and Development.

Balance is one of the central mental models. Good decisions are balanced decisions. If you control employees, they will not develop; if you give them complete freedom, they will not develop either. We do not know the full list of conditions necessary for development, but we do know that a necessary condition for development is pressure. The pressure of competitors, budgets, deadlines, etc... It is worthwhile to build work in a balanced way so that employees have freedom, but at the same time they achieve the necessary result.

In our work with teams, we have noticed three distinct phases: from following simple rules (Phase I) to developing their own original approaches to problem solving (Phase III).

Phase I relies heavily on the mental model of balance. In this phase, people learn simple things: write epics, get to meetings on time, work in sprints. People rejoice in small victories, protect their area of responsibility, and resist change. An implementation plan can be made for the first phase, as simple things are implemented. Balance helps to understand what specific things need to be implement

Development. If you need to get people to start behaving differently, fear and coercion are effective tools. In some cases, these tools will work quickly and reliably. However, our values are such that we want the employee to change voluntarily and consciously. It is this kind of change that we will call development.

Phase II is associated with routine work. The team often faces unique problems. They are unique because neither this guide nor others describe the unique situation in which the team performs. The team overcomes some problems easily through teamwork, and some are denied, devalued, and ignored. Performance in this phase improves slowly but steadily, and the team approaches its "glass ceiling." It is in this phase that natural development occurs, where people may resist change, but do not sabotage it.

Systems Approach. Implementing a management tool in one place may cause problems in another. Eliminating one negative factor can make the situation even worse. That is why we expect that what is written in this guide will not be applied strictly according to the instructions with the hope that it will work perfectly. There is no Silver Bullet.

Phase III. The second phase could also be the final one: not all teams need overachievement. Stable work often gives such a competitive advantage that the team does not need anything else. Nevertheless, those teams that want to develop further are forced to break through the "glass ceiling". Here the team reaches the point where it knows all ten thousand little things, but does not understand how to add up the result.

We do not know whether there is a fourth phase after breaking through that glass ceiling.

You are Professionals.
We do not have an ultimatum experience. Some of our decisions are not good – you could do better. Some issues we understand worse – someone who has been in the industry for 20 years could correct us. We would be grateful for such recommendations and are open to cooperation.