Blog/Team

Tight enough to move fast. Deep enough to matter.

A tight, multidisciplinary, fully distributed team spanning a thirty year range in age and experience: systems researchers, software engineers, and production veterans built into a lean execution and research machine, not a headcount to grow past.

Tight enough to move fast. Deep enough to matter.

I've stood in an incident channel with forty people in it, watching an outage get worse while everyone waited for someone else to make the call. I've also stood in one with five, where the right five people found root cause in eleven minutes and went back to bed. The variable that mattered was never how many people showed up. It was who, and how few.

That's the team we've built: small by design, not a stage on the way to fifty. What makes it work isn't the number, it's the mix. Multidisciplinary depth, a real range of age and experience, and a lean, focused machine built to execute and to do actual research at the same time.

The team together in Athens, with CTO Panagiotis Moustafellos presenting at the front of the room.
The team together in Athens, with CTO Panagiotis Moustafellos presenting at the front of the room.

The math nobody puts in the pitch deck

It's combinatorics. Add a person to a team and you don't just add their output, you add every new pair of people who now have to stay aligned, and that count grows faster than the team does. It's the same logic behind Brooks's Law: past a certain size, most of a company's energy goes into keeping everyone pointed the same direction, not into the actual problem. We optimized for the other side of that curve: fewer people, chosen so each one adds more than the coordination they cost.

Multidisciplinary by design

That only works if everyone in the room earns their seat. This team includes systems researchers, post-docs and PhD candidates who could have stayed in the lab, SREs who ran production at major companies and didn't have anything left to prove, engineers with serious security backgrounds who've spent careers thinking about how things get broken into, and people with decades of production experience who've already seen every failure mode twice.

A team built from that bench operates like a much larger team of generalists, because there's no translation layer between the person who understands the failure mode and the person who ships the fix. Nobody needed this job. They took it because the problem, reliability decided before things break instead of firefighted after, sits close to the unsolved edge of the field, and a team this dense can work right at that edge.

Month zero

I sent out the offer letters myself. I expected the usual spread: a counter from one, a month of thinking from another, a couple of no's from people with every reason to stay where they were. That's not what happened. Every one of them said yes, and every one of them wanted to start nearly right away. What I thought would take a few months to put together as a team happened in month zero.

The only explanation I have is that they inspired each other as much as the mission inspired them. Once one person with real conviction says yes, the next conversation gets easier, and the one after that gets easier still.

The range

Age and experience might be the biggest advantage nobody talks about in hiring. The team spans nineteen to forty-nine, a thirty year gap that's rare to find in a group this size. A twenty year old sees the fresh way to use a new tool before anyone else does. Someone twenty years in sees the failure mode that tool will eventually hit, because they've already watched an earlier version of it happen. Put both of them, plus a systems researcher and a security engineer, in the same room, and the blind spots any one of them would have alone mostly disappear. That range compounds. Cut it, and you're left with only fresh eyes or only scar tissue, never both at once.

The mix isn't where I'd like it everywhere. Four of our fifteen engineers are women. That's not a ratio I'll dress up, and we're actively working to change it.

Distributed by default

The team is fully remote. There's no office to work from, so most of what we do is asynchronous by default: pull requests, written proposals, recorded demos, Slack threads that turn into design docs. That's how nearly everything gets decided.

Some problems don't fit that mode, and I've stopped pretending they do. A real technical disagreement, the kind where two smart people are working from different mental models of the same system, gets resolved faster in a room with a whiteboard than across a week of messages. So a few times a year, I get the whole team in a room together: to calibrate, to build the kind of trust that makes the async work faster the rest of the year, and to grind through the problems that need two uninterrupted days of full attention. Those two days produce a jump you don't get any other way.

Earlier this month that room was in Athens, the whole team together for the first time: two days of keynotes and tech sessions, people meeting in person who had until then only known each other from a screen. I won't tell you what was on the whiteboards. Some of it is roadmap we're not ready to talk about publicly, some of it is research we want to publish properly instead of teasing it here. What I will say is that a distributed team this senior, given two days and a room, moves further on hard problems than most teams move in a quarter.

The roadmap

A team built this way gives us engineering capacity that's real without the diminishing returns a bigger team would carry. We now have a full twelve months of roadmap, sequenced, with owners, built around the same three pillars we started with: a live, causal model of production, a memory layer that gets sharper with every incident instead of just larger, and a control substrate that gates what any agent or engineer can do before it touches production. For the first time we have enough range across enough people to push on all three at once instead of taking turns.

We're keeping the team this size on purpose for the next three to four quarters, with maybe room for one more hire. Growing headcount isn't the problem in front of us. Novel research and genuinely new approaches don't get faster with more people in the room, they get slower, so we're optimizing for speed of execution, not size. This is what a lean, focused execution and research machine actually looks like from the inside: not a lot of people, a lot of range, and almost no motion wasted on coordination. Team scaling is a real problem. It's just next year's problem, not this one. What's in front of us right now is going deeper on the parts of the product some of our customers and design partners are already falling for.

Fewer people in the room, and every one of them someone you'd trust to drive the incident. That's the whole design.

See what this team is building, book a demo.

Talk to a founder

See where your agents are blind in production.

A 30-minute call with a founder. We map your stack to the Context & Control Model, live.

Book a demo