Hey!

Welcome back to another week of musings.

I'm still in Tokyo, and writing from the hotel. Which is a cool sentence to write down. I've been living my dream of street photography.

I hope you had a great weekend and managed to rest for the week ahead!

Was this forwarded to you? You can subscribe here!

Things I discovered in the past week

• MCPs, CLIs, and skills: when to use what? It is a helpful piece. I like that it focuses on when each approach makes sense, instead of pretending there is a single right abstraction for every workflow.
• You Need to Rewrite Your CLI for AI Agents is worth your time if you build internal tools or developer platforms. It makes a strong case that agent-facing tooling needs different defaults, especially around structure, predictability, and machine-readable output.

I've been thinking lately, as companies grow, one of the easiest things to lose is a clear picture of the customer.

Not because people stop caring, but because of scale. We stop talking about someone's frustrating workflow, or the specific reason they gave up on our product, and start talking about funnel drop-offs, retention curves, DAUs, and engagement metrics.

Those numbers matter, of course. But they are proxies. We don't really know why they left at a given point in the flow, just that they did.

Proxy measures everywhere

I think this happens naturally as a company gets bigger and tries to serve a larger customer base.

The bigger the business gets, the harder it becomes to answer the question: who exactly are we building for right now?

Instead of one clear customer with one obvious problem, we now have segments, personas, markets, compliance requirements, regional needs, enterprise demands, self-serve users, and internal stakeholders all pulling in different directions.

So we simplify. We use numbers as a shared language.

We say a team should improve activation. Another should reduce churn. Another should increase weekly active usage. Another should fix a step in the funnel.

Still, none of this is wrong. But it gets dangerous when the proxy becomes the problem statement.

Developers feel this, too

This affects engineers just as much. Early on, developers might sit close to support tickets, implementation calls, or actual customer complaints. You can hear the pain directly. You know why something is broken, annoying, or too slow.

Later, your work starts arriving already translated.

The problem is no longer "customers cannot trust this workflow" or "teams are abandoning setup because it takes too long." Instead, it becomes "improve step-two conversion by 3%" or "increase 30-day retention."

That abstraction helps organizations coordinate. But it also creates distance.

It becomes much easier to optimize for engagement instead of usefulness, for retention instead of solved problems, for reducing funnel drops instead of asking whether the funnel itself reflects something customers actually want.

The overhead is real

I do not think this is just a failure of discipline.

At a certain size, planning overhead is real and unavoidable. Big companies need coordination not only across engineering teams, but also with legal, compliance, privacy, finance, marketing, content, translation, and globalization. A startup can often make a decision in a room and ship it that week. A larger company usually cannot.

That is partly why large organizations develop planning cycles, quarterly planning, half-year planning, annual planning, roadmaps, portfolio reviews, and all the supporting meetings required to keep everything moving in roughly the same direction.

I've read a couple of Pragmatic Engineer pieces lately, one on shipping projects at Big Tech and another on working at Amazon, and they reinforced this idea for me.

My read on them is that big companies do not avoid bureaucracy, they operationalize it.

They plan in cycles. They define ownership clearly. They build mechanisms for dependencies. They expect writing, reviews, and coordination. And in Amazon's case, at least from that account, teams can still have a lot of local autonomy even while operating inside a very large planning machine.

"Data-driven" can become a hiding place

What worries me is how easy it becomes to hide behind all of this and call it being data-driven.

We split the company into platform, mission-driven, and functionally oriented teams. We adopt scaled agile. We create sync meetings, alignment meetings, prioritization meetings, backlog reviews, cross-org planning, and steering committees.

Soon, a lot of the energy goes into managing the system around the work. We tell ourselves that abstraction is helping us scale customer value. It is just making the customer harder to see.

Staying close to the pain

I do not think the answer is "ignore metrics" or "stop planning."

The answer is to keep reconnecting the work to a real customer pain often enough that the proxies do not take over.

That might mean product managers regularly bringing support calls into the planning process. It might mean engineers occasionally joining customer interviews. It might mean leadership forcing every major initiative to explain, in plain language, whose problem is being solved and why it matters now.

If a team cannot explain the real pain behind a metric movement, I think that is a warning sign. Or if your team cannot connect to any feedback source, you have a different problem altogether.

You can scale the process. You can scale planning. You can scale reporting structures. But you should not distance yourself from the customers!

Your turn!

How does your company handle priorities as it grows? Are teams still close to real customers and direct feedback, or has the work mostly been translated into dashboards, funnels, and planning artifacts? Let me know by replying to this email!

Happy coding!