What it feels like

Architects, not just coders

An agent might run for an hour on a single task. That hour is not downtime. It is spent on the architecture, the trade-offs, or the next problem.

The skill that matters is knowing what to ask for, recognising when what comes back is wrong, and having the judgement to say so. If what you love is the craft of writing every line yourself, this will be a frustrating place to work, and we would rather say that now than after you have joined.

Ours, not mine

Our tooling and processes belong to everyone, and everyone is expected to improve them.

If a skill is not working, the answer is not to complain about it. It is to fix it, validate it, and contribute it back so the whole team benefits. The MO_AI plugin is deliberately hackable for exactly this reason: anyone can adjust a rule, write a new skill, or change how something behaves.

Friction is feedback. The resistance you hit is data for the next improvement. People here are trusted to pull the levers themselves, and expected to.

Direct and honest

We say what we think, and feedback runs in every direction. Leadership actively asks what is working and what is not, and means it.

Problems get surfaced early, credit gets shared, and nobody has to guess where they stand. That directness is a feature rather than a rough edge. It is what lets a team move quickly without things quietly going wrong underneath.

Always levelling up

We think about capability across four dimensions: human interaction, engineering, AI orchestration, and product skills. We invest in all four rather than only the fashionable one. Using AI well is one part of the job, not the whole of it.

Counsellors help people shape development plans. MO_PRO, our internal product thinking programme, has been taught across the company: thirteen sessions, run Socratically, with a case study at the end applied to your own live project. Sessions are led by our own engineering, design, QA and validation leads rather than bought in.

The goal is not to become someone who can operate a tool. It is to become a more complete product builder. See how we decide what to build.

An operating rhythm

Fast where it counts, calm where it matters. We move quickly because the fundamentals and the tooling allow it, not because anyone is being pushed.

Days have shape. Regular sync points keep everyone pointed the same way, and the rest is protected for deep, focused work. Automation carries the mundane: dependency bumps, first-pass reviews, error triage. The all-hands runs roughly fortnightly.

Where we are

Teams in London, Cape Town, Bangkok, Guadalajara and Portland, working across time zones as one team rather than five branch offices.

We work hybrid. There are offices in all five locations and we are keen on office time, because the informal part of the work, the overheard problem and the conversation that saves a week, is hard to replicate on a call. Nobody is counting days, and the balance is agreed within each team rather than set centrally.

Bangkok

Cape Town

Guadalajara

What we look for

A few honest markers of who does well here, and who does not.

• You are energised by judgement, framing the problem, making the trade-offs and directing the build, more than by writing every line yourself.
• You improve the shared tooling rather than working around it. When a skill misbehaves, you fix it and contribute it back.
• You want feedback in every direction, and you give it straight.

And the honest disqualifier: if what you love most is the craft of hand-writing every line, this will be a frustrating place to work. We would rather say that now than after you have joined.

The people you would be working with are on the team page.