How we run our team: experiments, mistakes and what stuck

From the outside, it’s hard to tell how an engineering team actually works: how decisions get made, how much say people have, and whether the process helps or gets in the way. This post is our attempt to show that honestly. The short version is that the way software gets built has changed a lot in the last couple of years, and we’ve let it change us too.

We should be upfront: we haven’t got it all figured out. We still get plenty wrong. Specs miss the obvious case. Process hangs around longer than it should. Some weeks the quick wins crowd out the bigger work, and some weeks it’s the other way round.

What we do have is a team that loves experimenting. We try things, notice honestly when they don’t work, and make them a bit better next time. This post is a snapshot of how we run things today, mistakes included. It’ll look different in a year.

Where the time goes now

Not long ago, most of an engineer’s day went on writing code. Now, most of our code is written by engineers working with AI agents, and the time has moved to either end of the process.

More time up front. An agent will happily build exactly what you asked for, gaps and all. So we put real effort into specs: what the problem is, who it’s for, and the edge cases. In our world, the edge cases are often the product. AI helps here too, by poking holes in a spec before anyone starts building.

Building is the fast part. With a clear spec, a change that used to take days can take hours. That’s changed what’s worth doing, because work that was never worth the effort before often is now.

More time on review. Every pull request gets an AI code review first, which catches the code-level issues, then a teammate who judges whether it’s the right change. The person approving it has to understand it, whoever or whatever wrote it.

Watching it live. Once a change ships, monitoring catches errors and AI drafts a fix for an engineer to check. Small changes go out many times a day, so nothing turns into a big, scary release.

The bottleneck used to be typing. Now it’s thinking clearly and reviewing well. That’s where most of an engineer’s time goes here now: understanding the problem, shaping the solution and making sure it’s right, with far less on boilerplate.

Trying things, and undoing them

When the tools change this quickly, yesterday’s process can turn into today’s overhead. So we treat process the way we treat code: try it, see if it earns its keep, and delete it if it doesn’t.

The rule is simple. Drop anything that isn’t helping, and bring it back the moment the team genuinely feels its absence. Bringing something back just means the experiment did its job.

Code review is a good example. We tried handing it over to AI entirely. We shipped faster, and for a while it felt like a clear win. Then we noticed quality slipping: nothing dramatic, but more small things reaching production that a person would have questioned. So we caught it, and we’re dialling it back to find the right balance.

What we learned is that our AI reviewer is excellent at the code itself. It finds bugs, edge cases and sloppy patterns faster and more consistently than any of us. What it can’t do is judge whether a feature is right: whether it solves the actual problem, fits how people use it, and is what we should have built in the first place. That still needs a human.

We try new tools and ways of working all the time, usually in one pod first. If it works there, it spreads. If it doesn’t, we write down why and move on. Anyone can suggest a change, however new they are.

Small pods with real ownership

We work in small pods, each owning a part of the customer journey: Estate Planning, Probate, Web, and a stealth fintech pod we can’t say much about yet.

Each pod has a lead who owns its technical direction and a product owner who works alongside it every day. Pods work closely with the people who know our customers best, too: advisors, Estate Planning Consultants and the legal specialists who know every edge case by heart.

We give pods a problem to solve rather than a list of tickets. How they solve it is up to them. A pod decides how to build something, ships it, watches it in production and fixes it when it breaks. Nobody waits for another team to deploy their work, and nobody needs permission to try a new tool or a new way of working. Most of our process experiments start in one pod for exactly that reason.

Autonomy comes with a few shared guardrails. Every change is reviewed. Anything touching legal rules, money or personal data gets extra care. New services start from the same shared infrastructure, so nobody reinvents the basics. Inside those lines, pods are free to do what works for them.

It doesn’t always go smoothly. Sometimes two pods solve the same problem in different ways, or a good idea stays stuck in one pod for too long. When that happens, we share what we’ve learned and line things up again. That’s a price we’re happy to pay for teams that move quickly and own what they build.

That ownership starts early. New joiners ship in their first week and own the result in production, not just the code. As we grow, they land in whichever pod they can make the most difference, and they have a say in where that is.

How we make decisions

We talk things through openly, and anyone can push back, whatever their role or however long they’ve been here. Some of our best changes started with someone new asking why we do something a certain way.

We aim for consensus, and most of the time we get there. When we don’t, we don’t let it stall the work. Whoever owns the decision, usually the pod lead or product owner, makes the call. Then we disagree and commit: everyone backs the decision fully, including the people who argued against it.

Committing doesn’t mean going quiet. If you think a decision was wrong, say so, and bring evidence. Plenty of our calls get revisited once we’ve seen how they play out, and the code review change above is one of them.

We also match the effort to the stakes. A decision that’s easy to undo gets made quickly. One that’s hard to reverse, like anything touching legal rules or people’s data, gets more time and more voices.

Quick wins and longer bets

Every pod juggles two kinds of work.

Strategic plays are the bigger bets that move the business forward: a new product, a rebuild, a capability that takes months. They need focus, so we protect time for them and don’t let them get chipped away.

Tactical wins are the small things that make someone’s day better right now: a fix an advisor has been asking for, a report the operations team needs, a rough edge in a customer journey. With AI, many of these take hours instead of weeks, so saying yes is cheaper than it used to be.

The skill is in the balance. Pods flex between the two depending on what the business needs that month, and leads and product owners decide together where the line sits. In practice, most of us get both: a fix an advisor has been asking for, shipped by Friday, alongside something bigger that’ll take months to land. One keeps us close to the people we build for. The other lets us build something that lasts.

What we measure, and what we don’t

We measure the system, not the people in it. The question is never “who’s slowest?” It’s “where does work get stuck, and what would unstick it?”

We look at three kinds of signal.

Flow. How long work takes from starting to shipping, both the typical case and the slow tail, because the slow tail is usually where the interesting problems hide. Alongside that, how much is in progress at once and how much we finish each week. When too much is half-done, everything slows down, so that’s often the first thing we fix.

Health. How often we deploy, how often something breaks, and how quickly we put it right. With AI drafting a fix and an engineer checking it, the gap between an error appearing and the fix going out can be as short as 18 minutes.

Outcomes. Whether the thing we shipped actually helped a family, an advisor or a consultant. Product owners stay with a feature after it goes live, and they’re the first to say when something didn’t work.

We also keep an eye on how much of our code is written with AI. It’s well over half now. We don’t treat it as a target, but it tells us whether our tools and habits are keeping up.

What we don’t do is count lines of code or rank engineers against each other. Those numbers are easy to collect and almost always point in the wrong direction. Nobody here is chasing a leaderboard.

What it’s like to work here

It’s a team that moves quickly and talks a lot. You’ll see your work in front of real users within days, and you’ll hear what they thought of it soon after.

It’s also a team still working itself out, and happy to admit it. We’re growing, some of our process is a few months old, and parts of the codebase are older than we’d like. If you enjoy shaping how a team works as much as what it builds, you’ll have plenty to get stuck into.

Like the sound of this?

We’ll write more about each of these, including the things we’ve changed our minds on. In the meantime, if you’d like to help us work out what a great engineering team looks like now that AI is part of every step, take a look at our open roles.