Building The World’s Best Calendar: Our Engineering Process
By Xinxing Jiang
•
May 13, 2024
At Saturn, we’re on a mission to build the world’s best calendar to boost student productivity. Our users know that building the world’s best calendar involves a lot of interconnected surfaces and features, and our Engineering team is constantly working to identify the tools and processes that allow us to make better decisions and execute faster.
Project management is a critical component of our work at Saturn. To help us manage our engineering process effectively, we utilize Linear as our project management platform. At Saturn, we’ve been using Linear as our project management tool and are very happy with it. This blog posts aims to share our experiences with Linear, highlighting how we leverage it for project management and the insights we've gathered along the way.
Building the world’s best calendar out of our NYC office
How we use Linear
Our process begins with roadmaps. Roadmaps are developed by our Product Management teams, and these Roadmaps are incorporated into Linear, providing a high-level overview of ongoing projects and their timelines.
Our roadmaps in Linear
Each roadmap is broken down into several projects, each corresponding to desired features or engineering efforts. These projects are crucial for strategic planning.
Examples of projects in Linear
First, each project begins with a project description, providing a high level summary that informs leaders, product managers, and engineers about the project's intended goals.
A project description example
Then, a project has a few links to relevant specs (including a product spec, eng spec, and Figma design, etc) and meeting notes. Linking specs within a project provides helpful pointers and context to stakeholders so that everyone has a shared understanding of the important product or engineering aspects of the project.
Our Eng team hard at work!
Specs linked for a project
Once a project is ‘specced’, and the spec is approved by lead PMs, an engineer is designated as the project lead to manage the project, with other engineers and stakeholders added as members.
Project lead and members
Once the engineering team is assigned to a project, the engineers will work together to scope the project. Engineers will break down the project into milestones if necessary. The rule of thumb is if a project takes more than 2 weeks in total, it will be broken into several milestones. Our goal in designating milestones is to ensure that each milestone is a product deliverable (in other words, a version that we can deliver to the user to collect feedback and user insight along the way).
Project milestones
Once milestones are defined and discussed between engineers and PMs, engineers will look to understand the component tasks within each milestone, and add estimates for each of those tasks.
Add estimate to each task
Tasks within milestones are estimated using a point system, where one workday equals two points. Linear refers to this system as the “linear system”. We aim for each engineer to have about 8 points assigned per week, understanding that the team will also have obligations to other tasks such as meeting, oncall responsibilities, etc.
Point system
Once we add points to each task in a milestone, we can sum the points and get a rough timeline for how long it will take to complete the entire project.
One thing to be mindful is that scope can often increase while the project is live. Inevitably, more tasks will be added to a project while it’s in flight: bug fixes, increased scope, more engineering work to handle tech debt, etc. With the increased scope, the timeline of each milestone and the whole project can easily take longer than originally planned.
We have a thorough system to make sure that we properly manage tasks that may not be part of the original scope by using the Icebox status. Tasks in the icebox represent items that have been identified but not yet discussed / agreed upon incorporating into the projects. This differs from the Backlog status, which represents projects that have been identified and will be incorporated into later Engineering cycles. The Engineering team will regularly discuss Icebox tasks in batches in order to incorporate these projects and adjust the timelines accordingly, or ensure these tasks get addressed in later milestones or even later projects. The goal is to constantly communicate and understand new factors in order to avoid surprises.
Icebox and Backlog
Once tasks have been defined and their effort estimated, our engineers commence work. We operate on a weekly sprint cycle, during which engineers are typically assigned tasks totaling approximately 8 points to complete over the following week.
Everyone has around 8 points for a cycle
During implementation, one valuable tool is the project update feature. The project lead is tasked with writing regular updates in Linear, providing stakeholders with an overview of the project's progress. To enhance communication, we have configured Slack automations that relay these updates to relevant Slack groups. Stakeholders can then discuss and comment directly in Slack, with their feedback automatically synchronized back to Linear, ensuring it remains the centralized record of truth.
Project updates
Updating projects!
Once a project's coding and initial testing are complete, the project lead organizes a bug-bashing session. This involves inviting all relevant team members to download the latest staging build and actively engage with the new feature to identify any issues. We use Instabug to manage and track bug reports efficiently. Following this session, engineers promptly address and resolve the reported bugs, ensuring the stability and functionality of the feature.
Once the project is bug-free, our Engineering team will collaborate with our Data Science team to initiate a phased rollout, typically managed through an Amplitude experiment PThe project's status is updated to "Rollout" in Linear for clear tracking. Over the next few weeks, the Data Science team analyzes the data to evaluate whether the new feature positively influences key metrics. If the analysis shows the feature to be successful, we proceed to integrate the feature into the main codebase for default activation. Conversely, if the feature does not perform as expected, we conduct a retro to extract valuable lessons and then revert the experiment and code.
Rollout stage
Summary
The above encapsulates the entire project lifecycle and how we utilize Linear throughout. Linear facilitates our project management by organizing projects within roadmaps and detailing individual projects with all the information that key stakeholders need to get from idea to development. This approach helps ensure transparency and efficiency throughout the project’s duration.
Team meeting to check on progress
Lessons learned around project management
As a startup, we constantly reflect on our processes and actively seek areas for improvement. This can be challenging for a company like Saturn, where we have many surface areas with varying degrees of complexity and finality. Some surfaces on the app have achieved product-market fit while others are still in the exploration phase. As a result, it’s difficult to apply a one-size-fits-all approach to our process.
However, we have learned some general lessons around project management that we apply to our process. Here are a few:
Maintaining Visibility: It's crucial that stakeholders can access the information they need when they need it.
Previously, we relied heavily on Slack for communication, which, while effective for immediate discussions, proved inadequate for tracking and retrieving project details. By integrating Linear, we've improved how we organize updates and track bugs and operational requests through the triage feature, allowing engineers to focus on their work while maintaining transparency.
Adopting a 'Shift Left' Culture: In our early days, the urge to move quickly often led us to bypass thorough spec development. Over time, we realized that the time saved initially was lost later due to issues like unclear product requirements or debates over system design during code reviews. Now, we emphasize the importance of investing time upfront in developing and approving detailed product and engineering specifications. This approach allows us to address potential issues early in the project lifecycle, although we remain flexible enough to create demos for de-risking projects even before finalizing specs.
Conclusion
At Saturn, we are on a mission to create the best calendar for anyone. We understand that such an ambitious goal requires continuous self-evaluation. Ongoing retros and continuous learning helps us refine not only our processes but also our culture, ensuring that we learn from our mistakes and constantly enhance the user experience.
Come help us build Saturn!
We are actively hiring for many roles across engineering and non-engineering positions. See our open roles, and join our incredible team changing the future of calendars.
