Scoping an Engagement with the Customer

Picture two engineers working on the same customer engagement. The first has a clean architecture, tidy documentation, and a design the team is proud of. But the number the customer cares about has not budged in weeks. The second has a chaotic process, late-night fixes, and a pipeline held together with workarounds. Yet the customer's number is climbing every week.

The answer surprises many engineers because it cuts against instinct. Clean code and careful design feel like signs of a healthy project. The source asks you to set those signs aside and look at one thing instead: the measurable result the customer will see. This article is about that result and why it is the thing to keep your eyes on during this phase.

The metric is not just a shared goal written in a document. It comes out of scoping, the phase in which you and the customer settle on what the engagement is meant to achieve and how that achievement will be measured. The customer brings a need, and during scoping that need is turned into a number that both sides agree to watch.

Read the diagram as a chain of custody for one number. The need is stated loosely at first. Scoping converts it into an agreed measure. Everything you build is then judged by how that measure responds, so the measure you chose at the start quietly becomes the test you will be held to later.

The source treats the agreed metric as the single most important thing to track during this phase, for a specific reason: it is the standard by which your own work is judged internally. Because of this, scoping is the moment your evaluation criteria get written. Choosing a measure carelessly means choosing a poor test for yourself.

This is why the metric is useful beyond the document it lives in. It anchors your attention to what the customer will eventually experience, rather than to what your team finds satisfying to build along the way.

The source describes two states an engagement can be in, and both are read directly from the metric rather than from the work around it. In the first state, the metric is moving. The source is firm that the engagement is a success in this case, even if the path there was disorderly. In the second state, the metric is not moving, and the engagement is in trouble regardless of how elegant the architecture is. The verdict depends on the direction of the agreed number, not on the quality of the engineering.

Notice what the reasoning did not do. It did not ask whether the designs were elegant or whether the team liked the approach. It only asked what the agreed number is doing. That habit, reading the metric before reading the work, is the one the source is trying to build.

Drift away from the agreed metric rarely happens in one dramatic step. Each individual task can look reasonable, and the team can stay busy the whole time. The diagram below shows the check that brings attention back to the outcome.

The source moves on to a short list of patterns that separate engineers who land this phase from those who struggle. The passage introducing that list does not spell the patterns out, so this article does not guess at them. What the excerpt does make clear is why such patterns matter: being graded on the customer's real outcome creates a forcing function. The source describes this pressure as the fastest path to the kind of judgment that distinguishes a working forward-deployed engineer from a competent engineer.