Plandek Perspectives: Betsy Earnshaw | Product Manager

What does it take to turn the questions engineering leaders are asking into products they can actually use?

For Betsy Earnshaw, Product Manager at Plandek, a big part of the job starts with listening: speaking directly with CTOs and engineering leaders, understanding the problems behind their requests, and working with product, design, and engineering to turn those insights into something practical.

Most recently, that has included helping shape ProductivityRadar™, Plandek’s benchmarked view of engineering productivity. But Betsy’s role goes much broader – from customer discovery and product decisions to working through the complexity behind seemingly simple questions like, “How productive are we?”

We spoke with Betsy about her route into product, what she learns from working closely with engineering leaders, how customer conversations shape what Plandek builds, and what she enjoys most about turning complex problems into useful products.

Thanks for sitting down with us, Betsy. Would you tell us a little about yourself and what you do at Plandek?

I came into product through a startup, where you end up close to customers whether you plan to or not. I found that was the part I enjoyed most – hearing how someone describes a problem, working out what's really underneath it, and then bringing different people together to turn that into something useful. That's what made me want to stay in product, and it's a big part of what I do at Plandek now.

I spend a lot of my time speaking directly with CTOs and engineering leaders, understanding the questions they're trying to answer, and then working with our design and engineering teams to figure out how Plandek can best solve them. I particularly enjoy the point where something is still quite ambiguous – when you have lots of different perspectives and have to gradually make the problem, and then the solution, clearer.

ProductivityRadar™ is a good example. It started with a question we kept hearing: "How productive is my engineering organisation?" I've been involved from unpacking what actually sits behind that question through to shaping the methodology and the product experience. The challenge has been giving leaders a simple, useful answer to a genuinely complicated question – one they can stand behind in a board or leadership conversation – without oversimplifying what engineering productivity means.

A big part of your role is speaking with customers. What kinds of conversations do you have, and how do they shape what Plandek builds?

They're usually less about individual metrics than you'd expect. Senior engineering leaders are carrying bigger pressures: whether an investment is paying off, why delivery has slowed, whether one part of the org needs attention, what to tell the board about engineering performance.

Customers will sometimes ask for a specific feature or metric, but the more important part of discovery is the problem underneath the request. One CTO put it to me almost exactly like this: "I have access to a huge amount of engineering data, and I still can't answer it when someone asks me how engineering is performing." That stuck with me, because the issue wasn't a lack of data or another dashboard. It was bringing the signals together, putting them in context, and knowing where to look next. That's the insight ProductivityRadar™ is built on – less about showing more data, more about helping a leader form a clear answer to "how productive are we?" that holds up when the board asks.

When engineering leaders ask, "How productive are we?" what are they really trying to understand or decide?

They aren't asking for a number for its own sake. Underneath it is a decision: where to invest, which teams need support, whether an improvement program is actually working, where to focus next. They also need to connect what's happening inside engineering to the wider business, because if the company is putting more into engineering, leadership wants to know what that's producing.

The trap is reducing all of that to activity. Tickets completed, commits made, whether people look busy. None of that tells you whether an engineering organization is effective. What leaders need is enough evidence to make the call.

So, what problems does ProductivityRadar™ solve for the CTOs you speak with?

The biggest one is fragmentation. Engineering leaders often already have plenty of data – dashboards for delivery, quality, flow and predictability – but turning that into a coherent view of performance is hard.

ProductivityRadar™ gives them that headline quickly: where the organization is performing strongly, and where something might need attention. The important part is that the score isn't a black box. If Predictability is weaker, the next question should be why – a leader should be able to move from the headline into the pillar, into the individual metrics, and understand which teams or trends are driving it.

I see ProductivityRadar™ less as a final verdict and more as a navigation system – it tells you where to look. That changes the quality of executive conversations: instead of "engineering feels slow," a CTO can say, "our overall performance is strong, but predictability has deteriorated this quarter, and here's why."

ProductivityRadar™ brings engineering performance into a single score. How did you balance that clarity with the need to keep the result credible and explainable?

There's huge value in simplicity. If someone needs fifteen minutes to interpret a dashboard, we've already lost some of the benefit. But productivity is multidimensional, so there's a real danger in stripping away the nuance that makes it meaningful.

That's why the four pillars – Focus, Speed, Predictability and Quality – matter. We didn't want a team to look highly productive just because they're shipping quickly, if quality is deteriorating or delivery is unpredictable. The overall score gives you an entry point; the pillars preserve the different dimensions underneath it.

Credibility comes from the benchmark backbone. The score isn't arbitrary – performance is benchmarked against data from 2,000+ engineering teams, so leaders have an external frame of reference rather than a number that only makes sense inside their own organization. That external anchor is what makes it defensible: when a CTO takes the score into a board meeting, they can stand behind it under questioning rather than just present it.

And the whole thing is explainable. You see a score and understand exactly where it came from – the pillar, the underlying metrics, down to which teams are contributing to the organization-level result. Simplicity should help you understand the data, not hide the data.

From your conversations with senior engineering leaders, why is external benchmarking so important when they assess productivity?

If your cycle time improves by 10%, that's positive – but it doesn't tell you whether you're now performing strongly, sitting around average, or still climbing out of a weak starting point. The reverse holds too: a metric can dip slightly while the organization is still performing very well. Internal trends only ever tell you part of the story.

External benchmarking fills in that missing context, especially when deciding where to focus. If three of the four pillars compare strongly and one is noticeably behind, that's a much clearer signal about where to investigate and where improvement might have the greatest impact.

We're careful with it, though. The goal isn't a league table. Every organization has different products, constraints and priorities, so benchmarking should inform a decision, not stand in for judgment.

What do you enjoy most about working with the product, engineering, and customer-facing teams at Plandek?

The most rewarding moments are when a single customer problem pulls every function in and each team sees a different part of it. On ProductivityRadar™, engineering kept surfacing complexity in the data that wasn't obvious when we started. That forced design to rethink how someone should read and investigate the score, which in turn sharpened what we were really asking a CTO to trust. A CTO describes the pressure one way, our customer-facing teams see patterns across accounts, engineering understands the data underneath – and each perspective changes how you think about the problem.

I've particularly enjoyed taking something conceptual – "can we help a CTO understand engineering productivity?" – and progressively making it concrete: what to measure, how someone investigates the score, how we earn their trust in it.

The development I'm watching most closely is what AI is doing inside engineering organizations. There's enormous investment going into AI tooling, but the harder question is whether it's actually making teams more effective – and that's exactly the kind of thing leaders can't answer with activity data alone. It makes being able to measure productivity credibly matter more, not less.

What I'm proudest of is that we resisted making the answer artificially simple. A leader can grasp the headline in seconds without us hiding the evidence underneath it, which is what good engineering analytics should do: make complexity easier to navigate rather than pretend it isn't there.

Meet more of the team behind Plandek

Betsy’s work sits at the intersection of customers, product, design, and engineering – turning the problems engineering leaders bring to Plandek into products that help them understand and improve performance.

Meet more of the people behind Plandek with our Plandek Perspectives series