Systems & Scaling
Why the Same Job Title Means Something Completely Different at Two Company Sizes
Samuelson Owei · 27 October, 2026 01:00pm · 5 min read
An "operations manager" hired when a business had ten people and an "operations manager" at the same business with a hundred people are, functionally, doing almost unrelated jobs — one is hands-on, doing the work directly; the other needs to be building and overseeing systems that let other people do the work consistently. Most businesses never formally update the role definition as that gap gets crossed. The title just keeps carrying more and more unrelated responsibility, stretched further and further from what it originally described without anyone deciding that stretch should happen.
This pattern is worth naming explicitly because it's a slow, cumulative drift rather than a single decision, which means it rarely gets caught by any normal review process — nobody schedules a meeting to ask whether a role has quietly become a different job, so the question simply never gets raised until the mismatch has become large enough to cause a visible problem.
Why the role drifts without anyone redesigning it
Growth happens gradually, and responsibilities get added to an existing role one at a time, in response to whatever the business needs that specific month — not as part of any deliberate redesign.
Nobody sits down and decides to fundamentally redefine a role as the business grows. Instead, new responsibilities get layered on one at a time, each addition reasonable in isolation, as a response to whatever gap the business needs filled that particular month. The cumulative effect, years later, is a role that bears little resemblance to its original job description, without anyone having ever deliberately redesigned it, simply because each individual addition felt too small to warrant a formal reconsideration of the role as a whole.
A concrete picture of how this drift actually unfolds
An operations manager hired to personally handle scheduling for ten employees ends up, five years and ninety employees later, nominally still "handling scheduling" — except now that means managing three people who handle scheduling, a system nobody fully understands, and constant firefighting.
Picture someone hired as operations manager when the business had ten employees, personally handling the day-to-day scheduling by hand. Five years later, with the business at a hundred employees, that same person is still nominally "the operations manager," and scheduling is still nominally part of their job — except now it means managing three people who handle different pieces of scheduling, overseeing a system that's grown complicated and partially undocumented, and spending most of their time firefighting problems in a process they haven't personally executed in years. The title never changed. The actual job underneath it changed almost completely.
What this drift actually costs
A person hired and trained for the hands-on version of a role doesn't automatically have the different skill set the system-building version requires — and the business rarely notices the skill mismatch until strain shows up.
The skills that make someone excellent at hands-on execution — speed, attention to detail, comfort doing the work directly — aren't the same skills that make someone good at designing a system other people can execute reliably without them. A person who was the right hire for the first version of a role isn't automatically the right person for the role it's quietly become, and the mismatch tends to surface as strain and frustration long before anyone identifies the actual cause, because both the person in the role and everyone around them simply assume the difficulty is about effort or competence rather than a fundamental change in what the job actually requires.
Why this gets misdiagnosed as a performance problem
When someone struggles in a role that's drifted this far from its original shape, the instinct is to question their performance — when the more accurate diagnosis is that the role itself changed underneath them.
A person visibly struggling in a role that's drifted far from what they were originally hired and trained for tends to get evaluated against the role's current, unstated demands — and found wanting, through no fault related to their original qualifications. The more accurate read is usually that the job changed shape gradually enough that nobody noticed it had become a different job entirely, which means the performance conversation that usually follows is addressing the wrong problem, focused on the person rather than the role they were never actually re-equipped or re-hired for.
Why this is often painful to address even once it's correctly diagnosed
Recognizing that a loyal, long-tenured employee's role has outgrown their current skill set is an uncomfortable conversation, which is part of why the correct diagnosis often doesn't lead to a timely fix.
Even once a business correctly identifies that a role has drifted beyond what the current person is equipped to handle, acting on that diagnosis is genuinely difficult — it often involves a loyal, long-tenured employee who's given real effort to a role that simply changed shape underneath them, through no fault of their own. That emotional difficulty is a real reason this correct diagnosis often still doesn't translate into a timely fix, which is worth acknowledging honestly rather than pretending the fix, once identified, is simple to execute.
What fixes this before it becomes a performance issue
Periodically asking, explicitly, "does this role as it exists today match what we originally hired for" catches the drift early, before it turns into a people problem that was actually a role-design problem.
The fix is a periodic, explicit check: does this role, as it's actually being performed today, still resemble what it was when the person was hired into it. Asking that question on a schedule — rather than waiting for visible strain to force the conversation — catches role drift while it's still a straightforward redesign, instead of letting it calcify into what looks like, but isn't actually, a performance problem that becomes much harder to address the longer it goes unexamined.
My team and I look at whether your current roles still match what the business actually needs now, not what it needed when the role was first created — part of the free AI Scaling Roadmap.