Building Self-Organizing Project Teams: Practices and Process

With the rapid development and iteration of internet services, the demand for higher project‑management efficiency has increased. Organizations face the challenge of incorporating more new projects into their management system while improving overall project‑management capability.

Previously, project managers deeply participated in all projects, limiting the scope to internal business‑line teams. This caused fragmented channels, poor cross‑team coordination, and insufficient resources for urgent complex projects. In Q3, a transformation was carried out: shifting from internal project management to cross‑team complex‑project management, adopting deep, shallow, or support participation based on project characteristics, developing small management tools, building an engineering‑efficiency platform, and leveraging the PMO team. These measures alleviated the tension and ensured delivery of key cross‑team demands.

The article focuses on how to build self‑organizing project teams. It does not discuss how functional teams themselves become self‑organizing.

1. Why Self‑Organizing Project Teams Are Needed

A self‑organizing team is an internally driven group created to accomplish a great, challenging mission. The team receives tasks and constraints, follows agreed‑upon rules, and decides autonomously how to achieve the goals. High visualisation of tasks, risks, and progress, along with training, technical support, and retrospectives, enables continuous improvement.

For low‑complexity projects, deep manager involvement often leads to bottlenecks and limited team growth. When the manager cannot supervise all tasks, progress stalls and risk rises. Transforming such projects into self‑organizing teams helps distribute responsibility and foster team cohesion.

2. Characteristics of Self‑Organizing Project Teams

Team members show high proactive participation and strong self‑organization/collaboration abilities.

Project complexity is low.

The project manager shifts to an enabler and supporter role.

3. How to Build a Self‑Organizing Project Team

(1) Initiation Phase: Establish the team, identify key stakeholders, and define role responsibilities.

(2) Planning Phase: Based on project traits (e.g., iteration needs, release cycles), the manager designs an appropriate self‑organizing workflow and reaches consensus on process standards. Targeted training (effective communication, meeting efficiency, etc.) is provided.

(3) Trial‑Run Phase (including retrospectives and improvements):

Managers lead the team through initial activities such as kickoff meetings, requirement reviews, demand splitting, and handling urgent changes.

Managers help the team transition to maturity (referencing the Bruce Tuckman team‑development model). They resolve conflicts, align work habits, and cultivate a shared work philosophy.

(4) Self‑Running Phase (including retrospectives and improvements):

The manager becomes a pure supporter; the team operates autonomously, achieving co‑creation, co‑ownership, and co‑governance.

The team conducts its own retrospectives, continuously optimising the process, and may seek manager support when needed.

The PMO supports the self‑organizing team by providing templates, training, and consulting.

4. Practice of Self‑Organizing Project Teams

Two workflow templates are offered by the PMO: one for projects with iteration cycles (e.g., apps) and another for non‑iteration projects (e.g., backend APIs). Teams can tailor the templates to their needs.

Example: a team with low complexity, unified demand sources, fixed development & testing staff, and semi‑fixed product staff adopted a self‑organizing model.

Initiation: After evaluating suitability, the team defined stakeholders and role responsibilities.

Planning: The manager drafted a demand‑management process, illustrated below.

Demand Management Main Process

Trial‑Run Phase: The team conducted bi‑weekly review meetings, clarified requirements, identified dependencies, estimated effort, and set schedules promptly.

Regular Review: Establishes team rhythm; preparation before, during, and after meetings is essential.

Stand‑up Meetings: Team members synchronise progress and blockers; frequency is flexible.

Retrospective Meetings: Four steps – review objectives, evaluate results, perform root‑cause analysis, and summarise lessons for future improvement.

Self‑Running Phase: Once processes run smoothly, the manager steps back. The team self‑governs, adjusts processes, and the PMO continues to provide occasional consulting.

Conclusion

After a period of operation, the self‑organizing team achieved its goals: high‑priority demands were processed orderly, product, development, and testing members communicated proactively, and overall R&D and communication efficiency improved steadily.

The team now handles both pure backend demand reviews and cross‑team demand reviews, and continues to customise its own processes, demonstrating the effectiveness of the self‑organizing approach.