How I Build.

01 - The ambition

Building a market.

Market Serving starts with a market that customers already understand. They know the problem, can compare competing products and have expectations about what a good solution should do. The work is to serve them better.

Market Making begins earlier, when the technology is taking shape and customers may not yet recognize the new possibilities. You have to develop a product while helping people understand the category, find the first applications and build the surrounding community of adopters and partners.

Both are necessary, and the evidence looks different. In a mature market, adoption and competitive performance tell you a lot. In a market you are making, outside-in validation matters: are developers building on the technology, are credible partners investing effort, are customers willing to experiment, and is a repeatable use case emerging?

At Outshift by Cisco, our incubation model separates Market Making from Market Scaling. We look for evidence that a new market is forming before asking the team to scale adoption, and we expect the work to graduate when it is ready. Incubation should change the odds of success, rather than become a permanent home for a project.

A market-making vision may be well ahead of what customers can adopt. That is our problem to solve, not theirs.

02 - The journey

Momentum is everything.

I like ambitious visions. I also believe in impactful incremental steps, each one helping customers move from the market they know toward the market we are trying to make. The destination can be radically different without requiring everyone to jump there at once.

Each step must earn its place. A developer should be able to try something useful, a customer should solve a real problem, and what we learn should make the next step easier. Momentum comes from those gains accumulating, including the mistakes we discover early enough to correct.

I have seen teams pour energy into an elegant architecture, then treat documentation, interoperability and integration as somebody else's responsibility. The developer using the interface, or the customer deploying the first capability, is doing some of the hardest work. We should be right there with them.

AI can now generate code, prototypes, designs and documents much faster and at far lower marginal cost. Building reliable products still takes engineering and judgment, but the balance of effort is shifting. We should spend more of it helping people integrate what we build, learn to use it and get results.

I care about output velocity, because slow production makes learning expensive. I care more about outcome velocity, because our customers' results tell us whether the work is going anywhere. Momentum comes when each adopted improvement makes the next one easier.

03 - The organization

An AI-native organization.

AI agents are changing what a small team can deliver. A few people can now take on work that once needed a much larger group. I like that change, but I have also seen what happens when teams accelerate independently: duplicated work, incompatible architectures and disagreements about decisions everyone thought were settled. Ten faster teams can create a surprisingly slow organization.

We are developing an AI-Native Operating Model around three things that have to evolve together.

T3s (Tiny Teams with Tokens) give small human teams an agent fleet and accountability for outcomes. We measure what the team delivers, not how many tokens it consumes.

TOME (The Organizational Memory Engine) holds the context those teams need: decisions, evidence, intent and authority. A proposal can circulate through a hundred chats and still be a proposal. The engine has to know what was actually decided and who has the authority to change it.

Coordination Leaders work across shared Objectives and Areas, resolving trade-offs, surfacing dependencies and keeping teams aligned on architecture and outcomes. They have to exercise judgment across boundaries without turning into another chain of task approvals.

A productive team needs context it can trust and someone accountable for coordination when priorities collide. Any one of these three components on its own leaves the problem unsolved.

I have written about parts of this in Your Teams Are Shrinking. The Coordination Surface Is Exploding and Your Collaboration Stack Is Not Your Organizational Knowledge.

04 - The responsibility

From managing execution to managing outcomes.

As agents take on more execution, leaders will spend more time deciding what work is worth doing, reconciling competing priorities and checking whether the result delivered what people needed. Those decisions were always part of leadership. AI makes them harder to delegate away.

I look for three qualities in leaders: judgment when the evidence is incomplete, influence when an outcome depends on people outside their reporting line, and accountability after the work has been delegated. An agent can execute a task; it cannot take responsibility for the business judgment behind it.

I want teams to have room to make decisions, with enough shared intent and clearly defined authority to move without waiting for permission at every step. That takes active coordination and trust.

05 - The practice

Make it real.

Four principles have stayed with me: feed your curiosity, act with urgency, embrace challenges, and make it real. Curiosity gives us more possibilities to pursue. Urgency forces us to test them. Difficult problems make us rethink our methods. And working systems have an irritating habit of exposing assumptions that sounded wonderful in a meeting.

I enjoy building prototypes and shipping products. I enjoy it even more when someone outside the team picks up the work and makes something useful with it. That can take months of collaboration after a launch.

That is the work I keep coming back to, whether we are making a new market or changing the way teams build: get a good idea into the hands of people who can use it, and stay with it long enough to see what happens.