Breaking Down The Work And Timeline

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.