What Stayed the Same

After ten years of building companies, the technology changed, the teams changed, the scale changed, and my definition of success changed with them. The more interesting question is what survived all of it.

Overview

The easiest way to describe the last decade is through the companies. The harder and more useful way is to look at the decisions between them. Each venture changed something I believed about building: what it means to start before you are ready, how products reveal problems their founders cannot see, why tools can become leverage, and why scale eventually demands something no individual can provide alone. Looking back, I am less interested in the things that changed than in the principles that survived them.

Category:

Reflections

Published:

Jul 16, 2026

Updated:

Publisher:

Philip Cross

Reading

4 min

Series

Company

Updated:

Intoduction

Ten years is long enough to make almost every original assumption look slightly naive.

The technologies I started with are no longer the technologies I would choose today. Some of the products I once thought were important no longer exist. The companies became larger, smaller, combined with other companies, changed direction, or ended. The people changed too. So did I.

When I look back, it is tempting to organize the story around milestones. The first product. The first real customers. The acquisition. The IPO.

Those are useful markers. They are not what I remember.

What I remember are the moments when something I believed stopped being true. A customer using a product in a way we never anticipated — and revealing, in that single session, an assumption we had protected for months. A competitor becoming a more valuable partner than an opponent. A company becoming large enough that my own judgment was no longer sufficient to run it.

Those moments were usually more valuable than the moments when I was proven right. And yet, looking backward now, there are a few ideas that seem to have survived almost every one of them.

Start Before the Map Is Complete

Early in my career, I believed capability came before action. I wanted to understand the technology, then the market, then the business model, then the risks. Then, once I had accumulated enough understanding, I would be ready to build.

It sounds responsible. It is also an excellent way to delay difficult decisions.

The first major shift was realizing that some knowledge cannot be acquired before you start. A product can answer questions that research cannot. A customer can expose an assumption that a spreadsheet will never find. A prototype can reveal a constraint that becomes invisible when everything exists only as an idea.

Building does not eliminate uncertainty. It changes the kind of uncertainty you have.

I stopped expecting confidence to arrive before action. Instead, I started treating action as a way of producing confidence. That does not mean moving without thinking. It means recognizing that thinking and doing are not separate phases. They are part of the same loop.

The best decisions I made were rarely the ones I made with the most information. They were the ones where I knew enough to act, created something that could produce new information, and was willing to change my mind afterward.

That principle has survived every company since.

Let the Product Disagree With You

The second lesson took longer to learn.

Founders are very good at explaining why their ideas should work. That is part of the job. You need enough conviction to persuade employees to join, customers to try something new, and investors to believe the opportunity is real. But conviction becomes dangerous when it prevents you from noticing evidence that contradicts it.

Some of the most useful moments in my career came when customers did something we did not expect. They ignored the feature we thought was most important. They used something we considered secondary. They described the problem differently from the way we described it internally. Sometimes they wanted less. Sometimes they wanted something we had assumed was outside the product entirely.

The product does not care what you intended. Customers do not care what you meant to build. They respond to what is actually in front of them.

That taught me to treat unexpected behavior as information rather than resistance. The question stopped being: "How do we convince them that our original idea is right?" It became: "What are they seeing that we are not?"

That shift sounds small. It changes everything. A company becomes much more capable when it stops defending its assumptions and starts using reality to improve them.

Leverage Is Not Always More People

As the companies became more technical, another principle became increasingly important. Scale does not come only from adding resources. Sometimes it comes from finding the right abstraction.

I saw this most clearly while working around developer tools and infrastructure. A talented engineer can only do so much work individually. A good tool can multiply the output of thousands of engineers. A well-designed abstraction can turn something that previously required deep expertise into something almost invisible. If you make that work dramatically easier, your product becomes part of thousands of other products. The leverage compounds in ways that are difficult to see from the outside and impossible to ignore from within.

This changed how I thought about my own role as the companies grew. The founder's output matters less than the output of the systems they create. That can be uncomfortable. It means accepting that the most valuable thing you might build is something that no longer needs you.

But that is what leverage looks like. And it applies well beyond tooling. It applies to hiring, to culture, to decision-making. Every time you turn a judgment call into a principle someone else can use, you are compounding your own reach. Every time you make yourself the answer, you are limiting it.

What Scale Changes

The final lesson arrived slowly and then all at once.

At Acme, as the technology became more capable, the question stopped being how AI could improve our existing product. It became what products were now possible because the technology existed. That is a more disruptive question. It also creates a specific temptation: chasing capability for its own sake. A powerful technology does not automatically produce a useful product. The real work is turning capability into something people can depend on — which means designing for the moment it fails, not just the moment it succeeds.

The IPO made a parallel truth visible at the organizational level. Going public did not change what we were building. It changed the consequences of how we built it. Customers depended on us. Employees built careers around us. The organization needed to become more durable than any individual inside it.

That forced the same transition the tooling insight had implied years earlier. Founder intuition had been one of our greatest advantages. Preserving it at scale meant turning it into something other people could use without asking. The goal was no longer for people to ask what I would do. It was for them to understand enough about how we thought that they could make the decision themselves.

The larger a system becomes — a product, a company, a technology — the less it can depend on individual judgment. That is not a failure of leadership. It is what leadership is actually for.

Conclusion

After ten years, I am less certain about many things than I was when I started. That is probably a good sign.

I no longer believe there is one correct way to build a company. I do not believe the best technology always wins. I do not believe growth is always the right objective. I do not believe independence is always better than combination. I do not believe founders should make every important decision. And I certainly do not believe that feeling ready is a prerequisite for starting.

What I believe in has become simpler.

Build something real. Pay attention to what reality tells you. Change when the evidence demands it. Use technology for leverage, not novelty. Treat trust as something you have to earn. And when the company becomes larger than you, build it so that it no longer depends on you.

Those principles have survived changes in products, markets, technology, ownership, and scale. More importantly, they have survived being tested. That is the best definition I have for a principle worth keeping — not something that sounded right when you wrote it down, but something that remained useful after reality had several opportunities to prove it wrong.

The companies will change again. The tools will change again. The markets will change again.

My job is not to predict exactly what comes next. It is to remain capable of learning when it arrives.

That is the one thing I would still choose to keep. And after everything — that is enough.

Continue reading

The image shows a close-up of a sleek, modern jet engine turbine, highlighting the intricate blades and polished metal surfaces, set against a dark background, embodying advanced aerospace engineering.

Build Before You Know

The Product Wasn't the Business

What Stayed the Same

What Stayed the Same

Overview

Intoduction

Intoduction

Start Before the Map Is Complete

Let the Product Disagree With You

Leverage Is Not Always More People

What Scale Changes

Conclusion

Continue reading

Contact

Contact

Contact