Thinking Like a Strong Engineer

Strong Engineers

Strong engineers can do things that weaker engineers just can’t, even with all the time in the world. Some examples of capabilities:

Solving very difficult bugs, e.g., race conditions across multiple services.
Delivering meaningful improvements to the thorniest parts of legacy codebases.
Making changes that require a big architectural rework.

At the top end of strongest engineers, capabilities become something like “improving the SOTA for LLMs”.

Regular engineers make the bulk of most companies. They solve 95% of bugs (normal, non-cursed bugs), deliver most JIRA tickets, and unstick themselves from dev env issues most of the time. They help. They do the work. They’re just not burning with ambition to excel at the next promo cycle. Probably have other things going on in their lives.

Weak engineers are more likely at senior levels. The bar to hire juniors is explicitly capabilities-based and harder to slip by; seniors can talk about work they were tangentially involved with. A weak senior has to conceal their lack of knowledge and needs to learn in secret, which is much harder. They survive by reaching out in DMs to other team members. People can be weak for all kinds of personal reasons that are none of your business. That said, avoid time-asymmetrical helping – don’t let them spend minutes of their day tying up hours of yours.

What Makes Strong Engineers Strong?

Strong engineers need raw confidence to believe that they’ll figure it out, or the problem is too fiendish that there’s no shame in failing to solve it. Tackle the hardest part head-on instead of putting it off or trying to work around it.

Strong engineers are ruthless pragmatists that judge design decisions by how well it will work, not how clean or elegant a solution is. They often come into conflict with smart, technically capable, weak engineers, e.g., “is this design pattern overkill for our use case”.

Strong engineers work fast. Fast execution: (1) lets you experiment rapidly enough to find the right solution; (2) makes low-chance-but-high-reward ideas worth trying and eventually producing high reward; (3) make whole different tasks possible. It’s usually short intense bursts of productivity separated by long periods of relative inactivity.

See Some reasons to work on productivity and velocity by Dan Luu. Referenced by .

Deeply technical people will see simple solutions that others miss, and will be able to solve who categories of problems that other’s cant. The technical strengths needed should match the work that needs doing. Tracing lifetimes and crashes were a good fit for me working in the C++ Chromium codebase; my manager could (and did) throw hot reliability bugs my way.

Value Over Replacement

To measure value, estimate how much profit your specific part of the company is making, and how much your code is contributing to that, e.g., if you unlock a new customer segment bringing in ~5M/year in revenue, then your value is some percentage of 5M/year.

Value over replacement requires guessing what other engineers wouldn’t have done in your place, e.g., digging through metrics to find performance issues. It’s easy to imagine that your replacement is a dud or very strong indeed. Another signal is when you (or another engineer) are explicitly requested for a particular project.

Strong Engineers are Right, A Lot

Strong engineers are right about concrete factual statements (e.g., endpoint X has rate limit Y), concrete plans (e.g., can’t add this check here, but it’ll work there), lots of small decisions when writing code that show up in their code generally working and causing fewer bugs.

Never making confident technical statements is a dereliction of duty. If you’re the most technical in a room, it’s your job to give information and advice. The goal is to “be right a lot”, not “never be wrong”. Being wrong is forgivable, particularly when you’re the only one stepping forward to offer an answer or a plan. Do a high volume of work in a single area for a long time, so you gain deep familiarity and be right (a lot).

I’ve been wrong a fair number of times. What was most encouraging was seeing other more senior engineers being wrong in public as well; if they are fallible, then who am I not to try?

The times that I’ve been painfully wrong was when I tried making a call despite not being the person with the most context. In those cases, I was speaking out of turn.

Strong Engineers Take Positions

When you’re the person in the room with the most context (or technical skill), you need to take a position. Otherwise, you force people with less technical context than you figure it out themselves.

Overusing caveats and qualifiers make managers think “Ugh, why are you forcing me to make the decision myself?” and not “Wow, I’m glad this person is being so careful and accurate”. Their job involves a lot of educated guesses and have internalized that some guesses don’t pan out. Going in the wrong direction will at least often give you information, or provide a base to iterate on.

