On building teams across functions

The skills that translate between audit, marketing, and product management are the opposite of what you'd expect. It's not about knowing your function. It's about understanding how other people's functions work.

The Audit Lens: Rigor and Documentation

Auditors ask: "What's the control? How do you know this is true?" This habit makes you dangerous in a cross-functional setting—in a good way. You don't accept handwaving.

When an engineer says "we'll handle that in the next sprint," you ask: "What does that mean operationally? Who owns it? When will it be done?" When a designer says "it'll be intuitive," you ask: "Have we tested it? What does intuitive mean to our users?"

This drives people crazy sometimes. But it also prevents projects from dissolving into ambiguity halfway through.

The Marketing Lens: Speed and Signal

Marketing taught me to move fast and read signals. Not everything needs a perfect plan. Some things just need a hypothesis and measurement.

When engineering says "we need three more weeks," marketing taught me to ask: "Can we ship a smaller version sooner and learn?" When design says "we need another round of polish," I learned to ask: "What signal would tell us if that's actually necessary?"

This prevents projects from getting stuck in perfection. It also prevents them from shipping broken things in the name of speed.

The Product Lens: Systems and Tradeoffs

Product management is about holding multiple truths at once. The engineer is right about the technical constraint. The designer is right about the user experience. The stakeholder is right about the business goal. They're all right. The question is: which constraint are we optimizing for?

This requires a kind of intellectual humility. You don't have the answer. You have access to better information than anyone else because you've talked to all the functions. That's your advantage.

What This Looks Like in Practice

At Zeon, I lead teams where I'm not the expert in any particular function. The engineers know engineering better than I do. The designers know design better than I do. But I'm the only person who can hold the entire system in mind.

This means I have to earn credibility. Engineers need to trust that I'm not making decisions to protect design. Designers need to trust that I'm not cutting corners to appease engineering. Stakeholders need to trust that I'm not losing sight of the business.

The way you earn that: you understand their constraints deeply enough to defend them even when they're inconvenient.

The Unreasonable Skill

The real skill isn't being smart about every function. It's knowing when to defer, and when to push back. It's asking the question nobody else is asking because everybody else is caught in their own expertise.

That comes from having lived in three different functions long enough to understand each one from the inside.