For engineers in the internet industry, what comes to mind most often is the Scalability of systems β for example, how to improve a system as traffic, compute, and storage grow, with all kinds of horizontal and vertical scaling options. Besides services, the Scalability of a team is also critical. This post is mainly about how to organize a team so that, at a certain scale, adding people actually increases the team’s capacity to handle work.
1. Separating People from Tasks
For a small company, it is usually a handful of top employees who carry the entire team’s KPI. Achieving the separation of people and tasks is not easy. But relying heavily on a small number of employees is not a healthy state for the whole team.
People and tasks must not be bound together. When one person handles a matter single-handedly, it is indeed fast, and it is easy to get addicted to that. Once used to it, they keep using it; once familiar, they keep following the old routine. This makes it hard for others to take over such matters, and more importantly, it prevents other members from developing the relevant skills. You do not even need to wait for the workload to grow β as soon as that person takes a vacation or leaves, it will have a large impact on the entire team.
Separating people from tasks means hard-coding the process: handling a matter is simply starting a process. It has three steps:
Map out the lines of responsibility. For example, you need a developer A, an operations person B, and a streamer C. On a single line of responsibility, the handling process, points to note, past incidents, and so on all need to be recorded in the knowledge base, with a tasklist and checklist provided, spelled out as 1, 2, 3.
Organize the raw materials for starting the process. For example, after a livestream ends, the video needs to be uploaded to Bilibili. Following the process from the previous step, you need to download the video from Zoom, trim the video, add a Logo page, add a watermark, add subtitles, export to a specified format, upload the video to Bilibili, wait for review, and notify the group. In this process, you need to log into Zoom and Bilibili. So these account credentials need to be recorded and authorized, and these accounts should belong to the team rather than to an individual.
Start the process. With the previous two steps in place, any authorized user can start the process. The output may not be perfectly consistent because individual abilities differ, but it satisfies Scalability.
2. End-to-End Delivery
Before value is delivered, everything is meaningless.
As shown above, a process involves A -> B -> C. Many teams divide the work so that A is handled by one person, B by one person, and C by one person. Such an architecture is hard to adapt in an internet company: they never reach agreement on value delivery. A’s value is delivering to B, but they forget that only when C completes delivery is value provided to the customer. At the same time, as delivery requirements pile up, both A and B may become unable to keep up with C and turn into bottlenecks.
Each person is responsible for one thing small enough to be completed independently. If it is not, then split the thing; if it still is not, then let that person go.
One person, one task, following through from start to finish, completing the main work, with the rest assisted by other members β rather than demanding someone be a generalist. This is not a requirement about ability; it is a requirement about delivery mindset. Before it is live and before it reaches the customer, the matter is not finished β it needs constant attention, improvement, and pushing forward.
When everyone practices end-to-end delivery, the team can respond to growing delivery demands by adding people β and thereby satisfies Scalability.
3. Using External Services
When designing software architecture, one optimization is to separate storage out and use third-party storage, so that the business layer can respond to growing traffic by adding replicas.
When organizing a team, there is a similar scenario. Quoting a previous document: Why Should We Use Remote Build, here are a few of its key points:
- Raise the level of automation
- Make it easier for others to participate
- Versions are traceable and reproducible
- Lower cost
- Suited to remote work
Using public external services avoids a matter’s dependence on an individual, and satisfies Scalability.
