Customer Satisfaction 2 — Crossing the Gap

Case Three: Gold Plating vs. the Essential Need — Are You Applying Effort in the Right Place?

In a deeper discussion, one participant raised a question every engineering team should sit with: when delivering a technical solution downstream, we focus on architectural sophistication, elegant code and complete documentation — the "gold plating" — and quietly skip the customer's most essential need. The essential need is the real reason the downstream team depends on you: whether your interface is stable, whether your middleware is reliable, whether your component drops into their stack without friction.

Take a realistic engineering scenario. An infrastructure team launches a brand-new microservice governance platform for the business development teams. The UI is beautiful, the monitoring dashboards are rich, distributed tracing is complete — technically impeccable. Then the business teams try to adopt it and discover that the canary release strategy is incompatible with their existing CI/CD pipeline, so every release means manually shifting traffic; and that the error-code scheme does not match their existing alerting rules, so alerts either flood or miss. Until these are solved, a beautiful platform is a burden — not a pair of wings, but one more system to maintain.

This is where needs tiers matter. Basic needs — a stable interface, reliable performance, compatibility with the existing stack — are the reason downstream depends on you at all. Performance needs — clear documentation, fast response, low integration cost — directly move satisfaction up or down. Delight needs — advanced architecture, elegant code, performance beyond expectation — create surprise, but only once the basic needs are met. The most common mistake in engineering teams is over-investing in performance and delight needs while compatibility and stability remain unverified: substituting architectural sophistication for business usability.

One participant put it precisely: you have to "look at both sides of the coin". The same coin has one face showing what the upstream team delivered, and another showing what the downstream team can actually use. The pictures are completely different, yet upstream often assumes they are the same face.

From "I Believe" to "You Confirm": The Logic of Perspective Calibration

When participants compared their thinking before and after swapping roles, a sharp insight emerged. Every engineer is simultaneously a supplier and a customer: in the morning you ship an SDK to someone, in the afternoon someone ships a component to you. At the moment of receiving, you know exactly what you care about: can I integrate it directly, did it break anything, does the documentation actually run. But at the moment of delivering, those feelings seem to evaporate, replaced by an instinctive approval of your own output — "my code is fine, the docs are there, just use it."

This "role amnesia" is the most invisible mechanism in internal customer relationships. It is not deliberate double standards; it is the brain activating different frames of reference when the role changes. As a supplier, the brain retrieves memories of your own development process — late nights fixing bugs, repeated load tests, carefully written docs — and these form the evidence chain for "I have done enough". As a customer, the brain retrieves your experience of using the thing — failed integration, docs that don't match the version, performance that doesn't fit the real scenario — and these form the evidence chain for "you never understood what I need". Two evidence chains that never meet, both living in the same person.

So the core of perspective calibration is not the vague slogan "learn to think from the other side" — in fact, everyone already knows instinctively how the other side should behave when they are the receiver. Real calibration happens at the moment of role switching: before you press the "deliver" button, force yourself into the receiver's identity and ask — if I had just received this, what would my first reaction be? That single mental step maps the real feelings you accumulate as a receiver directly onto your behaviour as a supplier.

Crossing the Gap: A Four-Step Framework

Step 1: Downgrade your understanding from "conclusion" to "assumption". When you think "downstream needs this interface", add a mental tag: "I assume downstream needs this interface, but I have not verified it." This tiny operation changes your delivery behaviour fundamentally. You stop dropping a finished API on the table and waiting for feedback; you take the draft to downstream for a short conversation first. From "we built this for you" to "let's first confirm this is what you need" — three minutes of confirmation can save three days of rework.

Step 2: Align at the key checkpoints, not at the finish line. Do not compress satisfaction verification into final delivery. At requirements: "I understand you need A, B, C — is that accurate?" At design: "based on what we discussed, this is how I plan to shape the interface — anything missing?" At each incremental delivery: "this is the current version; where does it diverge from what you expected?" Every confirmation is a chance to narrow the gap; verification only at the end has no room left to adjust.

Step 3: Separate the tiers — secure the basics before chasing excellence. Split your delivery list into two columns: "must be true" and "could be better". Must be true: the interface is compatible with existing protocols, performance meets the bar in the integration scenario, the sample code in the docs actually runs. Could be better: elegant architecture patterns, rich monitoring, load-test numbers beyond expectation. Until every item in "must be true" has been verified by downstream, do not spend extra effort on "could be better". Not because excellence doesn't matter, but because before the foundation is solid, any interior decoration wastes trust on both sides.

Step 4: Replace "confirming" with "falsifying". The brain naturally looks for evidence that supports what it already believes — confirmation bias. After you build a feature, write a middleware or ship a component, you unconsciously pay attention to the one sentence downstream said in praise and ignore the moment they frowned. The countermeasure is deliberate: actively ask downstream "what is the single thing you least like about what we delivered?" That question forces you out of your comfort zone to hear answers you may not want — and that is exactly where the gap starts to close.

Conclusion: Humility Is the Best Cognitive Tool

The cognitive gap in internal customer relationships does not disappear as technical skill or experience grows. The opposite: the more experienced the engineer, the easier it is to form the fixed idea "I know what downstream needs", and to equate your own technical judgement with the other side's business need. The scene from the workshop — the supplier sitting across from the customer yet completely misjudging the customer's real need — is not an occasional mistake but a systemic cognitive difficulty.

At the moment of greatest certainty, your cognitive radar switches off. You stop receiving new information, stop validating assumptions, stop listening to voices that might contradict your conclusion. The only way across is humility about your own cognition — not a lack of confidence, but a clear awareness of its limits. It lets you pause before every delivery, switch identity, and ask the simplest and most easily forgotten question: if I received this deliverable, what would my first reaction be?

As one participant concluded at the end of the workshop: "look at both sides of the coin." In the internal supply chain of an engineering organisation, everyone flips between the two sides all day. Every flip is a chance to calibrate. The gap can never be fully closed, but every honest calibration makes it a little narrower. And that may be the basic skill every engineer spends a career practising.