Tiny Teams, Same Dependencies: Can AI Flatten Your Organization?

Your engineers or teams who are adopting an agentic software lifecycle see work compression.

If you look

at the typical structure of work... big initiatives that used to be split

into features that eventually were broken down into

stories that used to take days.

Now, with the assisted and especially agentic development, take

minutes or at most hours.

at this level,

it's not even worth

managing the way we've managed them before.

So it raises the question, do we even need to manage at this level, right? And one of the things that engineers complain about is that the current ways of working

whether it is a form of scrum or safe or team level kanban all of those feel wasteful and irrelevant

it sometimes feels like these engineers were just looking for an excuse to get rid of this prosthetic theater overhead that they're feeling.

So you look into best practices in organizing an AI-native product or engineering organization, and you show similar advice from McKinsey, Deloitte, Gartner, all the usual suspects that essentially boils down to the notion that instead of having the classic teams that you currently have with managers and a lot of structure, instead of that, what they're saying is you can move to tiny teams.

Tiny teams

that are assisted by and there's a certain attractiveness

to these teams.

If indeed you can take, you know, what used to take 10 to 12 people and do it now with two to three people

plus tokens,

that, you know, that's nice, right? You

now don't need the coordination mechanisms that you had between teams in the past, right? We used to have teams and a lot of scaling structure that connected the work of these different teams.

But if everything can be done by this notion of tiny teams and you don't need any of that structure, that's very attractive.

You don't need as many of the people that were focused on doing this.

And you don't need a lot of the events,

artifacts.

Your engineers or teams who are adopting an agentic software lifecycle see work compression.

If you look

at the typical structure of work... big initiatives that used to be split

into features that eventually were broken down into

stories that used to take days.

Now, with the assisted and especially agentic development, take

minutes or at most hours.

at this level,

it's not even worth

managing the way we've managed them before.

So it raises the question, do we even need to manage at this level, right? And one of the things that engineers complain about is that the current ways of working

whether it is a form of scrum or safe or team level kanban all of those feel wasteful and irrelevant

it sometimes feels like these engineers were just looking for an excuse to get rid of this prosthetic theater overhead that they're feeling.

So you look into best practices in organizing an AI-native product or engineering organization, and you show similar advice from McKinsey, Deloitte, Gartner, all the usual suspects that essentially boils down to the notion that instead of having the classic teams that you currently have with managers and a lot of structure, instead of that, what they're saying is you can move to tiny teams.

Tiny teams

that are assisted by and there's a certain attractiveness

to these teams.

If indeed you can take, you know, what used to take 10 to 12 people and do it now with two to three people

plus tokens,

that, you know, that's nice, right? You

now don't need the coordination mechanisms that you had between teams in the past, right? We used to have teams and a lot of scaling structure that connected the work of these different teams.

But if everything can be done by this notion of tiny teams and you don't need any of that structure, that's very attractive.

You don't need as many of the people that were focused on doing this.

And you don't need a lot of the events,

artifacts.