Forward Deployed Engineer - Mainloop
Forward Deployed Engineer
=============================
Go into a business that has never been automated, work out how it actually runs, and have something working in front of them in two weeks. Then hand it over properly, and go and do it somewhere else.
Mainloop is a new engineering team inside an established international group. We are in Barcelona, we are being built from scratch this year, and we have the backing, the customers and the product portfolio of a company that has been around for decades. You get the interesting part of a new team without the part where you check whether payroll clears.
Two more things about where this comes from and where it goes. The group has been running a tech lab in Casablanca for more than eight years — Barcelona is its second, built to sit closer to the teams we build for, and AI\-native from the first commit, because it starts from a blank page. And the plan does not stop at internal work: within about a year and a half we intend to externalise — external clients, our products sold on the market, products developed for it. The first eighteen months are deliberately spent building as much as possible for the group while the machine gets set up. You would arrive at the start of that curve, not after it.
What we build is the software that automates professional\-services work — across roughly fifteen countries, for businesses drowning in administration. That is the material: the admin. The forms, the approvals, the reconciliations, the eleven\-day handoffs, the spreadsheet somebody rebuilds every month. We work in two halves. One half — this half — goes into a business, finds out what really happens there, and builds something fast enough to prove whether it is worth having. The other half takes what we prove and turns it into something the company depends on.
Most automation teams only have the first half, which is why they end up with a drawer full of demos. Most of the rest only have the second half, which is why they build what somebody remembered to ask for. We are hiring the people for the first half.
We are not only looking for a developer. We are looking for someone with a consultant's instincts who can build — someone who is more interested in *why the invoice takes eleven days* than in which framework we use, and who can then go and build the thing that fixes it.
What the job actually is
A project arrives. It is usually a sentence — *"our people spend two days a month reconciling this by hand."* From there it is yours.
- You go there. In person, to whichever country it is, and you sit with the people who actually do the work. Not the manager's description of the work — the work.
- You understand the process properly. How it really runs, who touches it, where it hurts, and what it costs today. It is almost always administrative work — that is where the time goes in a professional\-services business, and it is where we win. How long it takes is set by the process, not by a calendar. Something simple is days. Something genuinely complex is weeks before anything gets built, and saying so is part of the job — we would much rather hear "this is more tangled than it looked" in week one than in week six.
- You check what we already have — before you build anything. This is a real step, not a courtesy. We own a portfolio, and a serious part of doing this job well is knowing it well enough that when a business describes their problem you already know we have most of it. Sometimes the answer is *we have this, it just needs configuring.* More often it is *most of this exists over there* — and you take that code and cut a PoC out of exactly the part you need. You will not be doing that from memory alone: you get code intelligence across the whole estate, wired into an agent you can hand a spec to and ask *what of ours already does this?*
- You write the functional architecture. How the thing works — the flow, the actors, the rules, the data that moves and the decisions in the middle. Functional first: this is a business\-process job, not a systems\-design one. You will make technical calls and you need to be able to, but the deep technical architecture is not what you are for, and the parts that need one go to Edouard and the Tech Lab. This document is what the agents build from, which makes writing it precisely the highest\-leverage hour of your week.
- You build it. Agentic build, steered by you: idea to something showable in one to two weeks once you understand the process.
- You put it in front of people, repeatedly. A short series of increasingly real prototypes, each shown to the stakeholders, each one better because of what came back. You own that loop and the first testing.
- You say whether it is worth it. You have been sizing the benefit since day one, so when the answer is *no*, you can say it with numbers.
- You get it to MVP, and you get people actually using it. Onboarding the users and following up afterwards is yours, not somebody else's afterthought.
- You write the handover pack while you build, hand the whole thing to a Product Owner and an engineer, and move to the next one.
The line you stop at — and why it is in your favour
You take a project to MVP. Not to production, and not for years. Once it is proven and near\-ready, our Tech Lab takes over: hardening, scale, security, the long run. You are out — properly out, not "available for questions".
That line is deliberate and it is the best thing about this job. You never accumulate a tail. You are not the person still being called in fourteen months about a thing you built in an afternoon, you are not maintaining six half\-owned prototypes while trying to start a seventh, and you do not slowly become the support desk for your own back catalogue. That is how this role burns people out everywhere else it exists, and it is the specific failure we built a second team to prevent.
Occasionally you will stay a little longer, and it will be because it is faster. If the follow\-up after launch is going well and the Product Owner is not free yet, you may keep running it for a while rather than let the thing lose momentum — a choice we make deliberately, in the open, and always with an engineer already on the other side. What we do not do is leave you quietly holding it.
What you get instead is the part most engineers say they want and rarely get: a new problem, a new business and a blank page every few weeks, with someone competent to hand the finished thing to.
An honest "no" is a real result here
Some of what you look at will not be worth automating. When that is true, you stop, you write up why, and that counts as a delivered outcome — because the next person does not repeat the work, and the business gets an answer instead of a project.
This only works if somebody has been quantifying the benefit from the first conversation, and that somebody is you. It is also why we mean it: you will have the standing to kill your own project, which is not a sentence most companies can write honestly.
You will get seriously good at building with AI agents
This is the part we would underline. We are an AI\-native team, genuinely — not a team that added a Copilot licence. Everyone gets their own Claude Max subscription and a desktop orchestrator that runs several coding agents in parallel. You will learn to drive that properly: how to get speed and quality at the same time, where it fails, and how to look at what came out and tell whether it is actually right.
Which changes what the work feels like. Very little of your week is typing implementation. Most of it is the things that decide whether software is any good — what should exist, what shape it should be, what the business will actually adopt — and then dropping into the detail exactly where the detail matters. You do not need to be able to hand\-write production code; you need to be able to *specify* precisely, *steer* well and *judge* what comes back. We will train you on our architecture, our patterns and our pipeline. That part is on us.
"If the agents build it, what am I for?"
A fair question to ask of an ad like this one, so here is the honest answer: the agents are the fastest part of the team and the least trustworthy one, and we do not expect that to change. Everything that decides whether the project was worth doing runs through a person.
What stays yours, permanently:
- Finding out what actually happens. Nobody has written it down. The person doing the job will describe the version in the procedure, not the one with the three workarounds in it — and the workarounds are the project. Noticing that gap takes a human in a room.
- Deciding what not to build. Half of doing this well is reuse, scope and refusal. An agent will cheerfully build the thing nobody needed.
- Sizing the benefit, and being willing to say no. Numbers, and the nerve to put them in front of the person who asked for the project.
- Turning it into a specification precise enough to be built. An agent will build exactly what you specified, beautifully, even when what you specified was the wrong shape. Getting from *"they need this"* to a spec that produces the right thing is the hardest hour of your week and the one nothing automates.
- Everything human. Being trusted by people who did not ask for you to turn up. Telling a stakeholder their favourite idea is not worth it. Handing over so well that the people inheriting it never need you.
Este anuncio proviene de Indeed. Ver anuncio original ↗