The double-edged sword of taking pride in your craft

Suppose you’re in a Formula car race as part of a team that’s attempting to win at all costs. You’ve been preparing for this race nonstop and around the clock. People are hyped up, and the race starts. Your car is racing alongside all the others and is doing well. Suddenly, a tire blows out. Normal. This happens, and that’s why there is a pit. Your driver heads to the pit, stops at your designated spot, and your whole team rushes to the car to change the tire in seconds. Every millisecond here counts. Your car then leaves the pit, gets back into the race, and the momentum is still extremely high. This is expected, right?

Now let’s take a step back and imagine for a moment that one member of your team, instead of helping change the tire or lift the car, says, “Why don’t we check the engine? Might as well!” Or someone else goes, “You know, while we’re at it, let me take a minute to make sure the screws on each tire are optimally tightened, just in case.” That would be insane, right? But guess what? In the work environment, especially in startups, this is sometimes exactly what we do as software engineers, and people from other professions do it too.

At times, we become very disconnected from the real world to the point of doing the equivalent of this in different ways. We lose sight of the things that matter in favor of things that simply grab our attention. We find ourselves optimizing things that either should not exist in the first place or are meaningless in the sense that they do not really align with delivering the project. And these projects almost always originate from something very simple: an opportunity to pursue or a problem to solve. That’s it. The solution doesn’t even need to fix the problem with a ten-year warranty. We just need to win the race now, remember?

If this analogy did not land, let me take you through another one that I’m very fond of. I come from a small town in Saudi Arabia. Unlike extremely populated and busy cities like Riyadh, there is almost no traffic there. On many streets, you don’t even need traffic lights. Roundabouts do just fine because, in most cases, traffic is extremely low-volume. Only a few cars might pass in an hour. It wouldn’t make sense to install traffic lights and have cars waiting when the problem could be solved with a much cheaper and more efficient solution: a roundabout.

Now imagine a civil engineer was assigned such an intersection and thought, “You know what? Let me build a fully sophisticated highway with a cloverleaf interchange because it’s better.” Well, is it actually better in this case? You just spent 20x the cost, or more, and it may not even be more convenient for drivers. It’s overly complicated for no reason and might actually make the journey longer. But then the engineer justifies it by saying, “Well, it’s scalable in case the intersection grows in volume later.” Okay, but what if it doesn’t? There may be plenty of reasons to believe that it won’t. And wouldn’t the whole thing require maintenance throughout that period anyway? Even ten years from now? Wouldn’t it have been better to build a simpler solution that fits your needs today, and then, in ten years, if the need actually exists, scale it up?

Usually, people who take pride in what they do fall into this trap because they think the only way upward is to solve the same problems in increasingly fancy ways now that they are more senior. No. You were doing good work already. You should keep doing good work, or maybe do more of it. That’s it. It’s not complicated, and it doesn’t have to be. This is the double-edged sword of taking pride in your craft, and I’ve been guilty of it myself. You either tame that urge to perfect everything and turn it into a strength, or you fall into a trap that leads nowhere but disappointment in yourself and frustration with others.

Throughout my experience building things in the startup industry, I’ve found that in many cases, 50–60% of the time spent building a new feature goes into activities that are completely irrelevant, or at least loosely relevant, to the intended objective. Sometimes this happens subconsciously. Other times, the time is wasted in alignment, sync-ups, waiting for one team to provide copy, another team to share graphic designs, and then spending weeks or months contemplating which flow is best.

Let me be very clear: nobody cares as much as you think they do about how good the graphic designs look. In many cases, 80–90% of what users care about is that the thing exists and that it works. I would rather have a functional feature than have nothing at all. And now that we have AI agents, it’s easier than ever to do some of this work yourself. You can write the copy yourself, generate initial graphic designs yourself, create rough flows yourself, and get on with it. It may not look as fancy as something that went through weeks of back-and-forth, but it took seconds or minutes instead of weeks or months.

And let me repeat: it does not matter nearly as much as you think it does. What matters are your objectives, which I’m assuming are related to things like traction, revenue, ROI, customer acquisition, retention, or whatever outcome the business is actually trying to achieve.

Finding Purpose in the “Wrong” Things

I get it. In the corporate world, the way work flows from ideation, to building the product, and then selling it can actually encourage this behavior. Mostly because the vision of the product is not always shared downstream. Instead, everyone is expected to do their part, sometimes without conviction and sometimes without fully understanding the “why” behind it all.

So what do you do as a good engineer if you don’t really understand why you’re building something, what purpose it serves, or what objective it aligns with? You try to find purpose and fulfillment in other things. Instead of finding meaning in the actual challenge in front of you and the outcome it brings to people or to the business, you start finding meaning in the solution itself. You over-engineer the problem because that gives you something tangible that you can feel proud of building and delivering.

The problem is that this very rarely aligns with the shared goals or objectives. You’ve overlooked the most important aspect of it all: the business.

If you start looking at your work that way and shift your mindset toward a more business-driven one, you can achieve much more without necessarily putting in more effort. You can assess your value based on how much you actually delivered, how much user traction it brought, how intuitive and seamless it felt to users based on their feedback, how much revenue it generated, how much friction it removed, or how much time or money it saved. The list goes on.

It’s all about perspective and being aware of how your work contributes to the overall objective, what the current priorities are, and what battles the team is struggling with at the moment. You don’t want to be optimizing irrelevant workflows or adopting a new tech stack while the team is struggling with stagnant revenue and is in desperate need of growth.

So start by digging deeper into these things. Understand how the team around you operates. What are the short-term and long-term shared objectives? What are we actually striving for? Then look at how, to the best of your abilities, you can contribute to those objectives.

Not the other way around.

Don’t fall into the trap of starting with the technology and then trying to make business sense out of it. You will almost always be biased enough to come up with a long list of plausible justifications for doing it. Start with the business objectives, then work your way down to your role, your responsibilities, and how you can contribute the most.

An engineer who speaks the language of business is invaluable to the team.