In low-trust cultures, avoiding commitment is smart. Where trust between engineering and product breaks down, engineers avoid giving estimates because they face unfair consequences when those estimates aren’t met.

Software Engineering Under the Spotlight

“Focus” means “the CEO is actively supervising this”, e.g., CEO asking for daily updates, blockers are removed by force, agile ceremonies are abbreviated, etc. Projects you’ve done under a spotlight are 5-10x more impactful in promotion packets; screwing up can stain your reputation permanently. Make your baseline 80% so that you can flex up to 120% for short periods when the spotlight is on you.

Chasing the spotlight is a good way to get promoted, but has its drawbacks, e.g., always at 120%, constant transferring and context-switching, difficult to build long-term colleague relationships, high pay but still substantially less than the bonuses you’re securing for the VPs.

Some engineers hide from the spotlight. They get intrinsic motivation out of writing code. They don’t want to push for more power or influence and are not terrified of being sidelined or laid off. Nothing wrong with this, but beware the tradeoff: one month grinding in the spotlight is worth one year of grinding in the dark.

Why Some Engineers Get Trusted with High-Impact Work

There are concentric circles of trust. Being the go-to engineer on your team requires being straightforwardly good at your job. Your manager will steer important work your way. Being the go-to engineer in your org has your manager’s peers asking your manager to task you with key pieces of work; your org leader knows your name and occasionally reaches out. Finally, in the inner circle of engineers at your company, all engineering-facing directors and VPs know your name and you’re shuffled to whatever the company considers important at any given time.

To move up the circles, you need invites each step of the way. You get contact with senior managers by working on important projects, which (if you do a good job) encourages them to tap you for more important projects. It boils down to: what does it take to be the kind of engineer the company can trust?

People higher in the management chain are heavily invested in success (bonuses, not getting fired), but have less technical context and direct power to affect the product. They’re almost entirely dependent on their engineers to actually do the work that needs doing.

Be discreet because they come to you with confidential information, e.g., company plans. When they ask you a question, draw out some sense of what the agenda is before committing to a response; this is not the place to opine about code quality. Get the technical questions right, e.g., don’t say it’s impossible to do X and it turns out to be possible. If you break their trust, you’ll be silently and immediately dropped from that circle of trust.

Be vigilant about these cases. There have been times in my career when I’ve been called up, but was too busy to properly step up. I’ve noticed that I didn’t get second invitations. It’ll probably take even more effort to re-enter those circles of trust.

Try to keep it inside your management chain. While it’s pleasant to feel helpful, these people won’t be there during your performance review. You can push back with something like, “I’d love to help. Let me run that request by my manager so she knows what I’m doing.”

How to Choose What To Work On

When the spotlight is on one of your team’s projects, be willing to drop less critical work and be fully engaged. Don’t be knee-deep in other work when the spotlight hits. The spotlight eventually moves on; important work is rare.

Be light on your feet. The only time you should be at full capacity is when the spotlight is on you.

Know when the spotlight is on. Visibly doing other things during an all-hands-on-deck situation is much worse than doing nothing. You can make up for a slow year by absolutely killing it during the right week.

When the spotlight isn’t on you, carve out your own lab days or 20% time. Spend an afternoon on one of your own goals; if it doesn’t provide value (doesn’t build credit with managers or fellow engineers), then the wasted time is on you. The real value of lab days is regularly practicing the skill of choosing what you work on. It takes time to learn which tasks will have a solid impact, and which ones won’t.

Crushing JIRA Tickets is a Party Trick

Promotions, bonuses, and internal respect come from shipping projects, not from closing tickets. Closing tickets is useful for rapid familiarity with the codebase and credit with colleagues, but at some point, transition to prioritizing work you think is the most important rather than whatever work is in front of you.

The failure mode here is assuming the work in front of you is important. It might have been important when it was created, but is it still important?

