Organize Around Missions, Allocate Around Opportunity

When everyone owns a step

Lately, I have been thinking a lot about team topologies.

With technology changing rapidly around us, it’s forcing me to reimagine how we structure teams to attack the work.

Say you’re a travel company with a few product managers and twenty engineers covering web, mobile, backend systems, AI, quality, and infrastructure. One logical way to organize everyone is by technical responsibility:

• Web and mobile applications

• AI and machine learning

• Internal tooling

• Platform

This brings similar expertise together and gives each team clear ownership. The org. chart looks sensible.

However, challenges arise when customer problems cross team boundaries.

Here’s an example: Your customer success team shares feedback that travelers are struggling to find available properties that match their dates and preferences.

To solve this, your AI team builds a personalization model. The internal tools team integrates it into your back-office suite for travel advisors. Your web and iOS teams expose personalized recommendations into the search experience. And your Platform team enables all three teams with data infrastructure and shared interfaces.

That’s a lot of handoffs. I’ve lived this pain personally, both as an IC and team manager. 😅

Each team already has a roadmap. Delivering the capability means finding room across several schedules and lining up dependencies. If the AI research takes longer than expected, the teams waiting on that work may move on to other commitments. Getting started again becomes its own coordination nightmare.

Everyone is working hard, but progress depends on priorities staying aligned across teams. Each owns part of the work, while responsibility for the full outcome is less clear.

Planning and dependency tracking help manage this coordination. But a well-orchestrated queue is still a queue.

Conventional wisdom

Conventional guidance suggests organizing teams around durable missions or business outcomes. You give a cross-functional team the capabilities and authority to own a problem from discovery through delivery and operation.

I agree with the reasoning. “Products Over Projects,” published on Martin Fowler’s site, describes long-lived teams attached to persistent business problems. AWS’s innovation-management guidance similarly advocates small, autonomous teams with clear ownership and adequate resources.

Keeping people together preserves knowledge that takes time to build. Teams learn about their customers, systems, and previous decisions, then carry that understanding from one approach to the next.

For the example travel company, the mission might be to increase nights booked per customer by helping travelers find relevant accommodations. The team could test recommendations, improve search, or change how travel advisors support customers. It remains accountable as its approach evolves.

That is a strong model. But when you’re a small company, permanently staffing missions is a bit impractical.

Startups require unconventional thinking

At a startup, every role represents a meaningful share of your capacity. You cannot fully staff every worthwhile opportunity, and keeping people assigned to one mission limits what you can pursue elsewhere.

With a fixed team and limited runway, I need to put our capital against the investments with the strongest case. That case changes as we learn. An experiment may reveal a larger opportunity, customer behavior may shift, or a new technology may change what is possible. As technology reshapes our markets, I expect us to revisit those decisions more frequently.

Our staffing model needs to support that. A mission can retain clear ownership while its membership and level of investment change. We can give a promising mission more capacity, reduce investment where the evidence is weaker, and preserve enough continuity to operate responsibly.

Fun fact: this assignment into another mission is sometimes referred to as a “safari.” 🦁

One person or several people join the team, participate in decisions, and share responsibility for its result. This gives us a practical way to concentrate effort where we see the greatest opportunity.

Making that investment also means deciding what receives less. Some missions should slow down or pause. Others should end because the need has been met or the investment is no longer justified. We need to make those decisions explicit, adjust commitments, and assign responsibility for any systems that still need support.

Moving people while leaving every deadline intact is wishful thinking. (Ask Ben).

These decisions become easier to act on when people can get established in unfamiliar work quickly. They need to understand the mission, its history, and the reasons behind its current priorities. I think context engineering gives us a practical way to make that knowledge more accessible and our staffing more agile.

Context engineering for the organization

In software development, context engineering helps agents find the instructions, architecture, conventions, and working state relevant to a task. An agent can start with shared project guidance and retrieve more specific information as it moves through the codebase. Anthropic’s discussion of context engineering describes this approach to selecting and maintaining relevant context.

We can apply the same architectural idea to people moving between missions.

In “Strategic Planning is Context Engineering, Part II,” I described building a company context layer with focused files, clear owners, decision records, and scheduled updates from business systems. That gave my AI workflows access to our actual strategy and operating context.

For mission teams, I would extend that structure across three levels:

• Company context: strategy, customers, market conditions, and current business performance.

• Mission context: outcomes, priorities, measures, research, experiments, and decisions.

• Working context: current progress, relevant systems, dependencies, and open questions.

A contributor can understand how the company is performing, why a mission matters, and where their work fits without asking five people to reconstruct the story.

I am experimenting with an agent for missions that helps maintain this record as the work happens. It draws on the mission’s tools and discussions, captures proposed decision updates, and answers questions using the relevant sources. People remain responsible for confirming decisions and resolving conflicting information.

Someone joining the mission could ask what has already been tried or why the team chose its current approach. Someone elsewhere in the company could ask what changed, what is blocked, or how the mission is performing.

This is useful well beyond onboarding. A surprising amount of organizational effort goes into answering versions of “Where are we at with that?” A maintained context layer with mission agents should service many of those requests, reduce interruptions, and make progress visible without another recurring meeting.

The information has to stay current and traceable. People still need experience and working relationships. But the time spent finding and reconstructing context is a cost we should actively work to reduce.

If we do that well, moving people becomes a more practical investment decision.

What this could look like

Return to the travel company. One mission team is working to increase nights booked per customer. Early experiments suggest that better personalization drives more reservations, and leadership decides the opportunity warrants more investment.

Two engineers move from a lower-priority initiative into the mission. Leadership explains the evidence, identifies which previous commitments will stop, and confirms responsibility for maintaining existing systems.

The team now has more capacity to test recommendations, build advisor controls, and improve the booking experience under one set of priorities. It measures whether the changes increase nights booked while monitoring cancellations and customer satisfaction.

If the evidence weakens, leadership can reduce the investment. If it strengthens, the company can commit more people. The same reasoning applies when another mission presents a more urgent problem or a better opportunity.

A promising idea gets a chance to earn more investment. It does not receive a permanent claim on the people assigned to it.

Clear ownership, accessible context, and a consistent operating system help these adjustments happen without requiring each incoming contributor to start from the beginning.

Operating with limited runway

With limited runway, I am responsible for putting our people’s time into the work that gives the company its best chance of succeeding. Leaving an assignment unchanged is also an investment decision, and it deserves the same scrutiny as moving someone.

Those decisions can be painful. 😖

People build relationships and care about seeing their work through. We owe them clear reasons, realistic expectations, and support when their assignment changes. We also owe them timely decisions about investments the business can no longer justify.

Organizing around missions gives us clear ownership of outcomes. Context engineering makes the knowledge behind those outcomes more accessible. Together, they give us a way to redirect people and effort as the business changes.

That is the organization I want to build: one that can learn something important and put people to work on it while the opportunity is still there.