When you’re running a project in a tech company, understanding that your main job is to ship the project goes a surprisingly long way. So many engineers spend their time on peripheral questions (like the choice of technology X or Y) when core questions about shipping the product (for instance, how all the critical paths will actually work) are still unanswered¹.

If you’re able to reliably ship projects, you can get away with being slightly abrasive, or not filling out your Jira tickets correctly, or any number of other small faults that would cause other engineers to be punished.

You could see this as a special case of the Pareto principle: the idea that 80% of consequences often come from 20% of causes. But I think in many contexts it’s even more extreme, closer to 90/10 or even 99/1. If you get the “main thing” right, you can get away with a lot of mistakes.

This principle holds in many other areas. When saving money, it doesn’t matter if you save a few dollars by hunting for deals if you then buy a car or house that’s on the edge of your budget. If you’re writing, clearly expressing your point will make up for awkward grammar or other mistakes, but even beautiful prose is bad writing if it doesn’t say what you mean. If you’re trying to get fit, consistency and avoiding injury is far more important than finding the most efficient program or the best gear. And so on.

Identifying the “main thing”

How do you identify the main thing? This is a pretty deep question. I have written extensively about this when it comes to working in large tech companies: you can read Knowing where your engineer salary comes from, or browse my posts tagged “tech companies”. In under twenty words, I think it’s “delivering projects in order to increase shareholder value and make the ~2 layers of management above you happy”.

From the way I’ve phrased it, it should be clear that I think this is the “main thing” for working in tech companies. It’s not the main thing for life in general, or for being a fulfilled software craftsperson, and so on. Those two domains have completely different main things².

Sometimes the main thing seems too simple to be important. Plenty of software engineers think something like “of course it’s important to ship the project, but that only happens as a result of writing all the code”, underrating the set of complex factors (both in code and elsewhere) that have to come together for a successful ship.

The only general reliable method I know is to carefully look at cases of success and failure, and to identify what the successes had in common. Pay particular attention to successes or failures that surprise you. If you thought a project was going really well but the people who ran it weren’t rewarded, or you thought a project was a complete disaster but it ended up being celebrated, that probably indicates that you’re mistaken about what the “main thing” is. Did someone get a staff promotion but you think they’re terrible? Is someone beloved by senior leadership, but you can’t see them doing anything that useful? Those people are probably getting the main thing right³.

It’s hard to even try

The first step in correctly identifying the main thing is to try. In my experience, it is surprisingly hard to motivate yourself to focus on the main thing. It’s much more natural to just jump into something that looks probably useful and start working immediately. Why is this?

One obvious reason is that it just feels bad to sit around contemplating all the things you could focus on. It’s much easier to account for your time - both to others and to yourself - if you look busy. What if you can’t come up with anything, and you’ve just wasted all the time you spent reflecting?

Another, less obvious reason is that many people are afraid that they might not like the main thing. Recall my description of the main thing at tech companies:

“delivering projects in order to increase shareholder value and make the ~2 layers of management above you happy”

Lots of software engineers really hate that this is the most important thing. I wrote about this at length in Software engineers should be a little bit cynical and You have to know how to drive the car. If you don’t like this goal at all, it’s going to be tough to spend time thinking about how you can achieve it.

In fact, I think it’s actually more important to think about the “main thing” if you hate it. This is why I’m suspicious of “do what you love” advice. If you love performance engineering but your company doesn’t, I think you’re better off doing it in your spare time and creating shareholder value at work, instead of trying to do as much performance engineering at work as you can.

Half-assing creating shareholder value a few hours a day (and doing performance engineering the rest of the time) is more valuable than locking in to the wrong “main thing” for ten hours a day. In my experience, it’s also likely more burnout-resistant, since there’s no faster path to burnout than working really hard on something that isn’t valued.

Caution: the “main thing” can rapidly change

In 2015, being easy to work with was the most important thing in many tech companies. If you were a pleasant colleague, you had to be really bad at other aspects of the job to face serious professional consequences. On the other hand, if you were abrasive and hard to work with, it didn’t really matter how technically competent you were. Many engineers made successful careers by maximizing pleasantness: attending and hosting work social events, making friendly connections in different teams, and in general becoming a known engineer in the company.

In 2026, it’s still important to be pleasant. But now that tech companies are tightening their belts and feeling more pressure to ship, the most important thing has shifted to being capable of delivering projects. If you’re able to do that, it can go a long way towards redeeming a difficult personality. Like love, shipping covers all sins. This transition has been a bumpy ride for many software engineers.

A lot of very pleasant “known engineers” have been laid off in the last three years. I suppose the lesson here is something like this: even if you’re doing great and are well-adapted to your niche, the environment can change and screw you over anyway. What can you do about it? If you’ve spent a good chunk of your career developing one set of skills, you can’t instantly transfer all that experience to a different set of skills when the environment changes. Maybe the underlying lesson is more like this: instead of over-specializing to a single niche, hedge your bets by being pretty good at multiple things.

Final thoughts

The lesson here is that you should spend a lot of time and effort trying to figure out what to focus on. In the extreme case, even spending half of your time doing this is worthwhile, if it puts you on the right track and you’d otherwise be neglecting the main thing.

This can seem pretty unintuitive. It feels safer and more productive to be doing something. But if you can force yourself to focus on the meta-question of what you ought to be doing - even if you don’t like the answer - you’ll be in a better position to achieve your goals.