You Can Be Both

I recently saw a post arguing that exceptional people are rare because they’re so focused on their craft that they skip “bureaucratic bullshit” and “often left other skills to rot”. I left a comment explaining that it’s a 50/50 situation. In this piece, I’ll expand my take on this more in depth. Exceptional people comes in different shapes and forms. Pretending that someone can’t be exceptional simply because they learned to deal with the “bureaucratic bullshit” feels like a weird stereotype. (If anything, this reads like the exact type of mentality that gave birth to the “10x engineer” meme lol.)

This is part of a series (The Opinionated Engineer) where I share my strong opinions on engineering practices.

There’s this weird stigma that you’re either a technically strong engineer or good at “playing politics”. These aren’t mutually exclusive. In fact, some of the best engineers I’ve worked with are good at both because they quickly learned that “playing politics” is critical to their success so they get good at it while continue to back themselves up with strong technical depths.

Being good at something doesn’t mean you love doing it. Many of these great engineers would absolutely prefer to just code and solve technical challenges all day rather than spend time in planning meetings, doing stakeholder alignment, or navigating organizational politics. If you gave them the choice, they’d pick the technical work every time. But they recognize that in most environments (especially as you grow in seniority), the non-coding work is the best way to scale your impact so they quickly learned to get good at it.

It’s like pundits complaining about modern NBA playing for the foul calls. These players are still some of the best in the world without it, but they learned that being good at it is critical to their success, so they adapt their game to it. Same thing 20 years ago with the kick-out jumper that Kobe Bryant and Ray Allen did.

A lot of this comes down to understanding what your company / org is biased towards or against in their performance evaluations. Unfortunately, it’s not always what the org needs but mostly what it thinks it wants. Different orgs has different priorities, speaking with a more senior engineer in the org (or observing more carefully) can show. As an example, certain orgs in Meta has very strong preference for engineers with strong technical skills so you need to be strong code reviewer and technical designer to get (a better chance) at promotion. Others prefer more tech leading skills so you need to show relevant ability - roadmap, plan, drive discussions, create scope - for a better shot at earning that promotion. Some places look for a floor raiser to help them build a 0 -> 1 project; others look for someone who can obsessively optimize mature products to extract maximum value. Generally, there are different archetypes that can earn you the promotion but knowing the preferred archetype makes it easier for you to get it.

It’s like if a team signs Messi and makes him play the center back position. I’m sure he can still do fine but the team is not getting the most value out of him. Then when it’s viewed in vacuum (without context), it’d look like he’s just an average player. That’s you during performance review. Your package is generally reviewed in a vacuum without the context of “trying new stuff” or “expanding into new roles” (with the exception of joining a new team). Not playing to your strengths hurt both you and the team because the team didn’t get the most out of you, while you look like a worse engineer than your capability.

If the org’s preferred style is not something that matches your strength, you’d need to consider if putting in the extra work is worth it (maybe you enjoy the people + work enough), or if there are opportunities out there that suit you better. As mentioned before, what the org needs isn’t necessarily what it wants. You can make the case for it but it will take extra effort relative to the alternative. (That said, in many occasions, a successfully made case would allow for better job security as being the only / few people with such specialty.)

It’s not that you can’t be a good engineer if you don’t fit your company’s performance rubric but rather it’d require extra effort from either you or your manager (or both) to make your case. Some are one-offs (defining a new archetype), while others might be recurring (figuring out the right business reason to justify the time and effort on your projects). At some point, you might want to ask yourself if all these extra work is worth the time and effort.

There’s also another school of thought that view all these as unnecessary bloats in larger tech companies. I’m not here to argue for either (I know, not very opinionated 🫣) but to share what / how to get the most juice out of your work. Most people like this prefer to stick to startups where performance review processes aren’t as rigid. That’s valid too. At the end of the day, that’s just a different game with different rules. The key is knowing which game you’re playing and whether you want to keep playing it.