How we use engineering cycles to get work done

What our execution rhythm looks like at an early stage company

We believe building Plus is a marathon, not a sprint. When we started growing the engineering team, we needed an execution rhythm to help us stay aligned on our goals, create shared visibility across the company, and enable us to make steady progress as a team.

We took a look at what worked well — and didn't work so well — for us at previous jobs, how other companies were tackling this problem, and considered our unique needs as a very early stage company.

Defining our goals

When we began developing our execution rhythms at Plus, we started by clarifying our priorities and constraints.

We wanted our team to focus on getting work done, rather than getting bogged down by unnecessary overhead. We wanted to introduce the minimum amount of process to create a shared understanding of what's being worked on and how we're tracking toward milestones and goals.

As an early stage startup, we work on lots of exploratory and ambiguous projects (like research, prototyping, experimentation) which have different project management needs. Our bias toward experimentation and iteration also means we can't plan in great detail more than a month or two at a time. So we also needed a process with flexibility to accommodate that ambiguity and uncertainty.

On the other hand, our very small team size means that communication and coordination costs are low. We don't have non-product teams yet, so there aren't separate marketing, sales, and customer success rhythms that we have to stay in sync with. This meant we could keep our processes lightweight, without multiple, cascading levels of planning and project management.

Our development cycle

We use a project management tool called Linear, which is organized around a "cycle," similar to an agile sprint but not tied to a specific release.

We run two-week cycles, which most of our team were used to and felt like the right cadence for us. We wanted to balance making continuous progress in smaller iterations (shorter cycles) against minimizing overhead and having enough time to do deep work (longer cycles). Our cycles start mid week and run from Thursdays to Wednesdays, because we want to avoid Monday and Friday holidays and minimize Friday evening meetings for our European teammates.

Engineers write their own issues, break down larger projects into incremental tasks, and are responsible for assigning their own estimates. We're not dogmatic about how issues are written, as long as they provide clarity about what's being worked on to both the person doing the work and everyone else on the team who needs context. This work happens asynchronously, outside of the full-team cycle meetings, which are limited to two hours across the entire two-week cycle.

We create a high level product roadmap every quarter, but we reprioritize often throughout the quarter. At the beginning of every cycle, we review every person's goals for what they will accomplish during that cycle. We summarize this in a Notion document, rather than reviewing individual tasks in Linear, which helps us focus on the bigger streams of work across cycles. Then we jump into Linear to make sure work is accurately reflected and to triage and assign bugs and smaller tasks. We try not to get bogged down by specific scoping or implementation discussions, and instead table those for project-specific meetings (usually a weekly check-in with 3-4 people.)

At the end of the cycle, we demo our work and review our progress against the plan. Work that isn’t completed moves into the next cycle. Rather than "sprinting" toward arbitrary finish-lines, we want our cycles to feel like we're moving forward in sync as a team, at a steady and sustainable pace.

Iterating over time

As our company grows, our engineering rhythm will also evolve. In the last few months, we've tweaked some of our cycle meetings and consolidated some rituals that didn't feel useful. As our team has evolved, we've changed the way we do pre-planning and backlog grooming. We're also still working on — and expect we'll always be working on — getting better at estimating our work.

We have a lightweight process that works well for us today, though we know if we're successful as a company, we will outgrow it sooner or later. We don't know how our execution rhythms will evolve in the future, but our goal will always be to create an environment where people feel aligned around our priorities, understand what's going on, and feel unburdened to do their best work.


💬  If you’re interested in joining a team like this, take a look at our careers page to see what openings we have available. You can also message me on LinkedIn if you’d like to learn more about our team’s processes. And, if you’d like to see how Plus brings together all of your team's data where you need it, without having to worry about complicated setup or integrations, request an invite to join our private beta - we’d love to hear your feedback!