Some people say it’s impossible. Some people say it’s hard. I say it’s not easy but achievable. In this article, I’ll try to explain my approach to managing the balance between business needs and engineering excellence.

Pragmatism in Action

I consider myself a very pragmatic person. If I don’t need something, I discard it. If a task can be done tomorrow, I do it tomorrow to avoid overthinking. When I need to purchase something, I buy it because it’s necessary. Similar concepts can be applied to software engineering and working in a team. Let’s explore an example situation that has occurred to me multiple times. A product manager once asked me:

“Hey Mariusz, I would like to ask you if we could somehow deliver this bug fix/feature faster. You know how important it is for our merchants. We receive a lot of support requests, and it’s becoming quite burdensome for our agents to answer all of them.”

In such situations, there are multiple possible answers. Let’s review each of them.

Answer 1: Technical Rigidity

“Sorry, it is not possible. We need more time to deliver good quality code.”

In this situation, we don’t balance business needs at all. We focus purely on the technical aspect, ignoring the impact on the product and the entire organization, such as the overload of support agents. Generally speaking, I consider this kind of answer to be the least appropriate, as it leads to multiple consequences: lack of trust, being considered not as a team player, and communication issues with the product in the future.

The only reason to provide this kind of answer would be due to a lack of trust in the product manager, who may have lied to you in the past. In that case, it should be addressed with proper, direct feedback instead of building a toxic relationship.

Answer 2: Blind Acceptance

“Oh sure, no problem, we’ll do a workaround quickly and deploy it today.”

While this answer may be better in some scenarios, in my opinion, it’s not good enough. We allow the product manager to have full ownership of the technical aspect of the product, making it possible for them to come to us with any request and demand to satisfy it in a very short time. Firstly, we shouldn’t accept the request without getting more context — it’s dangerous and can lead to consequences such as untested errors in production, immense pressure on the team, and missing pieces of a solution. I also see a danger in the second part of the answer, which is “deploy it today.” I would avoid promising anything like this unless the fix changes something straightforward, like changing a button color. What if the fix is not easy to apply to the code that is already in progress toward the proper, clean solution? What if QA finds a critical bug that takes more time? Always think about the consequences of your promises, as it can lead to a lack of trust.

Answer 3: Pragmatic Collaboration

“Can we please talk more about this issue? I’d like to understand more about the urgency and how much time we have to fix the issue. We’ve already started working on a proper solution without workarounds, and I’d like to avoid doing the workarounds if we can deliver the proper version soon. If we agree to the workaround, I expect you will give us more time to finish the proper solution and remove the workaround later this week/during the next sprint.”

This would be my pragmatic answer and usually is. In this answer, we first try to understand the importance of the request because, in many situations, these requests are not estimated enough. Sometimes it is due to pressure from leadership, sometimes due to a lack of experience from the product manager, and sometimes just from not getting all the details from the support.

After we get more details, we need to estimate the overall impact on:

• Product
• Team
• Organization
• Code/Infra

If the impact on product/organization is high (i.e., support agents experiencing significant delays in answering questions), we most likely should accept doing the workaround (if possible), especially when delivering the right approach could take a lot of time.

If the impact on the team is high (i.e., a lot of team members are involved in resolving support requests), we should decide after discussing the possible options with the team members.

If the impact on code/infra is too high (i.e., it would require delivering a completely new component to K8s just to remove it a few days later), we can refuse the request and ask for more time to deliver the right solution.

The last important part of the answer is agreeing on the fact that the workaround should not stay in the code forever. That’s a compromise that should be (almost) always done to avoid the situation where we only do workarounds and quick fixes instead of focusing on the long-term maintainability of the codebase.

Real-life Example: Collaborative Decision-making

Recently, in my company, we were exploring a new feature that was important for the team and the organization (we received many feature requests from support agents). The team made a discovery and estimated that it would take around a year to deliver the feature. This timeline wasn’t acceptable, as the request was urgent. One of the engineers found a workaround and presented it to the team. Because of the increasing number of requests, the team decided to use the workaround, deliver the feature in 3 months, and then work on the proper solution afterward. I think that was an exemplary collaboration between product managers and engineers.

Conclusion: Learning from Experience

The entire topic of balancing business needs and engineering excellence is, of course, much bigger, and it’s hard to provide an example for every situation that can happen in your team/company. I wrote this article to reflect a bit more on your day-to-day work and see if, perhaps, you’re not making my mistakes. When I started my career, I usually answered with the 2nd answer. Later on, when I gained more technical experience, I started to answer with the 1st. Only after several years of changing my roles and teams, I realized that the proper answer is the last one.