75 to 1,500 is its own discipline

There’s a person I meet at almost every company in a certain size range, and she’s usually the first person I ask to talk to. Her title varies. HR manager, payroll administrator, director of people, sometimes office manager, because the title was set years ago and nobody’s had time to fix it. She runs payroll for three hundred people, which owns her Monday and part of her Tuesday. Wednesday she’s onboarding six new hires for the busy season. Thursday morning a plant supervisor asks her whether the new overtime rule applies to the weekend shift, and she needs to be right, because the fine for being wrong has a comma in it. Thursday afternoon it’s open enrollment prep. None of these is her job. All of these are her job.

There is no benefits specialist down the hall. There’s no comp team, no HRIS administrator, no shared-services center in another time zone. There’s her, maybe a coordinator, and a stack of systems that were all designed on the quiet assumption that somewhere in the building sits a certified specialist who read the manual.

I run a software business that serves companies like hers, businesses roughly between 75 and 1,500 employees, and the longer I do this the more convinced I am of something most of my industry gets wrong: this band is not a smaller version of the enterprise. It’s a different discipline entirely, and treating it as a shrink-to-fit problem is why so much software fails in it.

The standard industry play is subtraction. Take the enterprise suite, the one designed for fifty thousand employees and a dedicated admin team, remove some modules, simplify the pricing page, and call the result mid-market. It looks sensible on a slide. Analysts have a column for it. And I think it’s exactly backwards, because subtraction removes features but doesn’t remove assumptions, and the assumptions are the problem. The assumption of a specialist reading each screen. The assumption that an implementation office exists. The assumption that configuration is somebody’s full-time job, that the org has an owner for every workflow, that complexity, wherever it lands, will be absorbed by headcount.

At enterprise scale, those assumptions are true. Complexity there is a staffing plan. A hard module gets a certified administrator; an integration gets a project team; nobody expects the payroll specialist to also run onboarding, because there are forty people between those two jobs. Enterprise complexity is absorbed the way a big building absorbs weather. You barely notice inside.

At three hundred employees the weather comes indoors. Complexity has nowhere to go, so it lands on the generalist, on her Thursday, in the gap between the overtime question and open enrollment. Every screen that assumes an expert is a small tax on someone who has ninety seconds to be one. Enough small taxes and the system stops being used properly, and then the company is running its most regulated, most expensive, most human process on workarounds and spreadsheets, and everyone quietly accepts that this is what software is like.

Now, the mistake people make when I say this is to hear “keep it simple” and conclude that companies this size need simple tools. Light versions. Starter editions. That’s the other half of the industry’s error, and honestly it’s the more condescending half.

Because her needs aren’t simple. A 400-person manufacturer runs rotating shifts, overtime rules that interact with state law, labor costs that decide whether the quarter works, compliance exposure that would look familiar to a company ten times its size. A gym chain with thirty locations needs real-time visibility into frontline scheduling that plenty of Fortune 500 head offices would envy. The regulations don’t read your headcount before applying. Scheduling depth, labor cost control, compliance rigor: companies in this band need all of it, at nearly full enterprise depth. What they can’t use is depth that arrives wearing the enterprise’s operating model.

So the actual design target, the whole discipline, is this: enterprise-grade capability, operable by a generalist. Both halves, at full strength, at the same time. Depth without the org chart the depth usually assumes. That’s not a subtraction exercise and it isn’t a simplification exercise. It’s a harder design problem than the enterprise one, if I’m honest, because the enterprise product gets to externalize its complexity onto the customer’s staff, and a product for this band has to swallow that complexity itself. The hard stuff has to be in there, working, and the person driving it has to be able to be competent in ninety seconds, between two other jobs.

Concretely, swallowing the complexity means the software has to be the specialist the org chart doesn’t have. Defaults that are actually right for a 300-person company out of the box, instead of a thousand configuration decisions deferred to an admin who doesn’t exist. Compliance changes that arrive the way weather updates arrive on your phone, already applied, not as a quarterly project with a statement of work. Screens written in the language of the person’s actual Thursday, overtime and schedules and new hires, not the vendor’s data model. When something’s about to go wrong, the system says so before payroll runs, in a sentence a generalist can act on. None of that is a feature you can point to in a demo, which is exactly why subtraction-based products never have it. It’s a thousand design decisions that all start from the same question: what if nobody here has read the manual, because nobody here has time to, because everybody here is doing three jobs?

That question, asked honestly, changes what you build at every layer. It’s also a question the enterprise playbook never has to ask, which is why you can’t get here by subtracting from it.

I’ve spent years saying publicly that people leaders at these companies deserve the same quality of technology as anyone at a Fortune 500, and I keep saying it because the industry keeps behaving as if it were a pricing statement. It’s not a pricing statement. It’s a design constraint, and it’s the one most vendors won’t accept, because accepting it means you can’t reuse the expensive thing you already built. Subtraction is popular because subtraction is cheap.

It’s worth being clear about how big the thing being underserved is. The Fortune 500 employs a small fraction of the people who go to work in this country. Most working people are at companies you haven’t heard of, companies in this band, run by lean teams where the payroll person is also the onboarding person and the compliance hotline is whoever answers. When software fails at a 50,000-person company, a process degrades and a steering committee forms. When software fails at a 300-person company, actual paychecks are late, and the person who has to explain why is the one the system was never really designed for in the first place.

I’ll grant the counterargument its due. There’s a school of thought that says the band doesn’t deserve its own discipline, that these companies should just adopt enterprise practices early, hire ahead, professionalize, grow into the suite. Some do, and for the ones that are sprinting from 800 toward 5,000, fine, that can work. But it prescribes the enterprise’s medicine to companies that don’t have the enterprise’s metabolism, and I’ve watched it fail too many times to find it respectable as a default. A 300-person company that staffs like a 3,000-person company doesn’t become sophisticated. It becomes broke.

I have skin in this argument. I run a P&L whose entire premise is that this band is its own discipline, and the market keeps agreeing with the premise, so you can discount my objectivity but not, I think, my evidence. I watch what happens when the second half of the design constraint is actually honored. Payroll that took a team hours starts taking minutes. The Thursday compliance question gets answered by the system, in plain language, before the supervisor walks away. Turnover moves, measurably, because it turns out frontline employees can tell when the tools respect their time, and so can the person running those tools.

Which brings me back to her. The industry has spent two decades building for her boss’s boss at a company she doesn’t work for, then handing her the subtracted remainder and wondering why adoption lags. She was never the edge case. In this band she’s the whole case: the generalist doing five specialists’ jobs with no manual and ninety seconds. Build for her Thursday and you’ve built the right thing.

She’s not a smaller user of enterprise software. She never was.