Getting Technical Work Adopted

Technical teams are frequently surprised that a system which works well is ignored. The reasons are consistent and almost none of them are about quality.

It did not fit the work. The system is technically correct and requires someone to open a different application, at a moment when they are doing something else. The friction is small and the usage is zero, because the alternative is what they already do.

It solved a problem they did not have. Somebody senior specified it, the people doing the job were not asked, and the thing that actually slows them down is elsewhere.

It threatens someone. If the output implies that a team's judgement was wrong, or that headcount is unnecessary, resistance is rational and it will be expressed as concerns about the methodology.

Nobody knows what to do when it is wrong. Without a defined path for handling a bad output, people cannot use it safely, so they do not use it.

Accountability is unclear. If a person is answerable for the decision and the system's contribution is undefined, the safe move is to ignore it and decide as before.

And trust was never built. The system arrived, asserted, and was expected to be believed.

What these have in common is that every one is addressable, and every one is addressable early rather than late. Which is the argument of this lesson: adoption is not a phase after building. It is determined by conversations that happen before and during, and a team that treats it as a launch activity has already lost most of the available leverage.

The relationship between technical teams and the people who currently do the work determines project outcomes more than any technical decision, and it is frequently handled badly in a specific way.

The pattern that fails. The technical team treats the domain expert as a source of requirements to be extracted, and afterwards as a user to be trained. The expert experiences a system built to replace their judgement, arriving with an implication that their judgement was inadequate.

Why that is both unkind and inefficient. The expert holds information that exists nowhere else: which data is unreliable and why, what the process actually is rather than what it is documented as, which cases are unusual, what changed two years ago that makes older records incomparable, and what the numbers do not capture. That information determines whether the system works, and no amount of technical skill substitutes for it.

And they are the ones who will decide whether it gets used, whatever the deployment plan says.

What works better, concretely.

Ask them to look at errors, as the previous lesson described. This is genuine collaboration rather than consultation theatre, and their reaction to specific mistakes is the highest-quality feedback available.

Ask what they look at when they make the judgement. Frequently it is something not in the data at all, which is the finding that saves the project.

Be explicit about the intended relationship. A system that surfaces candidates for their judgement is different from one that replaces it, and they will assume the second unless told otherwise.

And give credit publicly. Domain expertise is invisible in the finished system, and the person who supplied it watched their knowledge become someone else's product.

The practical test. If the domain experts are advocating for the system, adoption is solved. If they are tolerating it, it will quietly fail.

Technical documents get written in the order the work happened and read in a different order, if at all. The structure that survives contact with a busy reader.

The first paragraph contains the recommendation and what it costs. Assume this is all that gets read, because for most recipients it is. If your first paragraph is background, you have written a document for nobody.

Then what it means for the business, in two or three sentences: what changes, for whom, and what it is worth.

Then what you need, if anything. Decisions, resources, access. Put this early, because it is frequently the only reason the document exists and it gets lost at the end.

Then the reasoning, at the mechanism level from lesson one, for the readers who want to evaluate rather than accept.

Then risks and what would change your recommendation, which is the section that builds credibility rather than undermining it.

And everything else in an appendix: method, data, validation, alternatives considered, technical detail.

The test to apply before sending. Delete everything except the first paragraph. Does the reader have what they need to act? If not, the paragraph is wrong, and no amount of quality further down compensates.

The same inversion as the data storytelling cursus, arrived at for the same reason: the order in which work is done is not the order in which it should be delivered, and technical writing defaults to the first.

A difficulty specific to this moment: technical teams now work with stakeholders whose expectations were formed by marketing rather than by anything the team said.

What arrives. Executives who have read that AI transforms organisations and want to know why yours has not. Requests to build something a vendor demonstrated, without the vendor's conditions. Assumptions that a system will improve on its own, that it will handle any case, or that it can explain itself. And timelines derived from how quickly a demonstration was produced.

Why this is genuinely hard. The gap is not the stakeholder's fault and it is not yours. Correcting it can read as making excuses, as being negative, or as your team lacking capability compared to whoever produced the demonstration.

What works.

Separate the demonstration from the deployment explicitly. A demonstration shows a capability on selected inputs with a person steering. A deployment runs on your data, on the cases nobody chose, with nobody watching. Naming that distinction is usually enough, because it is obvious once said.

Use their own edge cases. Ask what should happen for a specific difficult case they know about. This converts an abstract argument about capability into a concrete conversation, and the stakeholder frequently reaches the limitation themselves, which lands far better than being told.

Be positive about what is genuinely possible, specifically and quickly. A team that only says what will not work stops being consulted, and the requests move to someone who says yes.

And distinguish not yet from not with this data from not ever, because collapsing them into no is inaccurate and it removes the conversation about what would make it possible.

The underlying stance that holds up. Be the person who is right about what these systems do, consistently, in both directions. Teams that are reliably accurate about both capability and limitation become the ones asked before commitments are made, which is where the real influence is.

