In my work on Perfetto, a performance debugging tool, one question I get often is: “how do I split a Perfetto trace into multiple files?” Instead of answering directly, I say: “there isn’t an easy way to do that, but what’s leading you to collect traces large enough to want to split?”

This is one of my golden rules at work. When a user asks me something “weird”: don’t answer the first version of the question.

On the surface this might appear like I’m talking about the XY problem, but that stops one step short. It treats the user’s stated question as a puzzle to decode: figure out what they really meant, answer that, move on. I think we can go much further.

Instead, the confusion that produced the wrong question is itself an opening, and the conversation it sparks is valuable to both sides. The user walks away with a better mental model of the tool. I walk away with a clearer picture of where the product confuses people. And sometimes, between us, we figure out that the product itself needs to change.

I’ve written before about how I can still be a successful engineer while avoiding the spotlight. While that covered the general strategy, this is one of the concrete tactics that makes it work. I should also say this post is aimed at people who build things for other engineers. If you’re building a consumer product, or a B2B service, it will translate less directly, but the underlying instinct might still be useful.

Diagnosing the ask

Some questions are easy, routine, and purely a matter of pointing at documentation; those don’t merit much discussion here. The interesting cases are where something is out of the ordinary, and it’s rare that the user will have given me enough information in their first ask¹.

So I run a mental checklist to figure out where to go next:

• Have I seen this before? If so, I might already have an answer to hand. If not, it’s uncommon enough that I want to slow down.
• Does the question even sound reasonable compared to others I’ve seen? If not, why might they be asking it, and is there a more normal question underneath?
• Does it fit the shape of the tool? Or is the user fighting the architecture without realizing it?

Once I’ve figured out what feels off, the next step is asking something that will surface the missing context. I might say something like “well the answer to your immediate question is X but that’s a pretty strange thing to ask for because of reason Y. Can you tell me more about the wider problem you’re trying to solve?”

This will probably be the start of a back and forth. How quickly it moves depends on how well the user can communicate their thoughts. But we’ll usually end up in one of a few places: they’re missing the philosophy of the tool, the product is hiding the right path or the product itself needs to change.

When they’re missing the philosophy

It’s quite common for users to come to us not knowing what they want, or not understanding the problem they’re trying to solve.

To be clear, I’m not criticizing them for this; teams are often trying to solve problems with limited time or resources, and they turn to new debugging tools when they’re struggling to make progress. As a result, they often find the tool, find it does most of what they want but doesn’t match their model of “how it should work”. So they file a feature request.

A common version of this: people come to Perfetto, see that a trace is a highly detailed recording of what a device did over a window of time, realize you can compute metrics from a Perfetto trace, and treat it as a holy grail solution to all their problems. Want a frame rate? Count frames in the trace. Memory used by an app? Look at the allocations and frees. In principle, any metric could be computed from a trace.

But this is a bad idea for a simple reason: traces are expensive to collect and process: you’re collecting all the data about the system rather than samply a single number. You’re going to waste a lot of resources when instead, a dedicated metric collection system would do the job much more efficiently².

My overarching point is that there’s a certain philosophy to how tools are designed, and users often miss it because they’re focused on their immediate problem.

A big part of my job is teaching the team how to approach performance engineering in the first place, not just explaining how to use Perfetto. It means making people aware of the tools they have available, how to think about things like startup, frame drops, memory, and power, and how to work with them both in normal situations and when something goes wrong.

Other times the team understands the problem; they just don’t see how to put existing tools together. Our tools are powerful by design, and we have to be mindful that other teams might not understand the full range of what we’ve built. It’s my job to figure out what they actually want. Often, something we built for a different purpose can be repurposed to meet their needs.

A perfect example here is what I already discussed: trace splitting. The conversation goes something like, “…what’s leading you to collect traces large enough to want to split?” They say it’s because they have periods of interest in a long trace and want to slice it up. Partly for performance, partly to make visualizing easier.

But then I point out that Perfetto already supports periodic trace snapshots, short repeated recordings instead of one long one, which removes the need to collect a long trace at all. They’re trying to solve a problem they shouldn’t be having in the first place.

It’s always satisfying to see people say “that’s exactly what I needed!” even though it’s not what they asked for. It means I successfully figured out what they actually wanted rather than what they thought they did.

When the product needs to change

Occasionally, the response reveals something genuinely new, something that could set us on the path to building something big. These cases are tricky: even when the ask is novel, the asker often can’t tell you what they actually need.

The cost of getting things wrong in foundational software is high, so I err on the side of not building something until not having it hurts: multiple teams have come to me saying “we want this.” Ideally by then we’ve found the essence of what’s actually worth building. This is very unlikely to happen after just one ask, so waiting is really powerful.

We’ve made this mistake at Perfetto. Take ad-hoc UI customization. People wanted to hack on the UI to suit their workflows, and they kept complaining about how hard that was. So we let them, and immediately took on a huge amount of technical debt. Every new feature had to interact with every existing one, and the whole thing quickly became impossible to scale.

It took us roughly one year to dig ourselves out of this hole by designing a proper plugin API. The real need, which no one could articulate up front, was a way to personalize the UI to the needs of their team or use case without affecting every other user. But of course no one was able to name this until it was too late. So it was our responsibility to spot this early as the requests flowed in.

Allowing folks to “merge” Perfetto traces was one we got right. People asked about it constantly, but we held off. We pointed people at workarounds and said “we’ll see.” We knew doing it properly was a lot of work and easy to get wrong, so we waited. We finally built it last year in a maintainable way, but only because we understood the problem space so well in the first place.

The point

The first version of a question is rarely the real one. Ask why before you answer. Sometimes the answer teaches the user how the tool is meant to be used. Sometimes it tells you the product is hiding the right path. Sometimes it tells you there’s nothing worth building yet. And sometimes it sets you up to build the next big thing once, not twice.

The technique is simple, but easy to skip because the pull to be responsive is constant, and every quick answer feels productive. Take the small step back anyway. Both sides almost always walk away with more than they came in with.