Bhavana

It’s 2 AM, and I’m staring at my screen, bleary-eyed and frustrated. The CI pipeline has failed for the third time tonight. I’ve spent the last week writing tests for a feature so small, I’m not even sure anyone will notice it. As I sip my cold coffee, a thought creeps in: “Is this really what being a software engineer is all about?”

I remember the excitement I felt when I first joined this company. I saw the demos and fantasized about how much I could help improve the product. Yet here I am, wrestling with some dependency that a guy who isn’t even on the team anymore thought “was better than reinventing the wheel.”

I’ve talked to other developers, and I’m not alone in this sentiment. We complain about product managers who don’t “get” tech, about the constant pressure to deliver faster, about the endless cycle of maintenance and technical debt. Tasks can feel like endless busywork. But are they really what our job is all about?

The uncomfortable truth is, we engineers often create our own prison of tedious work. We revel in optimizing systems that don’t need optimizing, refactoring code that’s already functional, and chasing the latest shiny tech stack. All while losing sight of what actually matters to the business and users.

To break free from this self-imposed drudgery, let’s take a step back and look at what a business actually wants from their software:

1. Acquire users
2. Keep users
3. Help users spend more money
4. Reduce operating expenses
5. Make leadership look good to stakeholders

Notice how none of these directly mention writing clean code or mastering the latest framework? That’s because those are at best table stakes and at worst procrastination.

So how do we bridge this gap between what engineers typically focus on and what businesses actually need? Here’s my approach:

Start by understanding the current constraint of your business. Most of the time, this boils down to “actually solving the problem.” But if you’ve got a product people are already using, you might need to focus on other factors.

For acquiring users, think about:

• Selling a dream outcome: people don’t start based on how good something is, but by the image in their head of what life will be like after they use it.
• Making your software beautiful: even if this is just in screenshots, but ignoring aesthetics is a bad idea.
• Reducing onboarding friction: put less screens between their decision to try it and actually starting to use it.

To keep users, focus on:

• Actually solving their problem: This is the foundation. If your software doesn’t do what it promises, nothing else matters.
• Assisting them in attaining their dream: Go beyond the basic functionality. Help users achieve their ultimate goals, not just complete tasks.
• Making the experience enjoyable: User delight isn’t just a buzzword. Find ways to make your software fun or satisfying to use.
• Creating ethical “switching costs”: Build features that make your product more valuable over time, like personalized data or integrations, so users have incentives to stay.

Helping users spend more money involves:

• Reducing payment friction: Make it effortless for users to upgrade or make purchases. Every extra click is a chance for them to reconsider.
• Enabling user success: The more value users get, the more likely they are to invest further. Focus on features that amplify their results.
• Showcasing their wins: Build in ways to highlight user achievements. This reinforces the value they’re getting and justifies further spending.

Reducing operating expenses means:

• Optimizing resource usage: Look for ways to cut costs in compute time, storage, or human effort. Small efficiencies can add up to significant savings at scale.
• Streamlining necessary evils: Every business has unavoidable processes. Make these as painless as possible to reduce hidden costs of frustration and lost productivity.

And to make leadership look good:

• Understanding stakeholder motivations: Get to know what drives your leadership and their bosses. This insight can help you align your work with their goals.
• Bridging user needs and business goals: Find ways to demonstrate how solving user problems directly impacts business metrics that leadership cares about.
• Speaking their language: Learn to translate your technical work into terms that resonate with non-technical stakeholders. This skill is invaluable for career growth.

The key takeaway here is simple but often overlooked: unless what you’re working on directly impacts one of these core business goals, you should probably be working on something more important.

That dependency update you’ve been putting off? It can wait if it’s not directly impacting user experience or system stability. The massive refactoring project you’ve been itching to start? Ask yourself how it ties into acquiring or retaining users and how you could actually measure and test that.

I would guess most SWEs and their teams are not directly addressing these core business needs (because most software adds problems rather than solving them). So they should probably focus on the work in front of them to make their software actually solve their users’ problems.

This doesn’t mean all those “boring” tasks are unnecessary. They’re often the foundation that allows us to build software that truly matters. But they’re the minimum bar, not the end goal.

The next time you find yourself deep in the weeds of a technical task, pause and ask yourself: “How does this contribute to our core business goals?” If you can’t draw a clear line, it might be time to re-evaluate your priorities.