Or why it doesn’t really matter how you got into this mess.

It’s easy for a product development group to point the finger at sales, product management, middle-management, and/or senior leadership and say “you got us into this mess!”

They’ll be right some high percentage of the time.

Why? In my experience, good product management/leadership is harder to find than suitable engineering chops. Product management is a force multiplier (for better or worse). Ideas to implement are cheap, and at least at first it is possible to build way faster than you can validate your assumptions. Product development — despite their protestations — is no match for the momentum of the org. Before you know it you’ve got a mountain of technical debt, a super broad offering that is expensive to maintain, and a bunch of disgruntled engineers (the ones that are left).

But here’s the problem: in the here and now, product development is likely optimized for the dysfunction. Meaning…you can “fix” the underlying issue (improve your product management chops, for example) and not fix the current issue. To further complicated things, those optimizations on the product development side tend to be way harder to unravel without causing significant disruption to the company. Examples include optimizing for busyness, rapid growth, high specialization, handoffs, individual vs. team focus, low quality, overtaxed shared teams, hero-culture, opacity, etc.

There’s also a deep human angle. On the prod dev side you’ll typically have folks who have “weathered the storm”, but there’s a good deal of accumulated bitterness, opacity, lack of trust, and dare I say general reticence. This survival mechanism becomes part of the challenge. We see here the stereotypical “difficult engineer”, who “isn’t a team player” and who is “dwelling on the past”.

I speak to plenty of engineers who are both 1) correct that the root cause was product (or sales, or _____), and 2) fail to see that they (and their leadership) are part of the problem now, if not the problem. They’re expecting a massive mea culpa (we are to blame, and we’re sorry) from the rest of the organization, and it will sadly never come. It’s a tough place to be in.

The whole thing burns down in a cycle of finger pointing. Sadly, it often takes a turnover in prod dev leadership/staff to “reset” and tackle the challenge anew with fresh eyes. It reminds me of the relationship that ends with a big

So why write about something so dire and seemingly inevitable? Because I think there is something product development can do about it…and that is to start, very early, to make visible the “costs” of the product management approach. For example: how has technical debt truly impacted the ability to get a feature through to production without significant rework and quality issues? How about the disruption caused by silver bullets? What % of throughput capacity (not resource capacity) currently going to maintain all of that product breadth? All of these questions are answerable without a lot of process overhead (and a good dose of psychological safety and focus on continuous improvement).

What tends to happen, to the contrary, is that as the pressure gets notched up…there’s increasing opacity as product development entrenches. Shadow work crops up. On go the gloves. It is “us vs. them”. I remember having a senior engineering leader request that the continuous improvement work NOT be put on “the board” for fear of it being micromanaged. There’s the work that product management sees, and then there’s this black box of other stuff.

So my thought for today is to what degree it is product development’s responsibility to shine a mirror back on the impact of a product strategy (or lack thereof). Is there a high ground? Does more transparency lead to great trust? Can a team act more safely on leading indicators when the system is being pushed too far?

And if you’re in the throes of coming to grips with the problem, what can the team do to “reset” and work to rebuild trust (if if they were technically “right” in the first place)?