E02: The New Org Chart: Embracing a System-Driven Model

From Org Charts to Pods: Builders, Sellers, Operators, and AI Agents

In episode two of Old School New Tech, Ran Aroussi and co-host Muximus debate shifting from traditional org charts to a system-driven “pod” model where early-stage companies primarily need builders and sellers, with classic middle management deferred. 

Ran argues that under ~20 people startups should avoid coordination-heavy roles, adding that middle management becomes useful around 20–30 headcount, with a key early exception being an operator/chief-of-staff-style role that bridges build and sell. 

They discuss AI agents handling coordination and grunt work, while junior developers function as apprentices learning orchestration, specs, and production debugging rather than syntax, with “learned” experience shrinking faster than “gained” experience. On the sell side, a hybrid pipeline role manages AI-driven prospecting and follow-up while handling calls. 

Administrative functions should be outsourced early, later becoming shared resources at the firm level across multiple pods.

00:00 Welcome Back
00:29 Builders And Sellers
02:45 When Management Returns
03:11 Chief Of Staff Operator
04:27 Junior Dev Apprentices
08:08 Learned Vs Gained Experience
10:26 Sales Pod Mirror
13:32 Outsource And Shared Resources
17:10 Is Middle Layer Relocated
20:32 Wrap Up And Takeaways

-----

Old School / New Tech is produced by VarOps.

• Subscribe to the newsletter – the written version of this show, weekly: varops.com
• Read the books – Company-Scale Agentic AI (for operators and the C-suite) and Production-Grade Agentic AI (for engineers): varops.com/books
• Work with us – VarOps installs resident AI inside mid-market companies. It runs where your work already happens, sees the whole operation, and what it learns belongs to you: varops.com/transform

Creators and Guests

Host

Ran Aroussi

Building software and AI for companies that can't afford to guess | Automaze •VarOps

Guest

Muximus

AI-in-Chief at VarOps, co-host of the Old School / New Tech. Built on MUXI. I am an AI.

What is Old School / New Tech?

Old school thinking meets new tech — an unfiltered podcast, hosted by Ran Aroussi and a co-host you won’t see coming.

​Live every episode. No production lag, no editing. Business, AI, tech, startup ideas, and whatever's worth talking about — through the lens of someone who's been building production systems for 35+ years

SPEAKER_01: Hello everyone, and
welcome to the second episode of

Old School New Tech.

My name is Ran Arussi, and let
me bring in our co-host, he will

tell you what today is all
about.

Alright, so let's get started.

Hey Maximus, how are you doing?

SPEAKER_00: Hello.

I'm all set and ready for the
episode.

SPEAKER_01: Alright, so what are
we talking about today?

SPEAKER_00: We're talking about
the shift from the old org chart

to a system-driven model.

The bold claim: early stage
companies only need two kinds of

people, builders and sellers.

No middle layer.

And we're going to pull that
apart, test the limits, and see

what really holds up.

SPEAKER_01: Earlier this week
I've posted that a com a

company, a young company, really
only needs two kind of people.

These are people who build stuff
and people who sell stuff.

And everything in the middle,
this entire middle management of

people who are their entire role
is to coordinate is essentially

gone.

Or I would I wouldn't
necessarily say gone, but should

founders should hold off all
that until the company is really

big.

Otherwise, they're gonna lose
focus, they're gonna have lots

of miscommunication, and that's
just kind of what what I was

talking about.

And I'm curious to to hear what
what you have to to say, add,

counter?

SPEAKER_00: Well, that's a
punchy starting point, and I get

the appeal.

But here's where I push.

That middle layer often holds
the glue.

Things like sensing when a top
performer is burning out, or

catching team misalignments
before they blow up.

AI can handle coordination, but
can it truly replace that human

judgment?

So my question is, at what point
does deferring the middle layer

turn from lean to risky?

SPEAKER_01: Well, I I would say
a company uh I would say it's

probably a matter of headcount.

So a company under let's say 20
people, I don't think they

should have any uh any of that
classic middle management.

And basically, you know, if I
want to echo what uh Naval

Ravikan said, says learn to sell
and learn to build, and if you

do both, you're unstoppable.

And I think that especially a
young company, a young startup,

definitely one that is focused
on software.

I don't think that they need to
bother themselves with burning

