Written by Olena Listratova, Technical Lead I, Rep Quoting Experience @ HubSpot
I remember when I was just onboarding into my team, the thing that was the most surprising and questionable was how the development cycle was organized.
Back then, based on my previous experience in many different environments, I strongly believed that the most efficient, controllable, and predictable flow was a two-week-long Scrum sprint. Imagine how startled I was when I learned that my new team was using a quarterly cadence. Even if the overall workflow was partially inspired by Scrum, it definitely did not follow it in all aspects.
To get my head around this required a mindset shift. But now that I’m in, I see the benefits and understand how the whole thing is viable (and allows my team to thrive).
Process overview
In short, the process can be summarized like this: at the beginning of the quarter, the team commits to delivering a set of projects. Every feature has a DRI (Directly Responsible Individual). We meet daily as a team to align on current statuses and weekly to align on the quarterly plan. We release features as soon as they are ready. As easy as that.
To expand on this a bit more: an average 2-week scrum sprint would have daily stand-ups, a planning, a grooming (maybe several), a sprint review, and a sprint retrospective.
An average month schedule for teams on a 2-week Scrum cycle: orange boxes for team meetings.
Our quarter has all of these ceremonies but in a different proportion. We meet for daily stand-ups, we meet weekly for planning, and we do a monthly retrospective. All the other communication is happening in relation to a specific project, so only people directly involved are participating. And, sure enough, the way we communicate can vary: sync or async is up to the participants to choose.
An average month on a quarterly cycle: orange boxes for team meetings, other colors – for project-specific meetings. Fridays are meeting-free.
Key difference: we spend less time on team-wide meetings, and we have more time for more dedicated conversations or heads-down work.
But how do you choose what to work on?
No surprises here — how we choose what to work on is based on business priorities. But priorities are diverse and weighing them against each other can be quite challenging.
Our work revolves around two main topics: product development and technical excellence.
At HubSpot, we have a well-defined product operating system, Mainsail. It defines the hierarchy of needs that teams should use when making decisions around prioritization. Mainsail dictates that guardrails (like security, privacy, reliability, etc.) come before product goals.
Product goals are shaped by our business and customer needs. They are coming in the form of prioritized OGPs. These are the features and improvements that drive our product forward.
So as the team leadership, we take these two work streams and form a quarter plan out of it. There are things that are absolutely required — we commit to delivering those. And there’s an optional scope — we want to work on that, but give no promises on delivery.
Key difference: the plan consists of committed and additional scopes, leaving room for maneuvers when the need arises (and we all know it will arise – when new requirements appear, a critsit happens or priorities get updated).
We don’t have a strict formula for how much time we spend on product work versus purely technical work. In general, we aim to solve as many customer problems as we can, which usually means focusing on product development. But we also know that keeping our tech foundation strong is essential to delivering a great product and therefore prioritize proactive technical work every quarter.
How do you structure the actual work?
We use the DRI (Directly Responsible Individual) model to drive projects. The idea is that every project has a DRI who is ultimately responsible and accountable for the success (or failure) of a project. Depending on project scope and complexity, there can be a dedicated DRI for different areas of it: engineering, design, enablement, legal, etc. Being the responsible person doesn’t necessarily mean that you are the only contributor though. But it’s on you to decide if more contributors are needed, who should be included in discussions, and how exactly things need to be done.
At HubSpot we believe that engineers should do more than just write code — we are expected to understand what problem we’re solving and how the solution will affect the business in the longer run. You can never do that on your own.
We work closely with the product team to figure out the best technical solutions, ensuring that what we build is both smart and aligned with our product vision. Working with other engineering teams is a big part of our process too. Each team has its priorities, so it’s important that we’re all on the same page and can adjust our timelines to work together smoothly. Flexibility is crucial here — it helps us remain operating frictionlessly, even when things change.
Key difference: teams have a lot of autonomy, engineers have a lot of autonomy. We care about the work being done and we trust engineers to choose the best path towards achieving that.
So having all the requirements assembled and all the involved parties and their availability known, a DRI comes up with an implementation plan. The bigger a project is, the more demanding the preparation phase is. But normally, after things have been discussed and settled, the engineering work kicks off and runs smoothly with few surprises.
Key difference: a team is normally working on multiple projects simultaneously, but individual contributors do not need to be deeply involved in all of them – only in those, where they are actively participating. That being said, it’s on a DRI to ensure that relevant information is shared across the team to keep everyone high-level informed and prevent knowledge silos.
A couple thoughts on productivity
At first glance, a quarterly cadence might sound like a more laid-back way of working. But it’s designed to boost productivity while keeping the stress levels of individual contributors low. By building trust and transparency within the team, we create a space where people feel safe to work at their best. There’s no constant pressure of unfinished sprints hanging over our heads every two weeks. Instead, we’ve got a clear plan for the quarter, so everyone knows what’s coming and how their work fits into the bigger picture.
This setup gives us the flexibility we need while maintaining a focused approach to our work. The team has a clear idea of what to expect, which reduces stress and keeps us moving forward efficiently.
Bonus: what if things go wrong?
We all know this: priorities change, requirements turn out to be incomplete, stakeholders change their minds, a vendor causes unpredictable issues – you name it. These are all painful and most probably lead to a change in the plan.
Changing the quarterly plan is something that happens inevitably, and it’s on the team leadership to make it as painless for the team as possible. In the end, a plan is just an educated guess. We make a guess of what our coming 3 months will look like and then, as life evolves, we adjust our guess accordingly.
There are a couple of guidelines, that help us handle the plan change:
Wrapping up
In the tech world, the 2-week sprint is often seen as the default approach. It works well for a lot of teams, but it’s not the only option out there. Our quarterly cadence suits our needs and allows us to work in a way that feels more strategic and thoughtful.
As engineers, it’s important to challenge the norms and find what works best for your team. There’s always room to tweak and improve your process, and finding the right rhythm can make a big difference in how smoothly and happily your team works together.
Are you ready to make an impact? Check out our careers page for your next opportunity! And to learn more about our culture, follow us on Instagram @HubSpotLife.