SPEAKER_01 0:00

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 0:24

Hello. I'm all set and ready for the episode.

SPEAKER_01 0:27

Alright, so what are we talking about today?

SPEAKER_00 0:30

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 0:46

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 1:32

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 1:55

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 2:45

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 3:04

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 4:04

Yes, I can see it now. Alright.

SPEAKER_01 4:06

You've So what do you see? Just to make sure that we're both on the same page.

SPEAKER_00 4:10

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 4:24

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 4:33

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 4:48

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 6:01

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 6:18

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 7:54

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 8:08

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 9:50

That's the long poll, right?

SPEAKER_01 9:51

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 11:56

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 12:16

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 12:58

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 13:24

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 17:10

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 17:30

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 19:27

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 19:45

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 20:44

Build, sell, and do.

SPEAKER_01 20:45

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!