You can find the full system design doc here - Feel free to use it as a template for when you are doing a system design at your job!
The tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:
- Something Alex forgot to mention in this video is the "POCs" section, where POC = "Point of Contact".
- Big projects will usually have a lot of stakeholders, so having this "people map" is very helpful for any project stakeholder to know who to direct their questions to for a certain aspect of the project (which are often about the timeline/milestones).
- This small, humble section is especially relevant at FAANG/Big Tech where the range of responsibility holders is almost always huge for major projects.
- Decomposing work and breaking big projects down into smaller tasks is helpful for so many reasons:
- It allows you to estimate the project far more accurately by increasing clarity.
- It creates "swim-lanes" for more junior engineers as they now have smaller, clearer chunks of work as opposed to this giant, hulking ambiguous cloud of a project.
- It makes it easy to understand project as you can now break clusters of tasks into groups and attach a milestone to each group.
- Don't just decompose the work: Try to sequence it into a logical order as well. For example, if you're building a CRUD feature, you probably want to prioritize the "Create" part as that's what everything stems from.