What a forward-deployed engineer does in week one
Day by day, what a forward-deployed engineer does in the first week inside your business: access, shadowing, real data, a one-page map and a ranked list.
Devvion · Published
"We've signed. Someone starts on Monday. What will they actually do all week, what do they need from us, and when will we see something built?"
Fair questions. A forward-deployed engineer works inside your business, not from a ticket queue. That changes what the first week looks like. It isn't a kickoff deck and a list of requirements. It's five days spent close to the work, ending with a one-page map and an agreed first thing to build.
Here's the week, day by day, as we run it.
Before Monday
Three things are agreed in advance, so day one isn't lost to logistics.
- One owner on your side. The person who will own the process when we leave. They don't need to be technical. They need authority to say yes and time to say it.
- Read-only access first. To the ERP, CRM or shared drives the process touches. Write access comes later, for named systems, when there's something to build.
- A calendar. Who we'll sit with on which day, and a slot in the weekly operations meeting.
Day 1: meet the work, not just the managers
The morning goes to the owner and the operations meeting. The afternoon goes to the people who do the process every day. The engineer asks what they do on a normal Tuesday, what they wait for, and what they redo. Most of the useful answers come from questions like "show me" rather than "tell me".
By the end of day one the engineer has a list of names, systems and the first suspicions about where time goes.
Day 2: shadow the process end to end
The engineer sits with the people doing the process and follows real cases from start to finish, on screen. Every exception goes on a list: the customer who orders by photo, the approval given in a chat thread, the spreadsheet kept beside the ERP because nobody trusts a report.
This is the day the process stops being the one in the procedure document and becomes the one that actually runs.
Day 3: look at a month of real data
Process interviews tell you what people think happens. Data tells you what does. The engineer exports a month of real records from the systems involved and checks them against what they saw on day two: volumes by type, how long each step waits, how often a record is changed after it's created, which fields are empty.
The gaps between what people said and what the data shows are usually where the first automation belongs.
Day 4: a one-page map
The engineer draws the process as it runs today on one page: steps, systems, handoffs, waits and rework. Each step is marked as one of three kinds: it only moves data, it follows a rule, or it needs judgement. Steps that only move data are candidates to remove. Rule steps are candidates to automate. Judgement steps stay with a person, or get AI help later with a person able to override.
Day 5: rank, agree, measure
The candidates are ranked by hours recovered against effort and risk. The owner and the engineer agree the first thing to build, write down how it will be measured, and take the baseline: hours a week, today, counted by the people doing the work. The week closes with a short playback to management: what we saw, what we'll build first, and what we won't touch.
What it costs to skip week one
Teams that skip this week usually start building from a requirements document, and find the real exceptions in month two.
The fixed flow: how the ranked list is built
Project intake and prioritisation
- New project request
- Summarise the request
- Business case complete?
- Score the request
- Check team capacity
- Portfolio board decides
- Approved this quarter?
- Project set up
- Starts with an owner
- Request to decision: 6 weeks → 2 weeks (Example)
The list from day five follows the same logic as any good project intake: every request is captured in one place, scored against the same criteria, and ranked before anyone starts building. It keeps the first automation honest. The loudest request doesn't win; the one with the clearest return does.
What the engineer doesn't do in week one
- Write production code against guesses. A quick prototype on real data, yes. A build, no.
- Promise a number. The baseline is measured first. Savings are measured against it later.
- Ask for admin access to everything. Read-only first, write access for named systems later.
- Bring in AI by default. Rules come first. AI goes on the judgement steps that remain.
What to do before your first week, with or without us
- Name the owner and clear two hours a day of their time for the first week.
- Pick the process and the three or four people who do it most.
- Set up read-only access to the systems it touches.
- Export a month of data if you can, so day three starts early.
- Tell the team why. Say clearly that the aim is to remove work, not people.
When to call us
Call us when a process crosses several systems, when an earlier project stalled between the plan and the build, or when nobody inside has time to own both.
Week one sits inside Devvion's two-week assessment, the first of six stages: assess, map, mature, automate, optimise, run. If the process needs redesigning before anything is built, business consulting takes the map and matures it first. Forward-deployed engineering then automates it in your stack. The people you meet stay on your work from the first day to the last. See the use cases we work on.
FAQ
Is Devvion's forward-deployed engineer on site in week one?
Devvion's engineer is on site for the start of the engagement and the key weeks, and remote in between. Week one is almost always on site, because shadowing the process and meeting the people doing it works best in the same room.
What access does the engineer need in the first week?
Devvion asks for read-only access to the systems the process touches, such as the ERP, CRM and shared drives. Write access comes later, only for named systems, once there's something agreed to build.
Will anything be built in week one?
Devvion rarely builds in week one. The engineer may test a quick prototype on real data to check an idea, but the first real build starts after the ranked list and the baseline are agreed with your owner.
Who on our side needs to be available?
Devvion needs one owner with authority to decide, for about two hours a day, plus time with the three or four people who run the process most. Managers join the operations meeting and the playback on day five.
What do we have at the end of week one?
Devvion leaves you a one-page map of the process as it runs, a list of exceptions, a month of real data checked, a ranked list of candidates, the first build agreed and a measured baseline to compare against later.