What kind of team do you have?

I have always worked in startups. Fast-moving, chaotic, figure-it-out-as-you-go startups. In that world, autonomous teams are not a preference — they are a survival mechanism. You cannot wait for someone to hand you a spec when the product changes every two weeks.

So when I joined a more established company, I did what I knew. I built an autonomous team. Engineers who could think end-to-end, challenge requirements, self-organize around problems. The kind of team I had built successfully three or four times before.

It was the wrong team.

Not a bad team. These were excellent engineers. But the environment was different. Stakeholders provided tasks, not goals. The team was treated as a service — requests came in, work went out. Goals were either unclear or changing so fast that long-term planning was pointless. Big projects were actively discouraged.

I kept trying to make the team autonomous in an organization that needed a task team. The company thrived. The team was frustrated. And it was only after I left that I could see clearly what had happened: I had built a team optimized for flexibility in an environment that needed efficiency.

That realization — that there are two fundamentally different team models, both valid, and the only mistake is misalignment — is what this post is about.

Two models

Over twenty years, across startups and scale-ups and everything in between, I have seen engineering teams that work well and engineering teams that don't. The ones that work are not always the most talented. They are the ones where the team model matches the environment.

There are two models. I am going to describe them as cleanly as I can, knowing that reality is messy and most teams sit somewhere in between. But the extremes are useful because they clarify the trade-off.

Model A: The task team.

A task team is a group of individual contributors with a coordinator. Work comes from outside the team — from stakeholders, product managers, or leadership — already broken down into tasks. The team executes, delivers, and moves to the next task.

Here is what I have observed in task teams over the years:

The team talks about tasks, not goals. Standups are about what is in progress, what is blocked, and what is next. The conversation is transactional: status updates, handoffs, deadlines.

Leadership communicates in terms of output. "Build this feature." "Fix this bug." "Deliver this by Friday." The team receives work and returns results.

Specialists thrive. The backend engineer does backend. The designer does design. The BI person does BI. They agree on interfaces and work independently. Deep collaboration is minimal — and that is not a problem, it is the design.

Juniors slot in easily. The work is well-defined, the expectations are clear, and a new hire can be productive quickly by picking up tasks from the queue.

It scales well. Adding people increases throughput roughly linearly because the coordination overhead is low. Each person has their lane.

It is fully remote-compatible. Communication is transactional, so it works fine over Slack and video calls. You do not need deep trust to hand someone a ticket.

It is efficient. Predictable output, measurable velocity, clean dashboards. Leadership loves it because it is legible.

But it is not flexible. When requirements change, the team stalls. When the work requires cross-functional thinking, the specialists struggle to collaborate. When someone needs to push back on a bad requirement, there is no mechanism for it — the requirement came from outside, and the team's job is to execute.

A task team crushes stable, well-defined work. It fails at delivering new projects, navigating ambiguity, or adapting when the ground shifts.

Model B: The autonomous team.

An autonomous team is a group that self-organizes around problems. Work does not arrive as tasks — it arrives as goals. "Reduce churn by 20%." "Improve the onboarding experience." "Figure out why customers are leaving after the trial." The team decides what to build and how.

Here is what I have observed in autonomous teams:

The team talks about problems, not tasks. Standups are about what was learned, what is uncertain, and what the team needs to unblock a decision. The conversation is about trade-offs, not status.

Leadership communicates in terms of outcomes. "Here is the problem. Here is the constraint. Figure out the best solution." The team owns the path from problem to delivery.

Generalists thrive, or at least specialists with generalist awareness (T shape). People do not need to be experts in every domain, but they need to understand enough about each other's work to anticipate needs, cover for each other, and collaborate without a coordinator. A backend engineer who understands the frontend implications of their API design. A designer who understands technical constraints.

Members challenge each other. This is not optional, it is the mechanism. If someone proposes a bad approach, the team catches it. If a requirement does not make sense, the team pushes back. This requires trust: the kind where you can say "I think this is wrong" and it lands as care, not criticism.

