Why Great Engineers Solve the Right Problems, Not Just Their Tickets

When a user taps "Pay" three times and ends up charged twice, the problem isn’t in the backend or the mobile app. It’s in the gap between them—an invisible space where no single engineer owns the full experience. This is the most common failure mode in engineering teams: not poor execution, but excellent execution of the wrong problem. The result? Systems that work flawlessly in isolation but fail spectacularly in the real world.

The Ticket Mindset vs. The System Mindset

Early in their careers, many engineers measure success by ticket closure. A task is assigned, code is written, tests pass, a pull request is merged, and the ticket is closed. This approach is functional for learning, but it becomes a liability when the goal shifts from completing work to solving real business problems.

The engineer who closes tickets efficiently is valuable. The engineer who asks, What problem does this ticket actually solve, and am I solving it in the right place? is transformative. Consider the difference:

• A backend engineer builds a payment endpoint that processes charges correctly, returns proper status codes, and includes robust error handling. Everything is tested. Ticket closed.
• A mobile engineer builds a payment screen that calls the endpoint, handles responses, and displays confirmation or errors smoothly. The UI is polished. Ticket closed.

At first glance, both engineers delivered exactly what was asked. But the business problem—charge the user once and confirm it reliably—remains unsolved. Why? Because the real problem exists in the space between their tickets, where no one was looking.

The Hidden Cost of Network Latency in Payments

Payment flows involve multiple steps: the mobile app initiates the request, the backend processes the charge, the payment processor confirms the transaction, the backend responds, and finally, the mobile app confirms the payment to the user. Network latency can disrupt this sequence at any point, often after the backend and payment processor have logged success, but before the mobile app receives confirmation.

In this scenario, the backend logs show no errors. The payment processor shows a successful charge. The mobile app, however, displays a timeout error: "Payment failed. Please try again." A user who trusts the app retries, resulting in duplicate charges.

The fix isn’t found in improving the backend or the mobile app in isolation. It requires a system-wide solution: idempotency keys. These keys ensure that retrying the same payment request never results in a duplicate charge, regardless of how many times the network drops or retries.

On the mobile side, an idempotency key is generated and persisted before the payment request is sent. This key is included in every retry attempt:

// Mobile: Generate and persist the idempotency key for each payment attempt
const idempotencyKey = `pay_${userId}_${orderId}_${Date.now()}`;
localStorage.setItem('pending_payment_key', idempotencyKey);

// Send with every retry of this specific payment
const response = await fetch('/api/payments', {
  method: 'POST',
  headers: {
    'Idempotency-Key': idempotencyKey,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ amount, currency, orderId })
});

The backend then checks for an existing successful charge with this key. If one exists, it returns the same result instead of processing a new charge:

// Backend: Check for existing successful charge with this key
async function processPayment(req) {
  const idempotencyKey = req.headers['idempotency-key'];
  const existing = await db.payments.findOne({ idempotencyKey });

  if (existing?.status === 'success') {
    return existing; // Return the same result. Don't charge again.
  }

  const charge = await paymentProcessor.charge(req.body);
  await db.payments.create({ idempotencyKey, ...charge });
  return charge;
}

This solution only emerges when backend and mobile engineers collaborate to ask: What does the user experience look like when the network behaves unpredictably? Not Does my component work? That’s the critical difference.

The Illusion of Reliability in Smart Devices

A similar blind spot appears in smart home ecosystems. Consider a team building a smart light:

• The hardware engineer ships firmware that correctly sends state changes to the cloud API. Tests pass. Ticket closed.
• The mobile engineer ships an app that correctly receives state changes from the cloud and updates the UI. Tests pass. Ticket closed.
• The backend engineer ships an API that receives from hardware and sends to mobile. Load tested. Ticket closed.

Users report that the light turns on 11 seconds after pressing the button. No single system is broken—each component operates within acceptable parameters. The issue lies in the cumulative latency across the entire journey. Each layer—hardware transmission, cloud processing, mobile polling, and UI updates—adds 3 to 4 seconds of delay. No one measured the end-to-end experience, and no one owned the user-facing metric: the time between button press and light activation.

This is what happens when reliability is treated as a property of individual components rather than the system as a whole. A backend can achieve 99.9% uptime, but if the mobile SDK polls every 5 seconds, the user’s effective response time is up to 5 seconds before the backend is even consulted. Add hardware latency and cloud-to-mobile push delays, and the gap widens.

To catch these issues, engineers must instrument the entire journey, not just individual components:

// Instrument the user-facing journey end to end
// Not just "Did the API respond?" but "Did the user get feedback?"
const journeyStart = performance.now();

await hardwareCommandAPI.send(deviceId, 'turn_on');
await cloudAPI.pushState(deviceId, 'on');
await mobileApp.pollForUpdates(deviceId);

const journeyEnd = performance.now();
const totalLatency = journeyEnd - journeyStart;

By tracking the full user experience, teams can identify where latency accumulates and address it holistically.

Own the Gap, Not Just the Ticket

The lesson is clear: engineering teams must shift from a ticket-driven mindset to a system-driven one. Success isn’t measured by closed tickets or passing tests—it’s measured by the experiences users actually have. When every component works perfectly but the user still faces failures, the problem isn’t execution. It’s ownership.

The next time your team ships a feature, ask: Who owns the experience when the network drops? Who ensures the user isn’t charged twice? Who guarantees the light turns on in under 2 seconds? Until someone owns the gaps between tickets, your systems will keep working perfectly—and failing just as perfectly.