Beware of The Proxy Problem

A high-impact technical program manager delivers outcomes, not programs.

(4 minute read)

👋 Hey TPM Crafters, let’s get crafting.

This newsletter edition is focused on the Leadership and Program Management.

What’s inside?

👨‍🏫 Learn: The Proxy Problem (look out!)
🤝 People: Aadil Maan, TPM @ Airbnb (a fellow TPM writer!)
đź“š Resource: The Art of Technical Program Management (a fantastic newsletter that frankly publishes more frequently than this one!)

Let’s get to it! 👇

Learn

👨‍🏫 The Proxy Problem

A high-impact technical program manager delivers outcomes, not programs.

Delivering on outcomes is trickier than it seems, though, because every company can accidentally incentivize their employees to focus on the wrong measures of success.

This is commonly called the proxy problem.

The proxy problem happens when you mistake an intermediate milestone for the actual outcome. It’s easy to do. Trust me, I’ve fallen victim to it several times in an effort to secure a win for my resume. This is especially true in engineering and product teams, where we’re all semi-incentivized to claim wins that look good in a sprint review but don’t translate into real impact.

Proxies aren’t inherently bad.

They help track progress, gauge buy-in, and measure engagement. But they’re a means to an end, not the end itself.

Let’s take a look at 3 examples from various points in my 10 year career as a engineer and program manager.

Proxy Problem 1: The Perfect Plan

I had just polished the perfect implementation plan. Or so I thought.

Every workstream was mapped out. Dependencies were accounted for. Teams knew exactly when and what they needed to deliver. Risks? Documented.

By all accounts, this was a rock-solid plan on paper.

It was early in my role as a technical lead for an API engineering team, and I was confident. Maybe too confident.

Then reality hit.

My manager praised my work. The plan looked airtight. But when it came time to execute, things didn’t unfold as expected.

Despite how well-structured the plan was, it didn’t translate into the outcomes I had envisioned. Everything was supposed to fit together like a 1,000-piece puzzle, and it did! On paper. But in practice? It didn’t matter.

What went wrong?

I suspect the proxy problem had something to do with it.

  • Proxy: A well-structured plan can feel like success. But a plan is just a tool. It doesn’t mean execution will go smoothly. As a TPM, I love a good looking plan! It makes me feel warm and fuzzy inside. Being aware of this personal love for plans is something I consistently have to beware of.

  • Outcome: The real goal was to reduce the time spent on quarterly planning while boosting engineering velocity. A true measure of success would have been seeing a measurable drop in planning hours and a corresponding increase in delivery speed.

Story 2: The False Comfort of Ticket Closure

Our cross-functional team had closed 75% of the Jira tickets for a project. That’s a solid number! We felt good. We had tangible progress to point to.

But that number didn’t tell the full story.

The remaining 25%? Those were the hardest, most complex parts of the project. The ones that actually determined success. We hadn’t secured a total victory yet and our team habits that helped us reach 75% were insufficient to help us accomplish the final 25%.

The project eventually stalled out and was deprioritized.

As a Technical Program Manager, this was a hard pill to swallow. It definitely brought my ego down to earth and gave me a good reason to reexamine my general approach to the TPM craft.

What happened?

The proxy problem strikes again!

  • Proxy: A high percentage of closed tickets feels like progress. But it’s just a number. It doesn’t represent outcomes.

  • Outcome: The real goal was achieving a new level of compliance certification. It was a binary result. The only metric that mattered was whether we passed, everything else was noise. But we never got to that point because of deprioritization.

Story 3: The Illusion of a Launched Product

Then there was the time we raced to ship API endpoints that had been deemed urgent by multiple teams.

We snapped to it, built what they asked for, and rolled it out to production. We all felt a rush of pride sending out the launch announcement.

Then…crickets.

But in the weeks that followed, nobody adopted those APIs. The “critical blockers” we had solved? Apparently, they weren’t blockers at all. The teams were just really noisy about the problem but eventually found a local solution.

Eventually, we shut the endpoints down. A complete waste.

Again…what happened?

You know. The proxy problem.

  • Proxy: Shipping to production. It felt good. It’s real work, but it doesn’t guarantee adoption. In this case, we were so focused on shipping quickly, that we failed to ensure the features actually solved problems.

  • Outcome: Success would have meant solving an actual pain point for internal teams. Adoption, usage, and problem resolution (not just deployment) should have been the true measures. You live and learn. Luckily the cost of this failure was relatively low.

Recap

Each of these scenarios had one thing in common: we weren’t measuring success. We were measuring a proxy for success.

Don’t get me wrong…

  • Creating plans is a good thing.

  • Tracking progress with tickets is a good thing.

  • Shipping to production is a good thing.

But when those good things become the thing, then your focus on outcomes is lost. The proxy problem has struck again.

It’s tempting to celebrate the proxies (plans, ticket closures, deployments) because they’re visible, quantifiable, and easy to track. But real success comes from solving the problem you set out to solve.

So, take time to celebrate those small wins, but don’t declare total victory quite yet. Stay focused on the outcomes.

Before you pat yourself on the back, ask yourself: Am I making progress, or just tracking something that looks like progress?

People

🤝 Aadil Maan, Staff TPM @ Airbnb

I want to take a moment here to give a shout-out to a fellow TPM and writer: Aadil Maan. Aadil has been at the writing game a bit longer than myself. His substack was one of the original inspirations for me to jump into the world of writing on the topic of Technical Program Management.

Keep up the good writing Aadil, you’re crushing it.

Resources

đź“š The Art of Doing Technical Program Management

Speaking of Aadil…he’s got a substack newsletter dedicated to Technical Program Managers! He’s garnered a whopping 5k subscribers and keeps churning out some high quality content.

I particularly enjoyed one of his latest posts to his subscribers: 30-60-90 For TPMs. Check it out!