How to move fast and not break things as a remote company

The Facebook-era “move fast and break things” startup motto no longer applies in today’s hyper-competitive environment. This is especially true for SaaS startups like Jam, where customers trust and rely on their products to complete their work.

If you’ve met anyone on the Jam team, you know we like to move as fast as possible...

...but, we also never want to deliver a broken experience. So, how to move fast without breaking things? Especially as a remote team?

As any developer knows, there's no one magic bullet to developer productivity. Here are 8 things we do as a team that support us moving fast while keeping quality high.

Tip #1 – the easiest way to unblock developers is to write clear tickets.

Creating clear, complete tickets is an easy way to unblock developers to move faster and fix more issues for customers.

When developers pick up tickets that don't have all the information they need, they need to spend more cycles investigating and waiting for follow up information from the broader team. This leads to developer time spent spinning wheels, and more expensive context switching too.

Giving developers all the info they need upfront helps them move fast and seamlessly zip through a bunch of fixes all at once.

At Jam, we use Jam to create tickets – so developers automatically get all the device, user, and debugging context they need right in the ticket.

Tip #2 – weeks of engineering can save hours of planning.

^ As Jam's engineering lead Tony Stuck puts it!

It's counter-intuitive but slowing down to spend a day planning the technical implementation of a feature first, rather than jumping in right away to start writing code actually helps us move faster in the long run.

Thinking through the technical implementation of a feature in the full context of the product and where it will go helps us write code patterns that are easier to build on top of later.

This helps us keep shipping fast over time because of a cleaner, more predictable architecture, and prevents bugs from popping up later that take up engineering time to fix.

The way this is implemented in action is as a checklist step in our software development process. After product spec and kick-off, the next step is for engineering to spend a little bit of time writing a technical plan.

Tip #3 – we set timelines on a Google Calendar.

Having a clear timeline is a great function for keeping us focused and forcing us to prioritize.

Kind of unique, but we put our project milestones on the calendar so they are easy for everyone to see and plan around.

Having milestones put on the calendar also gives us the flexibility to move them when needed, but makes it so that we consciously need to decide to move them, rather than letting dates slip by.

Tip #4 – stoplight system to check in on projects leading up to milestones.

Along with having clear milestone dates, we also use the stoplight system to communicate along the way how we are doing on those original estimated dates. The stoplight system is:

• 🟢 Green: near 100% certainty we are on track.
• 🟡 Yellow – we might be on track but it’s not 100% sure.
• 🔴 Red – definitely off track.

In the stoplight system, there is no such thing as "greenish yellow" or "yellowish red". You have to choose.

Having a daily check in on the project status helps us recognize when we are drifting off track and need to make decisions about whether to change the date or re-prioritize what's in scope.

Tip #5 – more code comments.

This makes it faster for engineers to contribute anywhere in the codebase successfully without breaking anything.

Tip #6 – feature flags so we can ship low-risk, and often.

We develop most new features behind a feature flag. That way we can ship frequently and quickly, but make those changes low risk. Once we've verified the feature works great in production, we can choose to roll it out gradually or all at once, also helping us move fast while de-risking changes.

Tip #7 – make things better as you go.

In every company, there's a balance between building new stuff and cleaning up old stuff. At Jam, we like to take a little bit of extra time to clean things up as we go. That way we don't need to pause for longer for bigger cleanup later. Of course we want to ship as fast as possible, but we always find it worthwhile to spend the extra day on the tail end of a project to clean things up.

Tip #8 – retros after every project.

To move fast and effectively together, it's really important for us to all continuously collaboratively improve how we work together as a team. We hold a 15-30 minute retro after every major project.

All of the tips above are things we started doing as a direct result of something one of us suggested in a retro. Retros are awesome, and are so important.

Happy building

Hope you enjoyed these tips and found one or two you can try! Let me know if you do give one a try – would love to hear how it goes.