From Good Engineer to First Choice
How to Become the Go-To Person
Here’s something nobody tells you when you start a new engineering job: the person who writes the best code rarely ends up working on the most interesting problems.
I know. It stings a bit.
But think about it. You’ve probably seen it happen. The brilliant engineer who keeps their head down, ships perfect PRs, never makes mistakes—and somehow, two years later, they’re still grinding on the same maintenance tickets while someone else is leading the R&D project everyone’s excited about.
What’s going on here?
The Game Nobody Explains
When you join a company, you think you’re playing one game: write good code, solve hard problems, deliver value. And you are. But you’re also playing a second game simultaneously, whether you realize it or not.
That second game is about social capital.
Social capital is your ability to get things done that break the normal rules. It’s being trusted enough to turn off a critical system to test a hypothesis. It’s being the first person someone thinks of when an exciting project needs an owner. It’s having accumulated enough respect that your technical opinions actually shape decisions.
Most engineers accidentally destroy their social capital by being nitpicky in code reviews about things that don’t matter. They die on hills about variable naming. They work 70-hour weeks, burn out, and wonder why they feel resentful.
There’s a better way.
What “Being Competitive” Actually Means
Being competitive at work doesn’t mean being the smartest person in the room. It means positioning yourself to work on problems you actually care about.
That requires three things:
Accumulated stature from both engineering and business sides
Trust that lets you trade for space and agency
Understanding of the multi-dimensional landscape of systems, features, and people
Notice what’s missing from that list? Raw technical skill. It’s assumed. It’s table stakes.
The engineers who rise quickly aren’t just technically strong—they’re “substantially more willing to spend enormous amounts of time on the job combined with having very strong soft skills and a capacity to navigate social and power dynamics.”
Let me translate that: they understand that the job isn’t just the engineering. It’s the relationships and power dynamics that make the company what it is.
The Uncomfortable Truth About People
Here’s where it gets real.
Not everyone at your company has equal influence. A random engineer asking for your help gets a different response than the CEO asking for your help. That’s not cynical—it’s just true.
Understanding who matters, what matters to them, and how decisions actually get made isn’t being political. It’s being effective.
The framework is simple:
Who does what? (Map the actual power structure)
Why do they do these things? (Understand motivations)
What matters to whom? (Know what each person cares about)
Who matters? (Yes, this matters—some people have more influence)
You can pretend this doesn’t exist and feel virtuous about it. Or you can understand it and use it to do better work.
Your First 90 Days: The Grace Period
When you join a company, you have a brief window where nobody expects much from you. Most people waste this sprinting to ship their first PR on day one.
Don’t.
Use this grace period to:
Map the codebase end-to-end, up and down the stack
Identify the wizards—the 20% of people doing 80% of what matters
Absorb tribal knowledge that won’t be documented anywhere
Build relationships before you need them
Understand the company’s actual priorities (not the stated ones)
Yes, prove yourself competent. Ship something. But don’t optimize for speed in week one. Optimize for context. The engineers who take time to understand the landscape properly end up going much faster in months 2-12.
Finding the Wizards
Every company has them: the engineers everyone wants on their project. The ones who’ve been there for years and know where all the bodies are buried.
How do you identify them?
How do people talk about this person?
What do they actually work on?
How close are they to the core primitives that make the company tick?
Is their code actually impressive, or do they just have a good reputation?
That last one is critical. Some “wizards” are all talk—internal company influencers who start things but never finish them. They’ll burn you out if you work for them.
Real wizards have a track record you can verify. Look at their PRs. Check their Jira history. See what projects they’ve actually shipped.
Once you find the real ones, get close to them. Read everything they write. Study their PRs. Join their channels. Drop them a DM when you learn something from their work.
You’re not stalking them. You’re doing what apprentices have done for centuries: learning from masters.
The Black Box Strategy
Here’s how to avoid drowning in a large codebase: treat most things as black boxes.
You don’t need to understand how the logger works. You just need to know it logs things. You don’t need to understand the entire auth system. You just need to know how to call it.
Save your mental energy for the components that actually matter to what you’re building. End-to-end understanding comes through repetition over time, not through trying to comprehend everything at once.
Can you do the task by black-boxing as much as possible? Then do that. Copy patterns from other parts of the codebase. Move fast on what doesn’t matter so you can move thoughtfully on what does.
The Speed Trap
“Be faster than anyone else. The faster I am, the more I can do, the closer I can get to working on what I want.”
This advice is both right and dangerous.
Being fast is good. Being perceived as fast is what actually matters. And here’s the trap: sometimes the fastest way to look slow is to work on big, important projects.
Perceptual velocity often matters more than actual velocity. If you’re quietly shipping a massive refactor that takes six months, people might perceive you as slow—even though you’re delivering enormous value.
The solution? Communicate more than feels natural. Ship in visible increments. Make sure people understand what you’re working on and why it matters.
The Better Version of This
Everything I’ve described so far probably made you a little uncomfortable. It sounds calculating. Transactional. Like you’re treating people as resources to extract value from.
Here’s the thing: the exact same behaviors can come from a completely different place.
You can write down things about your teammates because you’re trying to manipulate them. Or you can do it because you genuinely care and want to be a better colleague.
You can map power structures to climb over people. Or you can do it to understand how to help your team navigate the organization more effectively.
You can identify wizards to extract their knowledge. Or you can do it because you’re genuinely curious and want to learn from people who are great at what they do.
The actions look similar. The intentions are different. And people can feel the difference.
The most successful engineers aren’t the ones who are best at manipulating people. They’re the ones who are genuinely helpful, genuinely curious, and genuinely invested in making their team better.
Social capital isn’t built through tricks. It’s built through consistently:
Doing excellent work
Being reliable and fast
Making other people’s lives easier
Communicating clearly
Being pleasant to work with
Caring about the outcome, not just your part
Do those things, and the social capital builds itself.
The Real Secret
Here’s what it all comes down to: if you’re a likable person who does good work, you’ll go incredibly far.
That’s it. That’s the secret.
Respond to Slack messages with more than one word. Don’t be nitpicky in code reviews about things that don’t matter. Say thank you. Ask good questions. Be genuinely interested in what other people are working on.
No task is beneath you. No person is beneath you. Every conversation is a chance to learn something or make someone’s day slightly better.
Work hard, but don’t sacrifice your humanity on the altar of productivity. The engineers who burn out aren’t the ones who work hard—they’re the ones who work hard without building the relationships that make work sustainable and meaningful.
Your Move
You don’t need to follow this framework exactly. You probably shouldn’t. Everyone’s different, and context matters.
But here are the questions worth asking yourself:
Am I building social capital or accidentally destroying it?
Do I understand how decisions actually get made here?
Am I using my grace period wisely, or rushing to prove myself?
Am I learning from the people who are genuinely great at this?
Am I being the kind of colleague I’d want to work with?
The goal isn’t to min-max your career like it’s a video game. The goal is to get to a place where you have the freedom to work on problems you care about, with people you respect, in a way that’s sustainable.
That’s worth working toward.
P.S. I’ve opened a private community for senior engineers who want to step up as tech leads. If you want my direct help, I’m giving 75% off 1:1 coaching for the next 8 members who join.
👉 Apply here: https://www.techleadsacademy.com