Engineers love solving problems. That's the problem
At standup, the team made a call. The feature they needed wouldn't be ready in time, but they found an undocumented API that could work. Problem solved. Deadline safe.
Two months later, they went through the full release process again. And external testing. And additional regulatory costs. The workaround didn't work across all jurisdictions. The customer complained.
The problem with being good at problems
When you see a problem, you solve it. That's the job, right? Not always.
The team saw a clear problem: the platform feature wouldn't be ready before the deadline. They identified a solution using an undocumented API. They executed and hit the date.
But they never asked if the date mattered. Product management was never consulted about waiting one month. No one asked if they could reduce scope. The feature was only needed by one customer. They assumed the deadline was the goal. The deadline was just a date.
Dates feel concrete because they are concrete
December 31st is a real day. Q4 ends. The calendar doesn't negotiate. That makes dates feel important. Dates are the easiest thing to focus on because they are the most concrete part of the product.
But concrete doesn't mean critical.
Most software deadlines are based on sales targets, quarterly revenue projections, or executive pressure. Very few are actually immovable. The team treated the deadline like physics. It was politics.
What they should have done
When they learned the platform feature wouldn't be ready, they had options they never explored.
They could have waited one month. Product management might have been fine with it, but they were never asked. The team assumed they would say no. They could have reduced scope and shipped without the feature since only one customer needed it. Again, product management might have preferred that trade-off. They were never asked. The team knew that scope never goes down.
Or they could have communicated the risk. Use the undocumented API but tell stakeholders it might break in certain jurisdictions. Let someone else decide if that risk was acceptable.
They did none of these things. They saw a problem and solved it.
Not every problem needs a solution
This is hard for engineers to recognize in the moment. You're trained to solve problems. That's your value and what you're good at.
But not every solution adds business value. Not every problem is worth solving. And dates are always made up.
Before you jump to solve, ask one question: How does this benefit the end customer or create value for the business?
If the answer is "it hits the deadline," that's not an answer. That's an assumption. The team assumed hitting the date mattered more than code quality, regulatory compliance, and customer experience. They were wrong.
Sometimes the best solution is no solution
The team could have done nothing. Shipped without the feature. Told product management they'd need another month.
Instead they used an undocumented API. They hit the deadline. Then they started over.
Just because you can find a solution doesn't mean you should use it. Stop solving every problem you find. Start asking if the problem needs solving at all.
What to do Monday morning
Next time you see a problem and immediately start solving, stop.
Ask yourself: Does this problem need solving right now? What happens if we don't solve it? Who decided this was urgent?
Talk to product management. They might be fine with the delay. They might prefer reduced scope. They won't know you need trade-off decisions if you don't ask.
The deadline feels real because it's on the calendar. The customer's experience is real because it affects your business. Focus on what's real.
What's a deadline you hit that you wish you'd pushed back on?
You're great at the work. Let's make it visible.
If you're looking for help communicating trade-offs to stakeholders or knowing when to push back on deadlines, consider contacting me. Let's talk about how you can lead with clarity instead of just hitting dates.
Comments
Post a Comment