The Goose Is on the Team
You’re not falling behind on features. You’re starving the goose. P/PC — productivity vs. capability — explains every engineering org failure mode in one brutal parable.
"And the man, thinking he could get all the golden eggs at once, killed the goose. Of course, when he opened it, he found it empty."
— Aesop, being uncomfortably specific about your Q3 roadmap
Covey didn't invent the goose. He just gave engineers a framework for what they'd already watched happen in slow motion.
The parable is this: you have a goose that lays golden eggs. The eggs are P — Production, the output, the deliverable, the thing stakeholders put in slide decks. The goose is PC — Production Capability, the system, the team, the codebase, the relationship, the person that makes the output possible at all.
Kill the goose chasing eggs, and you don't get more eggs. You get none. You get an empty body and a very confused look on your face when the sprint velocity chart falls off a cliff.
The uncomfortable part? Most organizations don't kill the goose in one dramatic act. They just... stop feeding it. They stop noticing it's getting thinner. They act surprised when it stops laying.
I've watched this happen to people. To codebases. To products. To teams. Sometimes all four at once.
Here's what I've learned:
🪿 The Three Geese Nobody's Feeding
There's never just one goose at risk. There are three, and orgs neglect all of them simultaneously with impressive efficiency.
Your engineers 👷
The egg is throughput: features shipped, bugs fixed, tickets closed, velocity maintained.
The goose is the engineer: their skills, their energy, their sense of ownership, their ability to do the work next quarter and the one after that.
Personnel debt is what accumulates when you squeeze without investing. It's subtler than tech debt and more expensive. Tech debt shows up in your stack traces. Personnel debt shows up in your attrition reports, your Glassdoor reviews, and the soul-crushing Slack message that starts with "I wanted to let you know..."
I managed someone who'd been at the company for eight years. She'd been passed from team to team with lukewarm reviews and vague feedback. She got promoted to principal engineer — a title that demands technical mastery and leadership presence — by a manager who knew she wasn't ready, and did it anyway. Probably to make a problem disappear. It made the problem bigger.
No one had ever sat down with her and said: here's what this role requires, here's what I'm seeing, here's what needs to change. Not once in eight years. Just shuffled, promoted, and eventually handed to me.
I had to let her go. That was one of the harder conversations I've had. And the whole time I kept thinking: this is what accumulated silence looks like. No one killed the goose. They just never fed it, never checked on it, and then acted shocked when it stopped producing.
The egg is a lagging indicator. The goose is what you're actually managing.
Your codebase 🏚️
The egg is features. The goose is the system that lets you ship them.
You already know this one. We all do. We've all stood in front of a codebase that looks like an archaeological dig — layer upon layer of decisions made under pressure, documented nowhere, understood by one person who left in 2021.
Tech debt isn't a moral failing. It's a natural consequence of shipping under constraints. The problem isn't that it exists. The problem is when organizations treat it as optional, theoretical, or somebody else's problem to prioritize.
The goose gets slower. Deploys get scarier. Onboarding becomes a hazing ritual. Eventually you're spending more time working around the system than through it, and the features that used to take a sprint take a quarter.
The eggs don't stop overnight. They just get progressively smaller, harder to lay, and more expensive per unit until someone finally schedules the rewrite that takes two years and ships nothing.
Your users 🧑💻
The egg is satisfaction scores, retention, renewals, NPS, whatever your north star metric is.
The goose is the actual relationship with the user — understood needs, earned trust, feedback loops that work, an experience that respects the person using it.
I watched a PM spend weeks deep in the technical architecture of an AWS provisioning workflow — Terraform modules, third-party tooling, AI integrations. He was genuinely excited. He was drawing diagrams. He had opinions about the infra.
What he didn't have: a clear articulation of what the user actually needed. Minimum requirements. Edge cases. Anything that would tell the engineers building this thing whether they were solving the right problem. The engineers, to their credit, kept asking. He kept going deeper into the implementation instead of back to the user.
This is what it looks like when you're so focused on laying eggs that you forget the goose needs to eat first.
User research, discovery, feedback loops — those aren't pre-project overhead. They're what keeps the user relationship alive. The moment you start guessing at user needs instead of learning them, you're slowly starving the goose.
🪄 Authority Is Not a Production Capability
There's a fourth goose, and it's the one leaders are most reluctant to admit they're neglecting.
The egg: compliance, alignment, things getting done because you asked.
The goose: trust, respect, a team that actually wants to follow your lead.
Over-relying on authority — title, org chart position, decision rights — is a fast way to get short-term eggs and long-term nothing. People comply when they have to. They commit when they believe in you.
The leaders I've watched destroy teams fastest were rarely malicious. They were self-absorbed. Not sociopathically — just quietly, consistently prioritizing their own context, their own career optics, their own certainty over the growth of the people around them.
In other words: they were invested in their own production, not their team's production capability.
Teams where people invest in each other's success — where senior engineers pull people up, where managers create visibility for their reports, where PMs bring engineers into the discovery instead of handing them requirements — those teams compound. 📈 The goose keeps getting stronger.
Teams where everyone is quietly competing for credit, protecting their own lane, and waiting for someone else to lead: the goose goes hungry. Eventually it goes quiet.
🪡 The Part Where It Gets Personal
In 2025, my son finished second grade struggling to read.
He'd been struggling socially too — making friends, staying focused, keeping up. I was watching it. I was helping where I could. But between what I was seeing at home and what was being reported at school, the picture didn't quite add up. The school knew more than they were letting on, or maybe they just underestimated the severity. Either way, the signal I needed arrived late.
We finally got a real assessment. ADHD. Significant enough to require intervention, clear enough that it explained almost everything we'd been watching for a year.
Since then: a low dose of medication. Early intervention classes. Weekly tutoring. And more reading time together — just us, a book, no agenda. He's thriving now. Different kid, same kid, just finally being seen correctly. ❤️
Here's the thing that stays with me: if we'd understood the extent of it sooner, we would have moved sooner. The goose was struggling and the feedback loop was broken. The egg — grades, reports, test scores — looked bad but not alarming. The goose was having a much harder time than anyone told us.
That's partly why I stepped back from management when I did. Not because management is bad. Because I had a PC problem. I was shipping product at work and under-investing in something that mattered more. The eggs at work were fine. The goose at home needed me.
P/PC isn't just a corporate framework. It's a question you have to ask about every system you're responsible for — including the ones that don't show up on a roadmap.
The Goose Always Wins the Argument
Here's the thing about Covey's framing that engineering brains respond to: it's not a values argument. It's a systems argument.
You don't invest in your engineers because it's the right thing to do (though it is). You invest because personnel debt compounds faster than you think, and the payback period is brutal.
You don't invest in your codebase because clean code is virtuous (though it's nice). You invest because systems degrade in the direction of entropy when left alone, and recovery gets exponentially more expensive.
You don't invest in your users because empathy is important (though, duh). You invest because the relationship is the product, and when that relationship breaks, no amount of polish on the UI recovers it.
The goose isn't a resource. The goose is the whole game.
Stop optimizing for eggs. Feed the goose. 🪿
If this hit close to home, forward it to the person in your org who most needs to read it — or the one who definitely won't.