Part I · The job · Chapter 2
The engagement arc
Diagnose, design, demonstrate, deliver: four stages, each closed by something written or someone saying yes.
10 min read
Engagements look chaotic from the inside, but they follow a shape. Learn it, and you will know which question to ask next and which document is missing. You will also know why a project that feels fine on Tuesday is about to lose a week on Thursday.
What you'll take away
- 01The four stages of an engagement and what each one must produce.
- 02Where approvals sit, and why a missing document there costs a week.
- 03Why going backwards is part of the job, and how to do it without losing trust.
- 04A weekly rhythm that keeps a customer informed without drowning them.
Four stages, one direction
Every engagement moves from understanding a problem to a customer confirming that it is solved. The names vary by company. The order does not.
- Diagnose. Find out what is really happening, who it hurts and what it costs. You build nothing yet. You are earning the right to propose something.
- Design. Research the options, design two or three, price them and agree one with the customer. This is where most of the important engineering decisions are made, on paper.
- Demonstrate. Build the smallest version that answers the riskiest question, on the customer's data, and measure it. Show the champion first, then the sponsor.
- Deliver. The customer decides to go ahead, change course, pause or stop. If they go ahead, roll out in stages, hand over and wait for them to confirm the result.
Every stage ends in a document or a yes
Engagements outlive memories. People rotate, sponsors change jobs, and three months in nobody remembers why the second option was rejected. Close each stage with something written that the next stage can start from. It can be short. What it can't be is missing.
| Stage | Produces | Read by |
|---|---|---|
| Diagnose | Meeting notes within a day; a one-page problem brief written back to the customer | Sponsor, champion |
| Design | Options with costs; a short design doc; a decision log of what was chosen and why | Your lead, the customer's technical owner |
| Demonstrate | A working build on their data; eval results against agreed targets; a demo script | Champion first, then sponsor |
| Deliver | Go / change / stop decision; rollout plan with stop conditions; runbook and handover pack | Sponsor, operations, gatekeepers |
The problem brief deserves special mention. Writing the problem back to the customer in your own words, and asking them to correct it, catches more misunderstandings than any number of meetings. If they cannot agree on the brief, they will not agree on the solution.
The first document you send should describe their problem, not your solution.
The gates that cost you a week
Some steps cannot proceed without someone saying yes. They tend to sit in the same places on most engagements.
- Data access. Before you see real data, someone signs off on what you may see, where it may live and who else can see it. Ask for this in the first week, because it is always slower than anyone expects.
- Design approval. Your own lead and the customer's technical owner agree the design. A security review often hangs off this.
- The go / no-go. After the proof, the sponsor decides. Bring the evidence and the price, and make the options explicit: go, change, pause or stop.
- Production data and rollout. Moving from test data to live data, and from a few users to everyone, is usually a separate approval with its own reviewers.
Each gate has a document that the approver needs, and an approver who is often busy. A gate you saw coming costs an afternoon. A gate you discover costs a week, because you write the document under pressure and then wait for a meeting slot.
Looping back is normal
The four stages look like a straight line on a slide. In practice you will go back. A new regulation, a policy change, a data source that turns out to be unusable or a failed test can send you from Demonstrate back to Design, or even to Diagnose. Going back is not failure. Carrying on as if nothing changed is.
Two habits make going back cheap. First, when the build starts to differ from the approved design, update the design that week and tell the people who approved it. Surprises in a review cost far more than notes in an email. Second, keep a decision log. When you go back, you can see which decisions depended on the assumption that just broke, and you revisit only those.
"Done" deserves the same care. A deployment is not done when it reaches every user. It is done when the customer has watched it work for a while and confirmed the outcome. Even then, a policy change next quarter can reopen it. Done is something the customer declares, not something you announce.
The weekly rhythm
Customers forgive slow progress far more easily than surprises. A steady rhythm prevents most surprises.
- A weekly written update to the sponsor and champion: what happened, what it means, what happens next, and what you need from them. Keep it to five lines when you can.
- A short weekly working session with the champion or technical owner, to look at the design or the build together. Keep it short and keep it on the calendar.
- An internal check-in with your own lead, where you raise risks before the customer does.
- Same-day notes after any meeting where something was decided.
Try it
Find the missing artifacts
A regional bus operator wants to predict which buses will run late. Here is the project so far. Week one: a kickoff with the operations director. Week two: the FDE gets a CSV of last year's trips and trains a model. Week three: a dashboard demo to the director, who loves it. Week four: the IT team says the live GPS feed cannot leave their network, and the dispatchers say they cannot act on a prediction that arrives less than 20 minutes ahead.
Name the missing artifacts, say which stage each belonged to, and what each would have caught.
Write your answer down first, then reveal the worked answerWorked answer
A problem brief (Diagnose). It would have stated who acts on a prediction (dispatchers), what they can do about it, and how much warning they need. The 20-minute requirement was a dispatcher fact. They were never asked.
A data access agreement and design doc (Design). They would have shown that the model depends on a live feed, and forced the question of where it can run before anything was built. IT is a gatekeeper who was never invited.
Agreed success criteria (Demonstrate). A dashboard the director loves is not evidence. A target such as "flags 70% of delays at least 20 minutes ahead, with no more than one false alarm per route per day" would have been.
The cheapest recovery is to go back to Diagnose. Spend a day with dispatchers, write the brief, then redesign with IT in the room. The model work is not wasted, but it was answering the wrong question.