Forward-deployed teams

A contractor takes a ticket. A forward-deployed engineer takes the problem. They sit with the people who have it, work out what is actually wrong, and build the fix. You are buying judgment about what to build, not hours against a specification someone else already wrote.

Days, not months. Our engineers average fifteen years of experience and have worked in unfamiliar enterprise codebases many times. The two-to-three week discovery exists so that ramp happens against a scoped piece of real work.

Yes. Continuity is the point. The team assigned to your project stays on your project and learns your systems, your data and your business context. We do not rotate people between accounts to balance utilisation.

Either, and the choice is yours. Our people can embed in your team, joining your standups, using your tools and reviewing your pull requests. Or we take the whole programme and run it as a full team from our own offices, delivering against outcomes while your team stays on its current roadmap. That second model is how we take on the larger builds, and plenty of engagements start as one and become the other.

Troy Busot, our CTO, puts it as drawing the permissions boundary in the first conversation, because giving an agent reach into production data before that line exists is an incident with a date on it. Concretely it is three things, in this order: a business problem stated precisely enough to argue with, that problem turned into a scoring rubric and an environment that can run it, and then the agent or workflow that scores well against it. Troy Busot, our CTO, is usually in the first of those conversations. The third used to be where the hundreds of hours went, and it is the part shrinking fastest, because good tooling now writes a great deal of it. The first two are not shrinking at all, because they require sitting with the people who own the problem and knowing what a right answer looks like to them. That is the work, and it is why we put senior people in the room.

Because the constraint moved rather than disappeared. When implementation was expensive, the scarce skill was building the thing. When implementation gets cheap, the scarce skill is deciding what should be built and being able to tell whether the result is right. A wrong goal now gets implemented faster than it used to. Our engagements have gone from ten people to three on exactly this basis: the three are the ones who can define the problem, write the rubric, and judge the output.

Both. Alongside software engineers we field product engineers, who decide what is worth building and cut the scope that is not, and design engineers, who make the thing usable. All three work as one team, and AI has made that team considerably smaller and faster than the equivalent staffing three years ago. Andrew Ripley runs product and Sam Salima runs design, both in house. Sam puts the design case as arriving while the engineering decisions are still open, since coming in after them leaves you decorating whatever was already decided badly.

Most start with a two-to-three week discovery, which gives you a scope, an architecture and a realistic cost before you commit to anything larger. From there we put the right team on it to get things done, with daily demos so you see working software every day. That might be a single embedded engineer or a pod that owns the programme outright.