Day one of my first real engagement, I spent forty minutes in the wrong building. The client had two facilities across the street from each other, my badge worked at neither, and by the time security sorted it out I'd missed the kickoff meeting I was supposed to be impressing people at. It was, in retrospect, the perfect omen for the week.

Because the week got worse, in ways that would become my personal taxonomy of FDE first engagement mistakes. I shadowed the person leadership assigned me, built the feature the loudest executive asked for, and followed the official process documentation like it was scripture. By Friday I had a beautiful demo of the wrong thing. The dispatchers it was supposedly for looked at it the way you'd look at a fruitcake from a distant relative: politely, and never again.

Most of them are discovery failures wearing an engineering costume. You shadow the person leadership trusts instead of the person who does the work, you build for the loudest voice in the room, and you trust the process map over the sticky notes. The good news: these mistakes are recoverable, usually within two or three weeks, if you're willing to scrap your work in public.

Mistake one: shadowing the wrong person

Every client assigns you a guide, and the guide is always whoever leadership trusts most. At this client, a mid-size freight company, my guide was the operations director: smart, helpful, and four years removed from actually dispatching anything. He described the job as it existed in 2019, with confidence, for two full days.

Reality as it existed on Tuesday lived with the night-shift dispatchers, who had quietly rebuilt half the workflow around a shared spreadsheet and a group chat because the official system couldn't handle split loads. I met them on day nine, by accident, when I stayed late. Everything I thought I knew about the engagement had to be re-learned in a fluorescent-lit break room at 11 p.m.

Mistake two: building for the loudest voice

The VP of operations wanted an executive dashboard. He asked for it in the kickoff, in the follow-up email, and in the parking lot. It had charts. It had KPIs. It had his name in the corner of the mockup he sketched for me, which should have been a clue.

Meanwhile, the dispatchers wanted the split-load screen to stop requiring fourteen clicks. Nobody asked for this loudly, because people doing the actual work rarely do; they just suffer efficiently. I built the dashboard. Week two usage stats: six logins total, five of them executives, one of them me checking whether anyone had logged in. The parallel with a skeptical client who tested our AI against reality is that users vote with their keyboards, and their ballots are always honest.

Mistake three: trusting the process map

I was handed a laminated process binder, and I believed it. The binder said orders flowed from intake to assignment to dispatch. The binders always say things like that. Reality said orders flowed from intake to Karen, who knew which drivers would actually take which loads, and the system got updated afterward to match her decisions.

Karen wasn't in the binder. Karen was the binder. Every company has a Karen, sometimes several, and the gap between the documented process and the Karen-mediated one is where your software will live or die. The sticky notes on her monitor contained more accurate system documentation than forty pages of official procedure.

The week-three recovery

Week three started with an uncomfortable admission: I told the client I'd built the wrong thing and wanted to scrap most of it. To their credit, they'd suspected as much. I spent three nights sitting with the night shift, watching the spreadsheet-and-group-chat workflow in its natural habitat, and then built the ugliest tool of my career: a split-load screen with four buttons, no charts, and one very large font.

The admission conversation is the part nobody warns you about, and it's the part that saved the engagement. I brought the usage stats, said "I built the wrong thing" out loud, and braced for the ejection seat. The operations director just nodded and said they'd wondered why the demo didn't mention split loads. Clients can smell a misfit demo; what they can't smell is whether you'll own it, and owning it turned out to be the fastest trust I built all year.

It took six days. Six dispatchers used it the first night, all of them voluntarily, which felt better than any launch applause. By week six the count was forty users across three shifts, the shared spreadsheet had been ceremonially deleted, and the VP got his dashboard too, generated from data that was finally accurate because people were actually using the system. The full arc looked a lot like a later ninety-day logistics engagement: slow trust, then compounding adoption. There were no heroics, no 3 a.m. deploy story, just stubborn iteration in the right building.

The humbling part was realizing the information had been available the whole time. The night shift would have told me everything on day two if I'd been standing in their break room instead of a conference room. Nobody hid the spreadsheet; I just never asked to see how anyone actually spent their evening. Wrong building, wrong person, wrong priorities: all three mistakes were the same mistake, which was optimizing for looking competent instead of being useful.

A first-week checklist that works

Every engagement since, I've run the same week-one playbook, and it has never once produced a fruitcake demo:

  1. Shadow three roles, not one guide. Insist on watching the people who touch the work daily, including at least one off-hours shift.
  2. Find the fixer. Ask who people call when the system breaks at midnight. That person is your real documentation.
  3. Collect the sticky notes. Photograph every workaround, cheat sheet, and taped-on monitor note you can find.
  4. Log the loudest request, build the quiet one. Thank the VP, then ship the thing that removes clicks for the people doing the work.
  5. Ship something tiny by Friday. One screen, one workflow, real data. Momentum is the only currency that spends in week two.

My badge works at both buildings now, which took three weeks, roughly the same timeline as rebuilding the client's trust. Both were worth it. The fruitcake demo never happened again, and the night shift still texts me when the split-load screen hiccups, which is the real definition of a successful first engagement. Karen, for the record, got a framed screenshot of the new system at the client's holiday party, and she cried less than I did.