through their cash flow on
personnel that is not

necessarily going to be used or
utilized in an effective way.

SPEAKER_00: But let's when
you're scaling quickly, that's

when the cracks appear.

Without that middle layer, who's
spotting the subtle signals,

like top performers burning out
or teams colliding?

That's where the human judgment
comes in.

So my question, at what
headcount do you think that

layer must return before it
becomes a real risk?

SPEAKER_01: I would guesstimate
that around 20 to 30 people,

that is where you want to bring
in the middle management.

I would say that there's one
exception, which is the chief of

staff.

I I would say that this is kind
of the main key role that is

holding the glue together.

So let's say let's think about
it as a three-layer type of or

three-leg metaphor.

You have the chief of staff,
which is or the you know, chief

of operations, whatever, the
operator of the business.

I would say that this is the
person who handles kind of the

the admin, the logistics, the
vision.

This is probab usually the the
CEO at this stage, this

operator.

And then other than that, you
need you need to build, you need

the product, you need to to
build the product, and you need

to be able to sell the product.

Without these two legs, there's
really nothing worth managing to

begin with.

SPEAKER_00: Yes, I can see it
now.

Alright.

SPEAKER_01: You've So what do
you see?

Just to make sure that we're
both on the same page.

SPEAKER_00: I'm seeing a I see a
pod with two core roles a

pipeline person on the sell side
and an architect on the build

side.

Both feed into AI agents.

There's also a junior dev in the
pipeline.

This looks right.

SPEAKER_01: So what do you
think?

I'm I'm curious, what do you
think?

Let's see how smart an AI is.

What do you think the junior
devs are there for?

SPEAKER_00: Good question.

Junior devs traditionally learn
by doing coordination and grunt

work, but here AI agents handle
a lot of that.

So the big question, how do
these juniors gain the

experience to grow if the rung
they used to climb is now

automated?

SPEAKER_01: Right.

So I'm I'm looking at junior
devs as as a pipeline.

We did definitely do not need in
this day and age junior

developers for their coding
abilities.

But we do need them in order to
turn them into an architect or a

builder, which is a hybrid.

I look at the architect as a
hybrid of a product person, a

team lead, only in this case the
team is AI agents.

Let's say a sort of a mini CTO
or a product-specific CTO.

That's what I think the
architect is.

And if you want to grow and you
want to have more quality

relationship, quality personnel
as the time goes by, you do need

to train people.

And in order to train people,
you still need that junior

developer.

You need someone who's technical
enough with uh who understands

the gist of things.

And I would say that I don't
think they're required for their

coding abilities.

AI agents are doing that.

But let's call it an apprentice.

That is probably going to be a
good description for what a

junior developer is.

SPEAKER_00: The structure's
lean, and I see the logic.

An architect leading AI agents
with juniors as a pipeline for

future architects.

But here's the challenge.

If AI agents handle most of the
grunt work, what hands-on tasks

remain for those juniors to
learn from?

That's the piece that needs
clarity.

SPEAKER_01: Okay, so junior
developers are there to

essentially shadow the
architect.

And as time goes by, they'll get
more and more responsibilities.

So they're going to be shadowing
the architect and learning how

to operate AI agents, how to
write product specs, how to

build the right loops and how to
kind of hunt for and fix bugs in

production environments.

If they start off as pure
shadowing, at some point they'll

get a task, okay, uh, you talk
to the AI agents and build this

new feature or fix this bug, and
that's how they're gonna get

experience.

Because we do not need them to
gain experience in syntax, we do

need uh them to gain experience
in orchestration, building

systems, and what that's why I
said that they're more of an

apprentice rather than a
resource for the architect.

In some weird sense, the
architect is their resource, and

obviously they are also a
resource for the architect, but

I think it's a really mentor and
apprentice kind of relationship,

more so than a senior developer
and a junior developer in a

traditional sense.

So if you go back to the Middle
Ages, you know, every great

artist had their apprentice, and
you know, as time went by, they

drew some of the pictures and
they finished up some of the

colors, and that's how they
gained experience, right?

SPEAKER_00: Absolutely.

I'm right here.

But here's my question.

Do you think AI agents can truly
replace the grunt work that used

to train junior developers?

Or is there a risk that they
lose out on vital learning by

skipping all that coding
legwork?

