“People are package deals; you take the good with the confused. In most cases, strengths and weaknesses are two sides of the same coin.” — Steve Jobs
I’ve noticed something interesting about almost every engineer I’ve managed: their biggest strengths and their most frustrating weaknesses are often the exact same trait showing up in different contexts.
I learned this lesson personally when I was still a junior engineer. My ability to code quickly made me very productive — I’d often ship features in half the time estimated. My manager praised my speed constantly.
Well, until one day… During a particularly painful postmortem, we discovered that a production issue happened because of an edge case I had missed in my rush to complete the feature. My strength (coding speed) and my weakness (occasionally overlooking details) weren’t separate traits — they were the exact same characteristic showing up differently depending on the context.
This isn’t just true for me or a few people — it’s nearly universal. The qualities we celebrate in our team members are usually the same ones causing our biggest headaches. They’re not separate traits; they’re two sides of the same coin.
So what can we do about this? Three things have helped me:
- Get real about this duality in your 1:1s. Most people see their strengths and weaknesses as separate things. They’re not. In 1:1s, I’ll say something like: “Your ability to dive deep into problems is why you find solutions nobody else can. It’s also why you sometimes miss deadlines. Same trait, different outcomes.” This simple reframing helps people stop beating themselves up over their “flaws.”
- Be crystal clear about context. Don’t make people guess when their natural tendencies help versus hurt. One of my engineers was incredibly collaborative—wouldn’t make a single decision without getting everyone’s input. I told him exactly when this worked and when it didn’t: “For architecture decisions? Get all the input you want. For day-to-day coding decisions? You have permission to just decide and move on.” This clear guidance helped him develop his own judgment about when to lean into his collaborative nature.
- Use tension as a feature, not a bug. Some managers try to build teams where everyone works the same way. That’s a mistake. I once paired our fastest coder with our most methodical, thorough reviewer. The first week was pure chaos—they drove each other nuts. By the third week, they were producing better code than either could alone; the fast coder started anticipating the thorough one’s concerns, and the methodical one learned which shortcuts were actually okay to take.
The goal isn’t to create “balanced” engineers with no pronounced strengths or weaknesses. That’s just impossible. We want self-aware engineers who understand their natural tendencies and can adjust them based on what each situation demands.
I don’t think our job is to sand down people’s edges until everyone’s the same boring shape. We’re not trying to “fix” our engineers. Instead, we’re helping them see themselves clearly, warts and all, and teaching them when to crank up or dial back their natural tendencies. It’s more like coaching someone to use their power effectively than trying to rebuild them from scratch.
After all, we’re all package deals. The traits that make us brilliant will inevitably challenge us in other contexts. Understanding this doesn’t just make us better managers — it makes us more compassionate humans.