The Art of Picking the Right Battles at Work

I recently read an interesting article on a concept called “performance plateau”. The idea is that after a certain threshold, making a web site load faster isn't going to matter to its users.

The business implication of course is that the time invested in optimizing performance beyond this plateau would yield a better return if used on other matters. While this is common sense, it's surprisingly easy to become unaware of as an engineer. Beyond just performance optimizations, diminishing returns are real in many other areas of engineering work too, and prioritizing the right thing can be the most important skill to learn in your career.

This is thinking like an owner.

For instance, many engineers instinctively like to spend a lot of time refactoring old code into something cleaner. While paying back tech debt can be beneficial, in many contexts it's hard to justify it being more important than developing new features or fixing bugs.

“But bad code leads to bugs and slows down future development, which cost money!", you might argue. "Besides, it's good for eng retention and employer branding”. And I get it! It's usually the “right” thing to do, and it's what we're taught at school and on engineering blogs.

Engineers love doing the right thing code-wise, whether it's conforming to the latest trend in clean coding or re-architecturing the app stack to microservices. But I think engineers should be more focused on doing the right thing business-wise — and arguably refactoring code is not usually¹ the right thing to do business-wise.

Most employees work for companies that have business objectives², and how well an employee serves the company's business objectives tends to determine their worth to the org.

When times are good, companies tend to throw money at all sorts of low-return initiatives in the off-chance that they yield unexpected benefits — the logic behind spending is not always very rational, and is actually a good reason for a company to return excess cash to its owners in dividends³.

But when the tide turns and cash flow dries up, employees entrenched working on unprofitable things are the first ones shown the door. Therefore, the best way to obtain job security (and maybe even a raise) is to position oneself within the company to work on something that drives revenue or profit, preferably backed with tangible numbers.

This is where the “owner-mindset” comes into play: if you owned the company and your target was to at least keep it alive, or preferably grow it, what would you do?

You'd work on whatever gets the most money in the door.

To fulfill this, find a task that's suitable for your skillset and that generates the most monetary value and start working on it. In a bigger org, you might need to transfer teams and play office politics to get there, or if no such tasks exist, update your skills. (Admittedly, in startups that are still searching for product-market fit, identifying the right bet might be difficult, so showing willingness to work on a bit of everything and show your “hustle mentality” might be the right move).

If we take a step back, it all boils down to supply and demand:

Companies demand revenue.

Employees are supposed to supply it.

That's the math; and no amount of manifesting will change it.

I think Americans tend to understand this dynamic better than us Europeans; it's a dog-eat-dog world across the Atlantic, and American employees don't enjoy much job security compared to many European countries (for my European friends confused what I'm talking about: go read up on at-will employment and know that paid holidays are not mandated by US law).

I think Americans also tend to understand better that companies exist primarily to turn profit⁴, and thus fundamentally differ from a state, which primarily exists to serve its citizens' well-being (though some countries seem to have a differing view on that)⁵.

Anecdotally, I once worked with an engineer here in Finland who was upset about our employer (a digital agency) stressing the importance of employees having a high utilization rate⁶.

“I'm more than a number!”, he proclaimed. “The company should acknowledge the great work I do on open source projects [work sponsored by the company, but not bringing in revenue].”

Well, I'd argue the employer should primarily view him as a number, and if that number is negative, the company won't want to keep paying him.

(I wonder what he's up to these days.)

Ultimately, understanding your role as part of a supply chain — where your work must generate tangible value — is key to success in any company.

A bit more on supply and demand:

I've met surprisingly many people who graduated from a university and thought it alone would secure them a job. While luck, timing, and location certainly play into one's employment opportunities, it's naive to assume companies would hire you just because you have a diploma. For many roles, there are probably hundreds or more other applicants with resumes more or less identical to yours, so it should come as no surprise that many people struggle finding their first job.

There's also been a lot of worrying about AI tools taking over entry-level jobs, on which Byrne Hobart⁷ wrote an interesting contrarian take:

LLMs are good at synthesizing the big picture stuff, and struggle with precise tasks without supervision, so it's the senior people who should be worried, not the entry-level juniors. The same supply chain thinking applies here too: it's not the seniority or credentials that matter, but the tangible value you create.

Focus on that, and you'll adapt better to the brave new world of AI.