Optimal roles for product development to avoid Middle Management trap Many know about the middle management problem. It arises when an artificial management hierarchy is created, in which any decisions going from top to bottom or from bottom to top begin to drown. A kind of bureaucratic damper of the company, the goal of which is to preserve the current status quo and its position. Today I want to share my vision and experience on the topic of the necessary roles for optimal product development and avoiding the middle management trap. So, for a start, we need such roles: Product Owner (PO) - leader and driver from the business side, who is responsible for the product vision, backlog filling, priority management, and product development. Solution Architect (SA) or Technical Lead (TL), who will drive the technical side of the product, including architecture, development processes, engineering practices, and other technical issues. Development team, which will directly develop the product, balanced by competencies according to the chosen technical stack. Very simple and effective setup, in which business and team work together as closely as possible on common goals. What additional roles can appear in such a setup? If the business domain is complex and high-level requirements need to be elaborated in detail, Business Analysts can appear to help PO. This is already an additional link in communication between PO and the technical team. Also, there may be a need for the role of Enterprise Architect if the new product is built in a complex landscape of other systems and services. If there is no opportunity or desire to hire mature specialists to build a self-organized team, and SA/TL has no experience in managing a development team, then a Project Manager appears on the scene, who takes on this task. An alternative at this stage is the allocation of the Team Lead role. If development is done in Scrum and no one in the team has the necessary experience and desire, then the Scrum Master (SM) role may appear on the scene. The last 2 roles almost close the imperfection of the organization arising from a lack of money, experience, or time to build an optimal structure. This is the first step towards creating a complex hierarchical structure in which PO, SA/TL, PM/TL, and SM begin to share areas of responsibility and influence. And the balance of this division will depend heavily on their level of qualification and leadership qualities. Very bad imbalances can occur when PM begins to be responsible for priorities or SM becomes a team manager. The situation begins to deteriorate with the need to scale development. In the optimal structure, we still have the roles of PO and SA/TL, and all teams are self-managing cells. From my experience, 3-5 teams can easily work in this scheme, 5-8 is already more difficult, more than 8 is already becoming difficult. What do most companies do in this case? They begin to grow the management hierarchy. New roles appear: Delivery Manager (DM), who is responsible for organizing the work of several teams (usually from 2 to 5). PMs or Team Leads are already under him. Delivery Director (DD) or Program Manager (PGM), who is responsible for organizing the work of a large number of teams (usually from 5 to 10+). DMs are under him. So we have built a "beautiful" hierarchy PO->DD->DM->PM/TL/SM, in which the bureaucratization of decision-making processes occurs very quickly and everything slows down. To compensate for the loss of speed, more teams are added, and everything becomes even more complicated... What to do? There are several alternatives: split the product into independent subproducts, for example, a web application and mobile clients; separate weakly related streams, for example, admin panel, features for different types of users, regions, etc.; use the principles of microservice architecture and build teams around domain groups of services. In the first case, the structure can be left as flat as possible, but it is usually difficult to identify more than 2-3 subproducts. In the second and third cases, auxiliary roles such as Stream Lead or Domain Owner may be needed to organize work within the stream or harmonious development of the domain. The third approach can be used to scale almost any level. Avoid hierarchies, there is rarely anything good behind them!