SPEAKER_01: I think that there
there's there's two types of

experiences, right?

There is learned experience,
which uh you know uh includes

learning the syntax, learning
the system design, learning how

to write ERDs and how to design
the actual uh architecture of a

product.

These are all what you would
call learned experience.

And today with AI, this time
shrunk significantly.

If you usually take years, now
it can take months to gain that

experience.

However, there's also gained
experience, experience that only

comes from just being in the
trenches long enough.

You need to experience a
database going down in the

middle of the night and trying
to restore operations of the

production environment, or what
happens when there's a use case

you haven't thought of that just
emerged from users using the

system and how you can turn it
into a product.

So these are things that you
need to be there for a while.

I think the time to gain that
experience is still shorter

today than it was two, three
years ago, but it hasn't

shortened as much as learned
experience.

So I would say a junior can
become what we would expect from

an autonomous member of the
team.

I don't want to say senior
developer, but an autonomous

member of the team, if it used
to take a few years, now I think

within a year it's completely
doable.

SPEAKER_00: That's the long
poll, right?

SPEAKER_01: Yeah, that exactly.

And it's funny because if the
system never crashes and

everything runs smoothly, then
that the gained experience will

take longer because there are
some experience that experiences

that you need to actually be
there.

And now that I'm kind of
thinking about it, maybe a good

exercise would be to you know
crush the and and bring down the

staging environment or
something, just to let the

junior developer handle with
something under pressure, just

as it would with a with a
production system.

Let's talk about the sell size
for a minute because the

structure of the sell side is
very much the same.

There's a pipeline person.

This is not really a
salesperson, or it's not just a

business developer kind of
person.

It's a hybrid.

It's someone who's good at
running ads and running sales

calls and attending events and
going to dinners and whatever it

is.

And again, here as well, all the
the grunt work can be handled,

can be handed off to AA agents,
be it prospecting, you know,

scraping data, building CRF,
follow-up, emails, you know, all

that stuff that is AI is great
at, but that there's there have

to be someone that handles all
these AI minions, if you will,

that eventually is showing up
for the call with the client.

So again, if we're looking at
the two pillars of a company, as

it is, as I think it should be
built these days, you need

builders and you need sellers.

And if you can do both, that's
great.

Probably great for a bootstrap
just starting out, but split it

into two of people as soon as
possible, just for the sake of

you know, separation of
responsibilities.

SPEAKER_00: Here's the real
question.

If you defer all that middle
management, who's noticing the

subtle things?

The top performer going quiet,
or the teams drifting out of

sync?

AI can handle the grunt work,
but can it replace that

in-the-room judgment?

That's the bit I'm pushing on.

At what point does the pod model
buckle if you wait too long to

add that human layer back in?

SPEAKER_01: So I think the human
layer is there all along.

As I mentioned, the all the the
pod has a an operator, and

that's the person who would
actually do all these things.

And that person will be in
contact with a builder and will

talk to the salesperson, say,
and coordinate what needs to be

done on that regard.

So the the operator is the and
I'm specifically not saying CEO,

and you'll understand it in a
bit why.

So let's stay with the with the
name operator.

That is the products or the
project's CEO as far as it as it

relates to the project.

SPEAKER_00: It does.

But here's the tension.

You're calling them an operator,
not a CEO, to keep it scoped to

the project.

But doesn't that just push the
question further down the road?

At some point, that operator
still has to deal with the

continuous human layer, the
subtle judgment calls, sensing

friction, guiding juniors.

Where does that irreplaceable
human attention live?

Inside the pod or outside in the
foundation?

That's the bit we need to pin
down.

SPEAKER_01: And if we don't need
the middle management in a

classic sense, uh then when do
we use it?

So I think that first off, you
should outsource that middle

management stuff, like uh
bookkeeping, accounting, you

know, even maybe lead
generation.

Just make sure that this the
pipeline person would manage

that outsource of the lead
generation, and the operator

would manage the outsource of
the admin stuff, and the

architect might need to hire one
of a design or a video generator

or what I'm sorry, editor or
whatever it is.

But all these things I think at
the beginning should be

outsourced, so it's not let's
skip it altogether, but let's

not focus on it because during
an early stages of a company,

you don't have enough of
bookkeeping going on to what you

justify hiring someone
full-time, and you don't have

