My first 3 months at Sequence

Probation, passed

I've recently passed probation at Sequence and figured my internet-free time would be well spent reflecting on how the first few months have gone. I hope reading this gives you some insight into what my time here has been like, and maybe helps you make whatever decision you're trying to make. Even better if it makes you chuckle once or twice along the way.

When I decided to change jobs, I knew I wanted to move somewhere that moves fast, that owns the work it does, that takes pride in what it does. I wanted to be somewhere that pushes me to always strive to be better, to learn, to improve.

Before I landed

When I was going through Sequence's interview process, I didn't quite appreciate how selective it is.

Only now, being on the inside, am I seeing the time, thought, and care put into hiring. It's been further streamlined since I joined - my process took about seven weeks from initial interview to offer; whereas someone recently went from the technical interview on a Monday to an accepted offer on the Friday, which (other than being pretty nuts) is quite telling of Sequence.

The questions we often ask are:

• Is there an action to be taken here?
• How can we do this better?

I had a long notice period so didn't actually join for nearly three months, but I was made to feel part of the team well before I officially started. The team invited me to their annual Christmas dinner, where I got to meet the people who'd interviewed me, people I'd be sharing the office with, my future teammates, and everyone else I wouldn't be interacting with daily but who play an important role in keeping the business running.

They did a Secret Santa (which I wish I'd been informed about because I do love spending money on presents), and they made sure there was a present for me too. I think it was that simple act that made me certain this was going to be the right cultural fit for me. That and Daniel shrugging it off when I thanked him with a very casual, matter-of-fact reply: “You're part of the team now”.

I remember coming back home (with my Secret Santa LEGO set that matched the decor of my flat suspiciously well) absolutely buzzing. This group felt easygoing and welcoming. I felt like I'd been part of the group for a long time, like I hadn't only just met them. They were motivated, excited about the work they were doing, and invested in where the company was headed. Not something you can always expect from a team.

In the week leading up to my start date, I got an email with detailed instructions on how to get myself set up. My Google account was set up, a new MacBook Pro had arrived, and I was welcome to pick it up that week or on my first day. The rest I was okay to set up myself.

This is where I started learning how well documented everything is. The email had initial instructions on access setup, but once you were through that, almost anything else you wanted to know was accessible to you. I still didn't have access to the codebase, but short of that I knew what projects were going on, what teams were in charge of each, the tech stack, engineering standards, principles, and a bunch of amazing Notion docs (special shoutouts go to Kotlin Engineering Standards and How we review code).

The first week

Being a keen bean, I turned up at 8:30 on day one (you access the office via a mobile key provided before you start). By 10am I had access to the codebase. By noon, I had merged my first PR - a small one, setting up the build bot to be notified of PR failures, merges and deployments.

By 3pm, I was in my first standup with my new team: Team Badger - one of three engineering teams at Sequence. I'd met all my teammates, met my onboarding buddy, and had been given my first ticket. I also learned about 'badger bugs'. By 6pm, I was deep in the trenches of the codebase, attempting to understand our CPQ offering - helped along by a set of in-repo docs, rules and skills written specifically for agents, which meant that Claude already knew many of our conventions and could help me poke around. That was the first hint that AI tooling wasn't a side experiment here; we've heavily leaned into it and made it part of how we work.

The rest of the week went something like this:

• Day 2: completed my first ticket, first deployment to production
• Day 3: first bit of deeply unattractive but necessary infrastructure work: gRPC removal (more on that coming soon to this blog, cc Daniel and Project Fusion)
• Day 4: first bit of project work, picked up off a teammate who was busy with on-call: a long-requested feature for authentication in our customer portal application. Non-trivial, and a very nice first project to get stuck into
• Day 5: I fell asleep at 9pm, like an overstimulated (and exhausted) toddler. Five days in the office and a lot of new context had clearly drained the poor introverted me

First deployment to prod on day two - scary, right? My experience up until this point had been working with banks as customers, which meant long release cycles, lots of manual testing, long UAT periods, and working with the customer to drop new features into production. All of this would take multiple weeks (if not months) and would almost always result in various issues on the day.

It was a huge mindset shift to suddenly accept that any time you merge code, you deploy to prod. For context, we have three environments (dev, sandbox, production) and we deploy changes to all three right after the code is merged. I remember challenging Alen (our principal engineer) about it but walking away empowered to (1) build with confidence and test thoroughly, (2) make it safe to break and (3) break fast and fix faster.

At Sequence, PR reviews are taken seriously (see previous notes on my favourite Notion docs). Here is a quote from our docs that really stuck with me:

When we review code, we're thinking about the engineer who'll be debugging this at 2 AM during an incident, the new team member trying to understand how the system works, and our customers depending on our platform to deliver accurate, reliable results.

We let AI take a first run at the review before a human gets to it. It's become pretty normal now, but I remember it being super cool when I first had Cubic (one of our AI pull request review bots) leave a comment. And it got it right!

Week two, and shipping something real

In week two, we shipped my first bit of project work. Customer portal auth was now live and available for customers to enable. It blew my mind that my name was in our changelog next to this feature within ten days of landing in the company.

Shipping this fast works because we do trunk-based development with lots of feature flags. It allows us to roll out changes when they’re ready without worrying about breaking production. Do we occasionally misuse them? For sure. We move so fast and lean on flags so heavily that they sometimes end up living longer than they should. Someone recently mentioned that feature flags get brought up in our full-stack guild every 6-9 months, almost like clockwork. We then go through the cleanup exercise, then swiftly move on to shipping and leaving more flags in our wake. I am hoping we break that cycle this time around - we are putting some guidelines in place on when to use feature flags, best practices and expectations on cleaning them up.

We tend to run a QA session when a new feature is shipped - I learned this when I planned one for the customer portal auth change. Just a few of us who worked on the feature and someone from the customer success team. There's only one degree of separation between an engineer and a customer: the customer success team. Having that customer perspective represented made me feel more confident the feature would perform in a way our customers expected.

It was there that I started realising everyone in Sequence was slightly more than just an engineer. You stray a lot more into the product side of things, you learn about the industry, our competitors, our customers, but also our roadmap, our ICP, and you soon find yourself taking all of that into account when planning a feature. You no longer build per ticket. You build features with customers in mind.

The flipside of all this - the speed, the ownership, the proximity to the customer - is that we sometimes get ahead of ourselves. Move too quickly to build something before properly validating it with product or customer success, and you can end up reworking it. I've seen it play out a few times and we've taken some learnings from it since. We aren't too down on ourselves about it - the whole thing works because we move fast with a just enough, just in time approach. That tension between speed and getting it right isn't a flaw in the model; it's kind of the point. But there is always room to improve, so why not try?

The Pulse rotation

Sequence engineering is split across three teams: Badger (my team, handling CPQ and automations), Pulse (all things billing engine) and Inevitable (death and taxes, right? - invoices, credit notes, revenue recognition, and yes, taxes).

Everyone new to Sequence gets to do a Pulse rotation soon after they join. Mine started about seven weeks in. By the time I started on Pulse, I'd been in Badger long enough to notice something about how we work. We are a small and scaling team, so there are a lot of parallel work-streams running at any given time. Sometimes they are spread across people, sometimes they pull a single person in multiple directions. It keeps things moving and means we get through a lot of work simultaneously, but it does mean context switching can be painful. It's something the team is aware of - another thing that gets raised often that we try and stay cognisant of. Pulse was similar yet different - more reactive, but still very focused in the day-to-day.

Pulse was so much more fun than I expected. Part of this was down to the timing of when I landed into it, and part of it was the chance to dig deep into what underpins Sequence's offering. Pulse (and our billing engine) had worked through months of infrastructure improvements. I only caught the very tail end of it - some of my early Pulse tickets included addressing race conditions, undelivered Pub/Sub messages, and long-running database transactions. Not the most exciting work, but highly valuable to the stability of the platform.

During my Pulse rotation, I became a big advocate (as has everyone else) for acceptance testing - tests that exercise real domain logic through in-memory infrastructure implementations at unit-test speed. It's meant that we can write up desired scenarios that test actual behaviour rather than implementation before starting to iterate. These have also become the source of truth and expected behaviour for specific features within the codebase. Proper TDD, finally living up to its name.

This is where Conductor became so powerful - I can kick off work in parallel across several workspaces, burn through Claude usage limits, and ship faster than I ever had before. Building with AI rather than alongside it had been there since day one, but Conductor made it feel like a force multiplier. An AI hack day a little later crystallised it: people built a billing agent that could explain a billing schedule, a Sequence MCP, and an agent that detects when customers are at risk of churning. The output was cool, but the actual point was getting hands-on with the infrastructure of setting up and building agents. Apply all of that across a small team and it suddenly starts to make sense how we get through so much.

So, was it what I expected?

Mostly, yes; and sometimes more.

I wanted somewhere that moves fast, that owns its work, that pushes you to be better. I got that. I also got very close to customers. It's given me a slightly different perspective - I've started thinking about the why a lot more than the what. It hasn't taken away from being an engineer; on the contrary, it's made me a more informed, more rounded engineer who is part of a business, not next to one.

The bit I didn't quite expect is the culture. I appreciate that sounds like a very generic word, but it's the best I've got (English is my second language after all). It's the unspoken agreement that everyone is pulling in the same direction: jumping into incidents and helping out even when you're not on call; taking on more work to free up someone who's been pulled into higher priority things; or proactive improvements that make everyone else's life easier, not just yours.

If you've made it this far, thank you for powering through my ramble. You must be very keen to learn about Sequence (because you sure aren't here for my writing skills, I write more code than prose). We're hiring across New York and London and would love to hear from you!