Adoption is largely determined by decisions that look like engineering choices and are actually communication choices.

Where the output appears. A score in a separate dashboard is a system people must remember to consult. The same score inside the tool where the work already happens is a system they cannot avoid. This single decision explains more adoption variance than model quality does.

What is shown alongside the output. A bare number invites the question of whether to believe it. The same number with the two or three factors behind it and a link to the underlying case lets the person evaluate it, which is what they need in order to act.

What happens when the person disagrees. If there is no route to override, they will work around the system, and you will lose both the override and the information that they disagreed. A visible disagreement path is not a weakness; it is the mechanism that surfaces the cases where the system is wrong.

Whether the disagreement is captured. Overrides are the most valuable evaluation data any deployed system produces, and most deployments discard them.

How uncertainty is expressed. A system that presents every output with equal confidence teaches people to distrust all of it after a few bad ones. One that distinguishes confident from marginal cases lets them allocate attention, and it is honest.

And what the accountability is. Whether the person is expected to follow the output, use it as input, or justify departing from it. If this is unstated, people default to whatever protects them, which is usually ignoring it.

The general point for technical teams. These are not user experience details to be handled later. They determine whether the work is used, and they belong in the design conversation with the people who will live with the system.

Technical projects have long periods with nothing to show, and how that period is communicated determines whether the project survives it.

The pattern that damages teams. Silence during the work, because there is nothing finished, followed by a presentation of the result. From outside, that looks like a team that disappeared for four months. And if the result is disappointing, which is normal in exploratory work, it arrives as a surprise with no context.

What to report instead, during the middle.

What you have learned, which is not the same as what you have built. We found that the data does not record outcomes for a third of cases is real progress and it is more valuable to stakeholders than an incremental model improvement.

What you have ruled out. Negative results are progress and framing them as such is accurate rather than defensive.

What has changed about your estimate, early. A timeline that slips is manageable when reported at the point it becomes likely and damaging when reported at the deadline.

And what you need, continuously rather than at review points.

The framing that helps most with exploratory work is to be explicit about it upfront. This kind of work has a real chance of concluding that it cannot be done, and that is a legitimate and valuable outcome that saves the money that would have been spent building it. Stakeholders accept that when it is stated at the start and reject it when it appears at the end.

And one specific practice worth adopting. When a project is not going to work, say so as early as you know. Teams delay this hoping something will change, and the cost of the delay is entirely wasted. A team known for stopping its own projects early is trusted with more of them.

The highest form of influence for a technical team is being consulted before a decision is made rather than after, and that is earned through a small number of behaviours over time.

What builds it.

Being right about limitations, in both directions. A team that correctly says this will not work and correctly says this will work becomes a reliable instrument. A team that is only ever cautious is treated as an obstacle and routed around.

Delivering something small early. A modest thing that works, in production, generates far more trust than a large thing described. It also makes the team's claims checkable, which is what credibility actually consists of.

Reporting your own problems first. Degradation, errors, a project that will not work. Teams that surface their own bad news are believed about their good news.

Speaking in the business's terms, consistently. This is the whole of lesson one, and its cumulative effect is that people stop finding conversations with your team effortful.

Giving credit to domain experts, publicly.

And being useful about things outside your project. Answering a question, explaining something a vendor claimed, sanity-checking a number for another team. This is how a team becomes the place people come to before deciding, which is the position you want.

What destroys it. Overclaiming, once. Being wrong confidently about a limitation. Presenting a result that later turns out to have a basic error. Sounding like you are protecting the team rather than answering the question.

The asymmetry is worth knowing. Credibility accumulates slowly through many small accurate statements and drops sharply on one confident wrong one, which is an argument for calibrating carefully rather than for being vague.

Three lessons, as a set of habits.

You cannot assess your own explanation from inside it, which the tapping experiment established. So the fixes are structural: ask what prompted the question before answering, lead at the decision level and offer depth rather than delivering it, watch the words that mean something else, and check by asking people to state it back.

Simplify against the misrepresentation test rather than the completeness test. The alternative to a simplified explanation is not a complete one; it is one that was not understood.

Reconcile the mental models before deployment. Statistical systems are wrong by design, and a stakeholder who meets that idea through a live error will lose confidence out of proportion to the fact.

Explain the two kinds of error and their trade-off, because it converts an argument about quality into a decision that belongs to them. Give numbers as consequences over a real period, which requires business facts you have to ask for.

Show thirty actual errors before deployment, with the people who will live with the system. This one practice does more than everything else in the cursus.

Treat domain experts as the source of what determines whether the system works, and as the people who decide whether it is used.

Write documents whose first paragraph is the recommendation, and assume nothing else is read.

Report your own bad news first, early, including projects that will not work.

And the idea running through all of it. Almost every practice here moves a conversation earlier. Same content, different timing, and the timing is what determines whether it is received as information or as an excuse. A technical team that is consistently early is trusted; one that is consistently accurate but late is managed.