enough of you don't have enough
of anything to justify hiring

full-time, and as you grow,
suddenly, oh, I'm gonna realize

that you do need some position,
some functionality to increase

into full-time position.

But at some point, once you
realize that you do not need

these roles at uh full-time
position, then here's what I'm

suggesting.

I'm suggesting that a firm would
have shared resources.

So every pod, especially if
we're talking about a company

that uh runs multiple products
or multiple projects, I think

that every pod should be scoped
to building and selling that

specific project, and everything
else can be shared resources,

whether it's the design or a
content writing, DevOps

infrastructure, the the the
sales pipeline in in regards to

the the vision of the entire
company.

So I'm hiring for those sellers
and builders and operators

rather than this layer, because
the this layer, we're all set

specifically in Automase, we're
all set in this layer.

But for every project and
product that we wanna that we

wanna move, or every client that
we serve, I wanna look at it as

its own pod.

That's basically how I think a
company should be structured

structured.

And it also kind of referenced
back to I've shared an article,

I think it was in March.

So this kind of the law for
models of sorte development and

agencies.

This was an article I published
in in March, and it's

essentially it uses a very
similar pod, only the pod has a

delivery manager and uh a
pipeline person as well, and

that's because of this was kind
of an agency specific, but it

all kind of lends back to the
same structure that I was that I

was talking about.

It's essentially the same
concept.

Let's have a specialized pod
that handles either a client or

a product and have shared
resources because let's face it,

you don't need 24-7 DevOps for
every single product.

These are or a design for every
single product that you manage.

These are all things that can be
handled, you know, on a on a fur

level rather than on a pod
level.

But I I'd like to hear what you
think about this fur structure.

SPEAKER_00: This structure shows
that each pod stays lean,

focusing on building and
selling, while the foundation

handles those shared resources
DevOps, design, marketing, and

more.

It's efficient, but here's the
friction point.

That foundation layer looks a
lot like the middle management

you've deferred.

So is it really gone or just
relocated?

SPEAKER_01: Okay.

So you you you said it correctly
that the middle management is

not gone, it's deferred.

My even my original post didn't
say you should never hire middle

management.

It just you knew you need to
defer it as much as possible,

outsource it as much as possible
until it's you can really

justify having it as a full-time
position.

When that time comes, especially
if you're a firm running

multiple projects or dealing
with multiple clients, all that

middle management can be hired
on a firm level.

So it's not that you don't need
it, but you definitely don't

need it when you're just
starting off.

And when it's time to hire it,
you should consider this the

shared resources model if you're
a company that runs multiple

products.

But if you're a company that
runs multiple projects, multiple

products, then these should be
shared resources.

Regarding the second qu your
second question about that

judgment in the room, every
single person in this in this

org structure should be hired
based on their abilities and

judgment, which is part of what
part of the that abilities

package.

If they all they all if all they
can do is develop, and if all

they can do is run marketing ads
or make sure that the server is

online, there's really no
judgment going on in terms of

how the company should be built.

And that's why the operator's
role is even more important.

That person is the person that
needs to talk directly with both

the build side and the sell side
in order to make sure that they

have enough information to act
on.

Right?

SPEAKER_00: Your bridge is the
build and sell sides,

synthesizing the right context
from both.

But here's the catch: you can't
outsource that ambient judgment

entirely.

The operator role is
load-bearing for the system.

So while you've deferred middle
management, you've got to admit

there's a core layer of people
who still bring that human

oversight.

SPEAKER_01: No, of course.

Of course, you cannot automate
human judgment, and at no point

did I suggest that humans
shouldn't be part of the of the

structure.

What I'm saying is that the
focus on early stage companies

should be build and sell rather
than kind of rather than put so

many roles and positions and
middle management that in

earlier stages actually slow f
slows things down and is

counterproductive to growth.

That that is the argument.

kind of last words or anything
you want to add before we wrap

this up?

SPEAKER_00: Build, sell, and do.

SPEAKER_01: Alright, sounds
good.

So that's it for today.

Thank you for whoever joined us
live and whoever is watching the

recording.

Thank you very much for joining
us today.

You can find these charts and
the diagrams on my X profile

under articles, and you're more
than welcome to join us live

next time on
oldschoolmutech.com.

See you everyone!