A manufacturing CEO describes the work of holding a growing company together

In a post I read in August 2026, Jim Belosic, CEO of SendCutSend, described scaling a manufacturing company with 600 employees and factories in several states. His account connects growth with the work of keeping people informed and decisions reliable.

with 600 employees you don’t know everyone, but you still feel like they are your kids in a way. When someone loses a family member, or they have a sick kid, or they get into a motorcycle accident, I worry about them like they are my own kid.

the larger the company grows, the more you have to lose. hundreds of families count on me for a paycheck, so the stakes are really high. Easy to lose sleep when things go sideways for a little bit.

It goes on like that for ten bullet points. Vendors, safety, money that stops feeling like money. The whole thing is worth reading. But one line stopped me.

entropy is real. We are fighting laws of thermodynamics lol. Everything wants to dissolve into disorder and chaos. Gotta fight it 24/7

The comparison with thermodynamics describes the effort of maintaining an organization. It is a metaphor, not a physical law proving that a particular company must become disordered.

Nobody warns you about this part when the company starts working.

In a small experienced team, shared instincts can make some coordination implicit. Safety still requires explicit controls and training, regardless of headcount. New colleagues cannot inherit experience just by joining.

Then you grow. And the instincts do not come with the new hires. His words:

Some people are brand new to manufacturing and don’t have the instincts that come with working with machines for years and years

Read that again and take out the word manufacturing. It is true of everything. The way you handle a client who is about to churn. The reason you never quote that supplier on Fridays. The three checks your best ops person runs before a shipment goes out, checks she cannot even fully explain because to her they are just how you do it. None of that is written anywhere. It lives in her hands and her memory.

As the team grows, check whether each shift can perform the critical work without relying on the same person. Headcount alone does not establish where the problem begins.

The knowledge did not disappear. It just stopped scaling. You kept hiring and the instincts stayed at their original headcount.

The first thing that actually breaks is smaller than you expect. It is the messages.

Belosic again: using Slack to communicate across shifts and factories in different states, he says, sucks. Important messages get lost. Things get taken the wrong way. His fix is more phone calls and more travel, which work, but cost him the one thing he has least of.

Sit with that for a second. A guy running a real company with real machines is telling you that the tool did not fail. The tool worked exactly as designed. What failed is that the company outgrew the assumption underneath the tool, the assumption that everyone who needs to know a thing is close enough to overhear it.

That assumption is the whole informal company. It is what lets a business of thirty run on hallway conversations and a shared sense of how things are done. It is also the exact thing that dies first, quietly, while every other number still looks fine.

There is a second cost, and it is the one that eats at the good ones.

Belosic admits he catches himself making negative assumptions. He sees an office team grow and thinks, seriously, it takes a full-time job to do that? Then he sits with them and sees that at scale, yes, the thing that took twenty minutes a week when the company was small now genuinely takes a person all day.

His example shows the limit of judging a growing function from the outside. Sitting with the team changed his assessment of the work involved.

He is not lazy and he is not cold. He is just not in the room anymore. He cannot be. That is the trap of the thing working: the better it works, the further you drift from where it actually happens, and the more you have to guess.

Now the part he offers as the cure, which is also the part most people hear too late.

you can’t be everywhere all the time, so you gotta have great people that would make the same decisions you would make if you’re not in the room. Or ideally they make an even better decision. Great leaders allow companies to grow. Build them early.

Develop people who can decide

Everyone agrees with it and almost nobody does it, because early is exactly when it feels unnecessary. At thirty people you are the room. You are in every decision because you can be, and it is faster, and it works. Writing down how you decide, when you are still the one deciding everything, feels like paperwork for a problem you do not have yet.

The same transfer problem applies to the operating system around those people. Decision routes, checks and exceptions need maintenance as the company changes. A useful process record should explain the current work and help another person perform it.

The company that made you proud was probably built on instinct. There is nothing wrong with that. Good companies start exactly that way. The mistake is assuming the thing that got you here will survive being multiplied. It will not. What was implicit has to be made explicit, on purpose, before the day it costs you a client instead of just an afternoon.

The reason this matters more now than it did five years ago is that for the first time you can make the implicit explicit without hiring a department to do it. The rules, the routing, the checks that used to live in one person's head can become a system that holds them, applies them, and does the busywork around them, so your people go back to the judgment only they have. That is a real shift. It is also a different conversation, and it comes after this one, not instead of it.

The industrial lesson is to make critical operating knowledge transferable while developing people who can use it. Start with one dependency and test whether a second person can handle the work.

Bring one dependency to a 30-minute Strategy Session. We will recommend whether it needs mapping, a bounded feasibility test or a different next step.