dp.cx blog

I wrote a while back about learning to say no - pushing back on requests that don't fit the system, setting boundaries when you're stretched thin, getting comfortable with the discomfort of telling someone "this isn't the right call." That post was about building the skill. This one is about what happens when you use it and it doesn't matter.

A client wanted us to put a field on a screen where the data is auto-generated by the system. The problem is that the auto-generated data doesn't match what the client actually wants to see there. It's not a configuration issue or a bug - the data the system produces and the data the client wants are fundamentally different things. Putting one where the other belongs would be misleading at best.

A few of us flagged it. The system generates this data for a reason, and overriding it with something else would undermine the purpose of that screen. We proposed alternatives. We explained the mismatch. We pushed back, and the answer was no - build it anyway. So we pushed back again, with the same reasoning, and got the same answer. The client's contract was too large to risk the relationship over a field on a screen.

What's frustrating isn't the decision itself. I've been doing this long enough to know that business priorities override technical judgment sometimes, and that's not always wrong. The frustrating part is the downstream cost that nobody had to approve. Because we couldn't misuse the existing data without breaking the system's integrity, we had to build entirely new functionality to support what the client wanted. That's engineering time that didn't need to be spent. On top of that, the reporting team now has additional work to account for this new data path - work that exists purely because a short-sighted request got forced through. The decision was to accept the field, but the engineering and reporting costs that came with it were never part of that conversation.

In the original post, I mentioned that sometimes you pick your battles and absorb a request you don't love because the political cost of fighting it isn't worth it. That's still true. But there's a difference between choosing to absorb something and having your objection acknowledged and then set aside because the contract is big enough. The first one is a judgment call you're making. The second one is someone else making it for you.

What I've landed on is this: when the override happens, the thing I can still control is how cleanly I build the solution. We didn't jam the client's data into a field where it didn't belong. We built something separate, even though it cost more. The system's integrity stayed intact, even if the process that got us there didn't - but it's a frustrating way to spend engineering time, solving a problem that didn't need to exist.

If there's a takeaway, it's two things. When the override happens, put together a plan to do it right - accept the decision, but don't accept the shortcut it implies. That's what we did when we built separate functionality instead of jamming data where it didn't belong, and the system is better for it. And before the work starts, be clear about the tradeoffs that come with doing it right. A proper implementation meant entirely new functionality, additional reporting work to account for the new data path, and ongoing maintenance that wouldn't exist if the request had been scoped correctly in the first place. Put that cost in front of the people saying "build it anyway." They should be making that decision knowing what the right implementation actually costs, not just approving a field on a screen.