---
title: "People are package deals - by Steve Jobs and Terrible Software"
source: Ways of Working (JPH)
source_url: https://github.com/joelparkerhenderson/ways-of-working
licence: CC0-1.0
domain: operating-models
subdomain: jph-ways-of-working
date_added: 2026-04-25
---

# People are package deals - by Steve Jobs and Terrible Software

“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

The essay about this below is [Your Strengths Are Your Weaknesses](https://terriblesoftware.org/2025/03/31/your-strengths-are-your-weaknesses/)

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.
