As I was thinking about this, the analogy of taking a car to the mechanic came to mind. When you leave your car for repairs, the mechanic will typically provide you with an estimate of when the repair will be completed. If it’s a simple task, such as replacing a part, the mechanic might tell you that it will be ready by the end of the day. For more complicated repairs, they might say it will take a few days. In my experience, mechanics tend to give themselves a bit of extra time when providing an estimate. They know that things can go wrong, such as parts not arriving on time, unexpected issues cropping up, or complications that could delay the work. This is why they often tell you to come back at the end of the afternoon, even if the task is just a matter of one hour, or add an extra day or two to the estimate for longer operations, ensuring that they are not overly optimistic and leaving room for uncertainty. While this may occasionally lead to a situation where the repair takes a bit longer than expected, as a customer, I am usually understanding, even if it means that I have to make arrangements to reorganize a few things. After all, the mechanic has communicated the potential for delays and has made a realistic commitment. This transparency and realistic commitment is what I believe the software development industry lacks. In many cases, as developers, we are hesitant to provide commitments that include the necessary margin for error. Why? Are mechanics naturally gifted in this area? What is their secret weapon?

In the software industry, the primary individuals we make commitments to are often our managers. Unlike mechanics, who treat their customers as…​ customers—​meaning they are focused on customer satisfaction—​developers often approach their managers with the goal of pleasing, or impressing them. After all, they’re the ones who get to decide for your bonus…​ So we make a bet. And we keep making it day after day, week after week, crossing fingers and hoping for the best. But as we do this, we may downplay the risks or challenges involved in a project, providing overly optimistic estimates in an attempt to please them. The issue here is that this can lead to broken promises, missed deadlines, and a lack of trust, not to mention the dreaded burn-out. Quite the opposite of the intended effect. The core issue is that we do not view our managers as “customers” in the traditional sense. In the same way a mechanic is not trying to impress the car owner but instead focuses on delivering a satisfactory repair, we should aim to satisfy our managers, not merely impress them. The truth is, when we try to please or impress our managers, we are really just trying to satisfy ourselves. Satisying your managers may seem less rewarding in the short term, but trust me, it will prove the best option in the long run: by focusing on their satisfaction rather than attempting to please them, we can set more realistic expectations and foster a more honest and transparent working relationship.

So, how can we improve this dynamic? The answer lies in a simple word: Honesty. Start a conversation with your manager. In fact, it might be helpful for teams to have a “Manager Success Index” (similar to a customer success index) to gauge what their managers truly want and expect. Having a candid conversation with your manager about their expectations and priorities can help align your commitments with what is realistically achievable. By focusing on satisfaction over impression, we can build a more honest, transparent, and effective working environment. Most managers (except some old-school, die-hard, heartless / insecure ones — we know them) will appreciate knowing that their developers are committed to delivering quality work, even if it takes a little extra time. In the end, this approach not only leads to better outcomes but also strengthens the trust and professional relationship between developers and managers.