Importance at a tech company is whatever your C-staff say it is. Ruthlessly drop work that is no longer important. If you ship a project and your management chain begins talking about the next thing, stop improving that project. Declare victory and walk away!

Figuring out what the most important thing is:

Is there an ongoing high-visibility incident going on? Can I help with that?
Is there anyone waiting for a response from my team?
For each project that I’m leading, in order of importance, what can I do to help it ship right now?
For each project that my team is working on, in order of importance, is there work available to be picked up that would move it along?
Are there any tickets on the JIRA board in “ready for work”?

If you only spend your time on the most important thing, you can be hugely impactful with much less than 40h of work per week.

This is where I want to be. I spent 2024-25 working the hardest in my career, but on things that ultimately didn’t matter to my management chain. I mustn’t be a JIRA ticket robot again.

Managers often trust their senior engineers when the engineers tell them that technical work is important. They also communicate gently about priorities, e.g., “Sure, if you think this is worth doing then go ahead,” instead of “I don’t see the value in this work.” Furthermore, company’s stated values may be at odds with their real values, e.g., manager can’t say, “Actually, the company doesn’t care that much if our integration tests are flaky” when the company is doing a lot of messaging about the importance of integration tests.

Getting positive signals from your manager is key then. Seems like they’ll be silent when company’s (or execs') stated values are in conflict with or don’t match their own.

Figuring out an important thing that your organization isn’t doing and them trying to convince them to do it is the hardest way to deliver value. You’re betting that your execs have done a bad job of identifying what they want – that’s a big risk, and even if you succeed at convincing them to let you look at it, it’s unlikely that it’ll be top of their priority list. Worst case, you end up deeply invested in a hard technical task that the company doesn’t value.

It’s possible to be too early to a problem. I faced this when working in a micro-services application.

The problem was “get the Foo data present in the Bar service and persist in the Baz service”. Admittedly, this wasn’t a feature that mattered that much. However, I parsed the problem as an instance of “Foo’s serialization should work for any two services”. Wanting to solve this general case was enticing because it was (1) technically challenging, e.g., services can be deployed independently and the de-serialization should never break, and (2) could be reused by multiple teams because Foo is a very common type in the code base.

However, my management chain didn’t care about the general problem per-se. Furthermore, code-owners outside my team doubted the need for a general solution. In the end, I never shipped anything, and burnt capital with my management chain.

3 months later, the org wants to solve the same problem, and the docs and PRs I drafted are being used to guide that work. While validating to me, burning capital wasn’t worth it – my management chain still doesn’t care about this problem.

References

What can strong engineers do that weak engineers can't? Sean Goedecke. www.seangoedecke.com . Dec 27, 2024. Accessed Nov 23, 2025.
What makes strong engineers strong? Sean Goedecke. www.seangoedecke.com . Jan 9, 2025. Accessed Nov 23, 2025.
Value over replacement in software engineering. Sean Goedecke. www.seangoedecke.com . Mar 1, 2025. Accessed Nov 23, 2025.
Good engineers are right, a lot. Sean Goedecke. www.seangoedecke.com . Feb 6, 2025. Accessed Nov 23, 2025.
Engineers who won’t commit. Sean Goedecke. www.seangoedecke.com . Feb 10, 2025. Accessed Nov 23, 2025.
Software engineering under the spotlight. Sean Goedecke. www.seangoedecke.com . Apr 12, 2025. Accessed Nov 23, 2025.
Why some engineers get trusted with high-impact work. Sean Goedecke. www.seangoedecke.com . Dec 22, 2024. Accessed Nov 23, 2025.
How I decide what to work on at large tech companies. Sean Goedecke. www.seangoedecke.com . Mar 1, 2024. Accessed Nov 23, 2025.
Crushing JIRA tickets is a party trick, not a path to impact. Sean Goedecke. www.seangoedecke.com . Jan 14, 2025. Accessed Nov 23, 2025.