Navigation · The Swink Group
30 minutes · No pitch · No corporate theater
Growth has a funny way of exposing every process nobody documented, every handoff nobody owns, every exception nobody planned for, and every decision that somehow still needs the founder. We figure out why the business keeps fighting itself — then fix the operating structure underneath it.
Operational Traffic · Current State
Incoming Work
Default Routing Point
The FounderWhat That Creates
Work waits for somebody at the top.
The business works differently depending on who's online.
Growth creates more decisions instead of more leverage.
The Real Problem
The founder became the operating system because the actual operating system never got built.
What Better Starts to Look Like
Ownership · Workflow · Decisions · Systems · Execution
A business that makes sense without founder telepathy.
What Operational Problems Look Like
Usually it shows up as missed work, frustrated employees, annoyed clients, constant interruptions, or another meeting about why something still didn't happen. The symptoms look different. The operating conditions underneath them are usually much more connected than they seem.
Above the Surface · What You Notice
Symptoms are evidence — not diagnoses
Founder Dependency
You hired people so you could stop being involved in everything. Instead, you're still approving exceptions, answering questions, solving weird edge cases, and becoming the default answer whenever nobody knows what happens next.
Ownership
Plenty of people are working. That's not the same as clear ownership. Responsibilities overlap, work bounces between people, and something sits untouched because everyone reasonably thought somebody else had it.
Process
The process works because one experienced employee knows the exceptions, shortcuts, context, and unofficial rules. When they're unavailable, everyone suddenly discovers the documentation was mostly wishful thinking.
Handoffs
Sales thinks delivery has it. Delivery thinks onboarding owns it. Customer Success assumes somebody already followed up. The client doesn't care whose fault it was — they just know nobody called them.
Systems
The CRM says one thing, Slack says another, somebody has a spreadsheet, and the actual truth lives in a conversation from last Thursday. Technology was supposed to create visibility — not an archaeological dig.
Execution
Everyone agrees something needs to change. Then the meeting ends, normal work takes over, ownership gets fuzzy, and two weeks later you're discussing why the same damn thing is still happening.
↓ This Is Where Diagnosis Actually Starts ↓
Below the Surface
Who is actually allowed to decide without sending everything uphill?
Is responsibility genuinely clear, or just assumed?
How does work actually move when the day isn't perfect?
What information, ownership, or next action disappears between people?
Do the tools reflect the real operation or an imaginary cleaner version of it?
What turns an agreed decision into work that actually gets finished?
The Question I'm Asking
“Why does this keep happening — and what in the operation keeps making it possible?”
Diagnose Before Prescribing
Fix what keeps creating the problem, not just whatever broke today.
What We Actually Fix
Ownership, workflow, handoffs, documentation, systems, execution, and capacity all affect each other. A problem can surface in one layer while being created somewhere else. So we don't start by choosing a service. We figure out which part of the operation actually needs attention.
#
Operating Layer
What We Change
The Question Underneath It
Authority
Clarify who owns the work, who makes the decision, who gets consulted, and what genuinely requires the founder.
“The team handles it” isn't an operating model.
Who owns the outcome when something doesn't go according to plan?
Flow
Follow work from trigger to completion and remove unnecessary steps, duplicated effort, bottlenecks, dead ends, and those weird workarounds everyone forgot were supposed to be temporary.
How does the work really move when the day isn't perfect?
Transition
Define what survives when work changes hands: ownership, context, expectations, deadlines, and the next action.
A good handoff makes responsibility visible before the ball hits the floor.
What disappears every time responsibility moves?
Knowledge
Pull critical operating knowledge out of people's heads and turn it into documentation the team can actually use.
Not a 47-page SOP written solely so everyone can say an SOP exists.
What stops working when the person who “just knows” isn't available?
Infrastructure
Make technology support the operation instead of forcing the company to work around its software. That can mean cleanup, redesign, automation, integrations, better visibility — or occasionally admitting a tool actually needs to go.
Does the system reflect reality, or force people to fake the process?
Movement
Look at how decisions become action: priorities, meetings, follow-up, accountability, communication, and the rhythm used to move work forward.
A decision nobody executes is just a conversation.
What turns “we should do this” into something that actually gets finished?
Capacity
Determine whether the team actually needs more capacity, a different division of responsibility, or simply a better way of using the people already there.
Hiring isn't automatically an operations strategy.
Is the problem really workload — or is broken work creating fake capacity needs?
Why the Layers Matter
That's why diagnosis comes before the solution.
Intervention Logic
Jeremy's Rule
“I don't change something just so I can say I changed it. If it already works, leave the damn thing alone.”
Smallest Useful Intervention
Fix enough to solve the problem. No transformation theater required.
The Operator Lens
The thing everybody is complaining about might absolutely be a problem. It just might not be the problem. So instead of immediately changing something, we reconstruct what happened, compare it with what was supposed to happen, and find the gap that made the failure possible.
Operational Incident Reconstruction
Diagnosis In ProgressReported Incident
A new client finished onboarding. Nobody followed up.
Reconstruct the Sequence
Compare intended workflow with what actually happened.
What the company believes should happen.
What really happened on Tuesday.
What We Know So Far
The employee didn't simply “forget.” Ownership and the workflow diverged before the follow-up ever had a chance to happen.
Now We Test the Conditions
Any one of these could be contributing. Several might be interacting. We test before deciding what deserves to change.
Was somebody clearly responsible for the account after onboarding?
Was there a defined step that should have created the follow-up?
Could the CRM support the workflow — and was it configured to?
Did the responsible person know the expectation and have capacity to execute it?
Before We Change Anything
Only then do we decide whether the answer is clearer ownership, a different handoff, better documentation, a CRM change, automation, additional capacity, management follow-through, or something else entirely. Change needs evidence.
Good employees can look terrible inside unclear ownership, broken workflow, and conflicting expectations.
Existing processes and systems earn the right to stay when they're doing their job.
Make the workflow make sense manually. Then use technology to support something worth scaling.
Reconstruct · Test · Understand · Change
Fix the operating condition — not just today's incident.
What Better Looks Like
Operational improvement shouldn't only show up in an org chart, process map, or consultant's presentation. You should be able to feel the difference on a completely ordinary workday.
Same people. Same customers. Same business. The work simply makes more sense.
A routine exception immediately rolls uphill because nobody is quite sure where their authority begins or ends.
Responsibility, authority, and escalation paths are clear enough that normal decisions stay where the work actually lives.
Work changed hands through assumptions, messages, memory, and whatever somebody happened to say in the last meeting.
Responsibility, context, information, and the next action are visible before the work leaves somebody's hands.
The real process lives inside one experienced employee's memory, including every exception nobody bothered documenting.
Important knowledge is accessible enough that execution doesn't disappear when the person who “just knows” isn't available.
Somebody has a spreadsheet. Somebody else has notes. The official system stopped reflecting reality three months ago.
The tools support the real workflow, information lives where the team expects it, and leadership can trust what they're seeing.
Everyone agreed what needed to happen. Somehow ownership disappeared between the conversation and the actual work.
Owners, priorities, next actions, and follow-up are clear enough that progress doesn't depend on somebody remembering the meeting.
Visibility means opening Slack, checking spreadsheets, calling people, and piecing together five versions of the truth.
Useful visibility comes from the operation itself instead of leadership becoming the company's human status-reporting system.
The Tuesday Test
That's operational improvement you can actually feel.
Decisions live closer to the work.
Work moves without unnecessary friction.
The operation can explain itself.
Weird days don't automatically become emergencies.
The Actual Goal
Businesses will always have strange situations, difficult days, unexpected problems, and questions nobody planned for. Good operations don't eliminate reality. They make the company much better at dealing with reality without turning every problem into a fire drill.
How We Can Work Together
I'm not going to pretend every company needs the same twelve-week transformation package. Sometimes the right answer is a focused set of experienced eyes. Sometimes the work needs to be rebuilt. Sometimes leadership needs another operator nearby as the company grows. The scope gets larger only when the problem gives us a reason.
Scope Principle
Start with the smallest useful intervention. Let deeper work earn its way in.
Diagnose
You know the company has friction but you're too close to see exactly where it lives. We examine how work actually moves, identify patterns, test likely causes, and clarify what deserves attention first.
You can see the symptoms but not the cause.
Solve
We already know where the pain lives: a broken handoff, unclear ownership, messy onboarding, an unreliable workflow, or another defined operating problem. We fix that piece and keep the scope where it belongs.
One specific problem needs to stop being a problem.
Build
Knowing the answer isn't enough. We help turn it into workflows, documentation, role clarity, CRM structure, automations, operating rhythms, and practical tools the team can actually use. Sometimes you need the damn thing implemented.
The direction is clear, but making it real requires hands-on work.
Advise
Growing companies keep creating new decisions, bottlenecks, team challenges, system questions, and situations nobody planned for. Ongoing advisory gives leadership another experienced operational brain in the room without automatically adding another full-time executive.
Leadership needs continuing judgment, not just one answer.
No Forced Packages
I am perfectly comfortable telling you the useful answer is one clearer responsibility, one workflow change, one system correction, or one decision you've been avoiding.
If what we uncover genuinely requires deeper work, we'll talk about that too.
The scope should earn its way into the engagement. It shouldn't exist because somebody needed another line item on a proposal.
You Don't Need to Choose One
“I know something is wrong, but I can't tell you what.”
That's enough to start.
“This one part of the business keeps driving everybody nuts.”
Bring me that.
“We already know what needs to happen. Nobody has actually built it.”
We can look at implementation.
“I just need another experienced operator to think through this stuff with me.”
That's what advisory is for.
No package-selection homework required.
Tell me what's happening inside the business.
Diagnose · Solve · Build · Advise
The engagement gets bigger only when the problem earns it.
Jeremy's Rules for Operations
These aren't commandments, and I'm not pretending I invented operations. They're lessons learned from watching good businesses make the same avoidable mistakes over and over again. Simple rules tend to survive reality better than complicated frameworks.
Operational Guardrails · Field Standard
Keep the business from creating its own friction
01 / 06
Ownership
Shared responsibility sounds collaborative right up until something gets missed. Every important outcome needs a clear owner. Other people can contribute. Somebody still has to have the ball.
Prevents responsibility from disappearing inside collaboration.
Automation
Automation does not create clarity. It multiplies whatever you give it. If the manual process is confusing, inconsistent, or broken, automating it just lets the confusion happen faster.
Prevents technology from scaling nonsense.
Documentation
Documentation exists to help somebody do the work. If employees need a search party, a philosophy degree, and twenty uninterrupted minutes just to find the next step, we missed the point.
Prevents documentation from becoming ceremonial paperwork.
Capacity
Sometimes you genuinely need more capacity. Great. But headcount should not become the default solution to unclear ownership, poor workflows, weak onboarding, or work nobody has bothered to structure.
Prevents structural problems from disguising themselves as hiring needs.
People
People absolutely make mistakes. They also work inside the systems, expectations, tools, training, priorities, and decisions leadership gives them. Before calling someone the problem, make sure the business didn't set them up to fail.
Prevents system failures from being mislabeled as people failures.
Restraint
Consultants sometimes feel obligated to change things because they were hired to change things. I don't. If a process is simple, understood, reliable, and doing its job, it has earned the right to survive the consulting engagement.
Prevents consulting from becoming a source of unnecessary disruption.
The General Philosophy
The goal isn't more process for the sake of process. It's enough structure to make ownership clear, execution repeatable, information trustworthy, and the company easier to navigate.
Good operations should disappear into the way the business works — not become another layer everybody has to work around.
Before We Add Anything
Does this make the work easier to understand?
Will the people doing the work actually use it?
Does this solve a real problem, or are we just adding process?
Ownership · Clarity · Usability · Capacity · Fairness · Restraint
Operations should help people work — not give them more shit to work around.
That's Enough
You don't need a process map, polished explanation, consulting vocabulary, or a finished diagnosis before we talk. Tell me what keeps happening, what keeps breaking, what keeps landing back on your desk, or what your team keeps fighting with. The recurring sentence is usually a pretty damn good place to start.
Signal
The Sentence
Founder Dependency
“Why does everything still need me?”
What It Gives Us
A place to examine authority, escalation, ownership, workflow, and decision rights.
The First Conversation
Tell me what keeps happening inside the business. We'll talk through what you've seen, what you've already tried, and where the operation seems to keep fighting you. Then we'll decide whether The Swink Group can genuinely help.
“Jeremy, here's the thing in my business that's driving me nuts...”
30 minutes · No pitch · No pressure · No corporate theater
One More Thing
“If I don't think you need me, I'll tell you. That's still a useful conversation.”
The Swink Group · Operations Consulting
Make the business easier to run.
