Taro Logo

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.