My experience in a self-management team

I am going to tell you about my experience in a self-management team: what it is, its advantages and disadvantages. During the last year and a half, there were from 3 to 5 software engineers on my team. My initial task was to build multiple products and develop processes from scratch.

Self-management Team

In the self-management team, there is no separation of roles or specializations except for software engineers. It means front-end, back-end, infrastructure, testing, and project management is done only by engineers. Each team member participates at each iteration of the software development lifecycle: get a task, clarify requirements, write code, test, deploy, monitor, and support. Tasks are distributed among the team members, hence we don’t have experts assigned to specific parts of projects.

The team chooses, integrates, and supports a technology stack on its own: Go or Python, Jenkins or Github Actions, Kubernetes or not. Criteria for a choice can be the size of a project, throughput of engineers, supportability in the future by new engineers (community interest in technology, number of specialists in the market).

Grooming, planning, assignment, meetings, and retrospective is done on the team’s own.

The goals of the team leader, except software engineering, are motivation and care of the team members, removing obstacles, and improving processes.

In general, the team is trying to be a problem solver instead of a resource utilizer.

More About Processes

I want to describe processes that are not directly related to a self-management team but related to any team, including mine. I just want to mention that they were easier, more effective, and nicely implemented into the self-management team.

There are no meetings where we discuss our work such as on daily stand-ups and retrospectives. I wanted to build processes where development is clear, obvious, and documented for everyone as if we work remotely even being at an office: pull requests’ descriptions with explanation and examples, documentation for processes, tools, technologies.

There were no 1-to-1 meetings. I wanted to have instant feedback from the team members. If there is something you don’t like and/or want to improve, just send a message to your entire team explaining your position. Imagine, a team member comes to you and says they want to quit for some reasons he could have told you about earlier—but no, now a problem has been made worse by time. Meanwhile, it’s a point for you to think about his competencies (or desire to work on a product, or seniority). Mentally, it’s a hard process, you should work on it to push yourself each time you see you can improve something even if it takes a lot of energy and time.

This is also true with deadlines and estimates, only when it’s really needed because work expands so as to fill the time available for its completion.

When a product manager sets team goals, a chat or an e-mail is used with all team members included in «cc». After, the team decided who will be doing what and when based on the product manager’s setup.

A good branching model is key such as Trunk-based when code is delivered to production right after the merge to master. There are no development and release branches as Gitflow Workflow says. We had the single branch master, if a pull request is merged to it, it means that tests are written and passed, functionality is checked on a deploy preview (feature branch, review app) — delivery of a feature is fast. One pull request — one commit to the master branch — one release.

Advantages

For a member of a self-management team:

• Working on different tasks using various technologies in diverse domains and fields. It’s never boring and brings T-shaped growth.
• Understanding of a full software development lifecycle.
• Growing of responsibility as an engineer does a task without distribution to other specialists (management, testing, deploying, monitoring).

For a self-management team itself and a company:

• Each member of a team participates in clarifications of task requirements, technical and architectural solutions, which brings all angles to discussions.
• There are no problems with vacations, sick days, and dismissals because there are no parts of a project which are known only by certain team members.
• There are no problems with moving to remote work if it’s needed.

Disadvantages

Not everyone feels comfortable being in a self-management team. Someone wants to improve skills in a specific area and be an I-shaped engineer. You should be careful hiring new engineers, they should match a team culture.

Software engineers differently value a code style, tools, and technologies. The more responsibility each team member has, the more beliefs they have around it. The values of a team member inevitably conflict with another team member’s values, especially at the beginning of the team history. Misunderstandings are unavoidable, it’s important to find a win-win solution (or at least a compromise) to not make anybody unhappy as soon as possible.

It’s unusual for management and business-people to have communication with a whole team (or anybody from a team) instead of the only team leader.

Conclusion

Conclusions I made for myself:

• Team members are multi-skilled, hence enjoy their work and processes.
• Each team member has the same responsibility, hence a team is a close-knit team and performs well.

Thank you for your time. If you have any questions, suggestions, or topics to discuss, feel free to write a comment.