Juniors need a mentor. Unlike a task team, there is no well-defined queue to pick from. A junior in an autonomous team needs a senior to pair with — someone who helps them develop the judgment to navigate ambiguity. This creates a team-within-a-team dynamic.

It is harder to scale. Adding people increases coordination overhead exponentially. An autonomous team works best small, five to eight people. Beyond that, communication breaks down.

It requires investment in trust. This team cannot function over pure Slack. The members need to know each other well enough to assume good intent, give honest feedback, and argue productively. That trust takes time and, in my experience, requires some amount of in-person interaction to build.

It is flexible. When requirements change, the team adapts. When the market shifts, they pivot. When a new problem emerges, they can reorient without waiting for someone to rewrite the spec.

But it is not efficient, at least not in the ways organizations typically measure. Output is less predictable. Velocity is hard to track. The value the team produces is real but often invisible to dashboards.

An autonomous team wins when the environment is uncertain, when the work requires judgment, and when adaptability matters more than throughput. It struggles when the work is stable and well-defined, because the team's superpower is wasted on problems that do not need it.

How to tell which one you are running

There is a simple test. Walk into a standup. Listen for five minutes.

If people are talking about tickets, deadlines, and blockers — you are running Model A. The conversation is about what to do.

If people are talking about problems, trade-offs, and what they learned yesterday — you are running Model B. The conversation is about what to solve.

You can also listen to leadership. If the team receives tasks and delivers output — Model A. If the team receives goals and delivers outcomes — Model B.

Most teams think they are running Model B. Most teams are actually running Model A with aspirational branding. The standup does not lie.

The alignment problem

Neither model is wrong. The dysfunction comes from misalignment — saying you want one model but running the other.

I have seen it from both directions.

Companies that say "we want empowered, autonomous teams" but then assign tickets with detailed acceptance criteria and measure velocity by story points. They are running a task team with a motivational poster on the wall. Going to the office three days a week will not magically create autonomy. Neither will calling the standup a "sync."

And companies that go fully remote with a team that genuinely needs to collaborate deeply, to argue about architecture, to challenge product decisions, to build the kind of trust where honest feedback flows freely. Those teams slowly degrade. Not immediately. Not dramatically. But the trust erodes, and one day you notice that nobody pushes back anymore. People just agree in meetings and complain in DMs.

The question is not which model is better. The question is: what does your environment actually need? What does your team actually do? Are those aligned?

In a previous post, I defined a senior engineer as someone who discovers constraints, understands the why, and shapes what gets built. That kind of engineer can only thrive in Model B. Model A does not need it — it needs reliable executors. If you are hiring senior engineers and putting them in a task team, you are wasting their talent and guaranteeing their frustration.

And from the efficiency vs. flexibility framework: Model A is the efficiency end of the spectrum. Model B is the flexibility end. The same trade-off, applied to people instead of systems.

The natural evolution

There is a pattern I have seen in nearly every growing company.

Startups begin as Model B. They have to. The product is not defined, the market is unclear, and survival depends on the team's ability to figure things out fast. Everyone does everything. The engineer who wrote the backend also debugs the deployment. The designer talks directly to customers. There are no tickets because there is no process. The team is small, trust is high, and flexibility is the only competitive advantage.

Then the company finds product-market fit. The work becomes more defined. The chaos that was a feature becomes a bug. Leadership wants predictability. Stakeholders want timelines. The company starts hiring specialists, adding processes, creating ticket queues. Model A emerges, naturally, necessarily.

This transition is healthy. Not every problem needs an autonomous team. Scaling requires efficiency, and efficiency requires structure.

But it has human consequences. The generalist engineers who thrived in the early chaos become unhappy. The work feels boring. They start complaining, not because they are bad engineers, but because the environment no longer fits them. They were hired for Model B and now they are living in Model A.

Sometimes the right thing to do, for the company and for the engineer, is to let them go find an environment that fits. That is not a failure. That is alignment.

The mistake is not the transition from Model B to Model A. The mistake is not recognizing it is happening, and not being honest about what the team needs now versus what it needed six months ago.

Know what you have. Know what you need. Make sure they match. Everything else follows from that.