At Sequence, we're building the AI-powered revenue platform for modern finance teams. The likes of Cognition, incident.io, and 100+ other high-growth companies trust us to handle their entire revenue cycle - quoting, billing, invoicing, revenue recognition. That trust extends to every line of code we ship.

As our customer base grows and our team scales to meet it, we’ve developed a shared understanding of what "good" looks like. These principles help every engineer - whether they joined last week or helped write the first commit - know how we work and how we make decisions.

These aren't rules - they're a guide that help us to move fast and ship confidently as we continue building a best-in-class experience for our customers.

This is the sort of list that’ll never be done. We'll keep learning and iterating as we grow.

How we work together

Take ownership of problems

Strive to proactively identify and resolve problems within your area and be the driver of change.

Think about the customer experiencing the bug you're fixing or the real problem behind the feature you're building - not just the spec. Taking ownership means refusing to ship anything that falls short of our high bar, even when it's harder or takes longer. This might mean going beyond your immediate role - for example, analysing some logs to determine the impact of a change or prototyping a basic design to convey an idea.

You don't need permission to fix a bug, improve documentation, or refactor something small. Just make sure the team knows what you're working on - share it in triage or drop a note in Slack. For bigger decisions, like picking a new technology or breaking API changes, involve the relevant people early. If you're unsure whether something needs alignment, ask.

Thoughtful communication is a superpower

Investing in thoughtful communication multiplies our impact across everything we do - that includes how we write code, review PRs, send messages, draft proposals.

Ambiguity costs time. Write clearly, provide the relevant context, and choose the medium (docs, Slack, diagrams, etc) that helps your audience understand most effectively.

Make it safe to fail and share what you learn

When something goes wrong, we focus on the system failure, not the person. Blameless post-mortems, honest retrospectives, and supportive code reviews create space for experimentation and growth. If you made a mistake, own it openly - it helps everyone learn.

No one expects you have all the answers. If you're not making any progress on a problem, and it risks blocking your work, ask for help (by explaining what you're trying to achieve and what you've tried so far). If you solved something tricky, share it in Slack or our guild meetings. We get better as a team when we learn out loud.

Consider reversibility of decisions

There are two types of decisions: one-way doors (impossible or very difficult to reverse) and two-way doors (reversible). We move quickly, and our default should be good decisions at high velocity, rather than slow, perfect decisions.

When you need to make a one-way door decision (something with long-lasting impact or that's difficult to reverse) take the time to think it through carefully and involve others. For two-way doors, make the call and adjust as you learn.

Unblock others whenever you can

If someone is stuck, helping them is an incredibly high-value use of your time: spreading skills and knowledge levels everyone up.

If someone is waiting on you for a code review, feedback on a proposal, or an answer to a question, prioritise that ahead of picking up something new yourself. This doesn't mean dropping everything immediately - finish your current focus block, but make unblocking others your next priority.

Engineering excellence

Build for the person who’s debugging an incident at 4 am

We solve difficult problems, and we should strive to do this in a simple, consistent, and concise way. If code is hard to understand, it's probably too complex. Systems we can't reason about are especially prone to bugs, so keep things simple wherever possible.

Default to, at a minimum, providing brief comments for high-level decisions capturing the why. Assume your reader doesn't work in your team and has no background on this system.

Make changes small, make them often

Small and incremental changes make it easier to spot bugs, are faster to review, and safer to roll back. A 100-line PR can get thorough feedback in minutes; a 1,000-line PR can sit for hours or longer. Break work into the smallest shippable unit that adds value and contains enough context for a meaningful review.

The same idea applies to rollouts: gradual rollouts that can be easily rolled back (e.g., feature flags) let us find and fix problems before they become major annoyances to lots of people. “Big bang” launches are best avoided: they significantly increase the chance something will go wrong in a big way.

Tests aren't an afterthought - they're how we ship confidently

A strong set of tests gives us the ability to refactor safely, catch regressions early, and review changes faster. They're the foundation that lets us move quickly while maintaining quality.

When you build new systems, consider how to test them as part of the design, not something bolted on afterward. We're all responsible for ensuring adequate test coverage that gives confidence in what we're releasing. Good tests make code review faster and deployments safer.

Leave things better than you found them

Strive to improve things incrementally with each interaction – this could be any of our codebases, documentation, process, etc. Anyone can propose a change to any part of what we’re building, and you’re never stepping on anyone’s toes by trying to make things better.

Build reusable abstractions, tools, and automations that let the team ship faster. As we scale across a wide product surface area, well-designed building blocks mean we're not solving the same problems repeatedly.

Make technical investments that increase our velocity

Our velocity comes from removing friction and frustration. When you spot something slowing the team down, you have the context to fix it.

Slow CI? Speed it up. Flaky tests? Fix them. Noisy alerts? Fix the code or update the alert. Mass confusion about how something works? Write a doc. These investments compound over time.

For small improvements, just do it (and share what you’re working on with your team). For larger ones, ask yourself: will the time spent fixing this be less than the time we'd spend working around it over the next few months? If yes, it's probably worth doing.

Identifying problems is useful, but solving them is what moves us forward. If you spot something worth fixing, either fix it yourself or create a clear plan so someone else can pick it up.

Run less tech

Before adding something new, ask: can we solve this with what we already have? Every technology is a long-term commitment. New tech should only be adopted when the benefits clearly outweigh the costs of learning, debugging, and maintaining it.

When selecting technologies, favour mature, boring technologies over shiny new ones. Boring tech has fewer surprises, better community support, clearer hiring paths, and lets you innovate where it actually matters: solving customer problems.