An ordinary week on a deployment
This is a composite week from the middle of a deployment, assembled from the shape these projects reliably take rather than from one real account. It is deliberately not a highlight reel. In a middle week the plan slips, one integration breaks for a reason nobody documented, a meeting that looked like a waste turns out to contain the week’s most useful sentence, and roughly a third of the time goes to things that are not engineering at all. The pattern worth noticing is not the tasks. It is that the progress comes sideways: the thing that unblocks the project is almost never the thing that was scheduled to unblock it, and the engineers who do well are the ones who recognise it when it shows up in the wrong meeting.
Monday: the plan meets the queue
The week starts with the status call. The plan says the second data source is connected by Friday. The access request for it was submitted eleven days ago and is with a security team that has not responded.
An hour goes to finding out where the request actually is, which is not a technical activity and not something the account manager can do for you, because the answer requires knowing which of three queues it landed in. It turns out to be waiting on a data classification question that nobody routed to anyone.
The rest of the morning is spent doing the thing that distinguishes a week that recovers from one that does not: finding what can still move. The connector cannot be built, but the transformation logic can be written against the sample export from three weeks ago, so that when access lands the work is an afternoon rather than a fortnight. This is unglamorous and it is the difference between a six-week project and a ten-week one.
Tuesday: building, and the first real block
A long uninterrupted morning, which is the most valuable resource in this job and has to be defended deliberately. The retrieval layer goes from working on the demo set to working on the real documents, which immediately exposes that a fifth of them are scans rather than files.
Nobody mentioned the scans. Nobody was hiding them; the person who described the document set does not think of the scans as part of it, because their team has been handling those separately since before the system that stores the rest existed. This is the ordinary texture of stage two, discovered late.
The afternoon goes to a decision that is more consequential than it looks: whether to handle the scans now or to scope them out. Handling them adds an extraction step and probably two weeks. Scoping them out means the system is wrong for a fifth of cases in a way users will notice immediately. The answer here is to scope them out and say so loudly, in writing, to the sponsor, because a known gap that everyone has agreed to is survivable and a silent one is not.
Wednesday: the meeting that was going to be a waste
A standing governance meeting with eleven people, most of whom have no involvement in this project. It was declined twice before and is being attended this week only because the sponsor asked.
Forty minutes in, someone from a team you had never heard of mentions, in passing, that their group already built a normalised view of the customer records two years ago and nobody uses it. This is the sentence that changes the project. Three weeks of planned reconciliation work disappears, and it disappeared because you were in a room you did not want to be in.
The rest of the day goes to finding that person, confirming the view is real and maintained, and discovering that it is maintained by one engineer with no mandate to support anyone. Most of the afternoon is spent making it worth their while to help, which is a conversation rather than a ticket, and which is the actual skill being exercised.
Thursday: adoption, before the system is finished
A session with four people from the team whose work this changes. It is deliberately early: the system is incomplete and showing it now, half-built, produces better information than a polished demo later would.
Two of them are enthusiastic, one is polite, one says almost nothing. The one who says almost nothing is the one to follow up with, and the follow-up happens one to one rather than in the group, because the objection they are not raising is the one that will decide adoption.
It emerges, that afternoon, that the output does not show a number they are personally accountable for. It is not a hard change and it would never have surfaced from a requirements document. It surfaced because someone watched the room rather than the screen.
Friday: writing things down, and the part that gets skipped
The morning is the week’s note: what was learned about the data, the decision to scope out the scans and who agreed to it, the discovery of the normalised view, and the change coming from Thursday. This is not a status report. It is the artefact that a version of you in four months will need, and that nobody can reconstruct from memory.
The afternoon is the stage-five work that is easiest to postpone indefinitely: two notes to the product team. One says that document extraction should be in the product rather than rebuilt on every deployment, with this week as the evidence. The other says that the current onboarding assumes access can be granted in days, and describes what actually happens.
Neither note will produce anything this quarter. Written consistently, over a year, they are the reason a product company employs this role rather than hiring a contractor, and they are also the reason some deployment engineers become unusually influential inside their own company while others remain field staff.
What the week says about the job
Roughly two days of the five were engineering in the sense a product engineer would recognise. One was spent on access, process and people. One produced its value in a meeting nobody would have scheduled for that purpose. One was writing.
Someone reading that split and feeling that three of the five days were a distraction from the real work should take the comparison with product engineering seriously before choosing this role. Someone reading it and recognising that the three days are where the deployment was actually won is describing why the job exists.
