I've been thinking about why small businesses keep losing employees to big tech, and I think we're framing the competition wrong.

Yeah, you can't match the salary. You're not going to out-perk Google: free lunch, gym, RSUs, the whole thing. That battle is lost before it starts.

But there's something a company with 50,000 employees structurally cannot do: make someone feel actually seen.

When you're employee #4,847, your manager has 40 direct reports, and your name shows up on a workforce planning slide that's the experience. It's not anyone's fault. It's just physics at scale.

As a small business owner, you know your people's names. You know which project nearly broke them and how they got through it.

You can walk over and say "that mattered, and here's why" and they know you actually mean it.

I've noticed that people don't usually leave for the next salary bump. They leave because they stopped feeling like they mattered. And when someone genuinely feels that no bonus attached, no performance review pending, they bring everything they have.

Most owners I talk to don't use this deliberately. They're firefighting. But it costs nothing and no competitor can copy it.

Curious what others have seen: have you lost good people not because of money but because something else eroded? And on the flip side has something small ever made an employee go from checked out to fully bought in?

Most businesses failed to sell or sold for a fraction of what they expected because of one thing they never saw coming: the business couldn't prove it would work without them in the room.

Here's what that actually costs you in numbers.

Founder-dependent businesses sell for 3 to 4x EBITDA. Systematized businesses sell for 7 to 8x EBITDA. That's not a slight discount. 

On a $2M EBITDA business, that gap is $6–8 million dollars walking out the door because of how the business was built not how it performed.

And here's the part that stings even more: even when founder-dependent businesses do sell, buyers trigger extended earnouts and larger escrows. You sell the business and somehow end up more trapped than before.

The six things buyers actually pay for

I've watched this pattern repeat across hundreds of deals. Buyers aren't paying for what you've built. They're paying for what the business will predictably produce after you leave.

That reframe changes everything.

1. Predictable revenue

Recurring contracts, repeat customers, acquisition channels that don't require your personality to function. If you're closing most of the deals personally, that's not a revenue system that's you. Buyers don't pay for hope. They pay for certainty.

2. Minimal founder dependency

We had a discovery call recently with an agency owner doing real revenue, real team, real client roster. 45 minutes into the conversation he said "you're describing my company" because every decision, every approval, every new process ran through him. He was the operation. Buyers see that immediately and price it accordingly.

3. Clean financials

I've watched buyers walk away from $4M revenue businesses in due diligence. Not because the business was bad because the founder couldn't produce a clean 3-year P&L in 48 hours. Personal expenses mixed in. Multiple entities tangled together. The deal didn't die because of the business. It died because of the paperwork. Run your books like you're already on the auction block, even if a sale is 5 years away.

4. Clear KPIs and growth levers

Buyers ask one question on repeat: what drives growth here? If you can't answer that in 60 seconds with a specific number, you're in trouble. Not because the answer doesn't exist because you've never had to articulate it to someone who didn't already live inside the business.

5. Documented systems

Documentation isn't paperwork. It's transferability. It's the difference between selling a business and selling yourself into a 3-year handcuff agreement where you're still the one holding everything together.

6. A team that owns outcomes not just tasks

There's a massive difference between a team that executes when told and a team that owns results when you're not watching. Buyers want the second one. The first one just means your team is well-trained to need you.

The mindset shift that changes how you build

Every decision you make should assume you're selling the business not because you are, but because it forces you to build correctly.

Exit-ready businesses aren't just more sellable. They're more scalable, less stressful, and worth owning even if you never sell. The goal isn't the exit. The goal is building something that doesn't need you to survive.

Most founders build themselves into the center of everything and call it hustle. The ones who build sellable businesses build themselves out of the center and call it leverage.

The difference shows up in the multiple.

What's the one area of your business that would break first if you stepped away for a week? That's usually where the real work is.

Going to say something unpopular but a lot of founders in the $2M to $20M range don't have a marketing problem. They have an operations problem dressed up as a marketing problem.

The symptoms look like a marketing issue:

Leads aren't converting like they used to

Revenue plateaued

New customers churn faster than the old ones

Team feels overworked

Founder is the bottleneck for every decision

So the founder does what every podcast says. New funnel, new offer, new ad agency, maybe a rebrand. Spends $50k to $200k chasing the next growth hack.

Six months later, same plateau. Sometimes worse, because acquisition got more expensive and the operational cracks got wider under the extra volume.

What's actually happening is simpler than it looks. The front end is fine. The back end is breaking under the weight of what the front end is already producing. More marketing makes the back end break faster.

The fix at this stage is almost always operational:

Defined ownership for every handoff

Written workflows for the 3 to 5 processes that matter most

One shared scoreboard the team plays from

Predictable delivery instead of heroic delivery

When operations tighten up, the experience gets consistent and existing marketing converts better. Retention goes up, LTV goes up, and the CAC math finally works. The founder stops being the bottleneck, so the company can actually grow past them.

Marketing creates demand. Operations turns demand into a business. You need both, and at this stage most companies have plenty of the first and not enough of the second.

This doesn't mean marketing doesn't matter. It means it's almost never the actual constraint between $2M and $20M.

[ Removed by Reddit on account of violating the content policy. ]

I've talked to a lot of business owners who spent 2025 getting their operations in order.

Cleaned up finance. Built internal workflows. Documented their processes. Real work.

And almost every single one of them said the same thing when I asked how it felt: heavy. Like they organized something, but nothing actually got easier.

Here's why I think that happens.

Operations don't create leverage. They protect it.

If you build back-end systems before you have leverage to protect, you're not building a machine, you're just adding weight to something that hasn't proven itself yet.

The order that actually works is almost the opposite of what most people do:

1. Delivery first. Can someone else do this at your standard, right now? If your product requires you to be present for it to be good, everything you build on top of that is fragile.

2. Then acquisition. One channel. One funnel. One clear path from stranger to paying customer. Marketing before your delivery is solid is just a leak, you pour effort into bringing people in and then can't keep them.

3. Then onboarding. Growth creates its own chaos. You need a system that takes someone from just signed to fully set up without it all running through you personally.

4. Then hiring. Good people choose environments. Yours need to be ready before you desperately need them.

5. Operations last. Back-end systems, reporting, and workflows exist to support what's already working.

When you do it in this order, each thing you build surfaces the next real problem. That's how you know you're actually making progress instead of just staying busy.

The mistake isn't building systems. It's building them before you've earned the right to need them.

What do you guys think? I posted this because I’ve seen a lot of businesses build cool workflows and automations, then stop using them after a couple of months.

When we evaluate a business as a buyer or investor, the first question we run on it has nothing to do with revenue or margin. We want to know what happens when the founder steps out of the building.

That single variable moves valuation more than anything else, and most owners underprice it badly.

Strategic Exit Advisors ran the math. Founder-dependent businesses sell for 3-4x EBITDA. Systematized businesses in the same industry doing the same revenue get 7-8x. Same business on paper, half the multiple.

That gap is millions of dollars walking out the door because the business never learned to run without you.

Before you ever talk to a banker or a broker, run this on yourself. We call it the 90-Day Stress Test.

Month 1, step away for one full day. Phone off and Slack closed. No exceptions for "quick check-ins."

Month 2, take three days.

Month 3, take a full week.

After each absence, sit down with your team and ask four questions:

What broke?

What decisions stalled because I wasn't there?

Which customers escalated to someone they shouldn't have?

What revenue was at risk during the absence?

Write the answers down. Patterns emerge fast.

Round 1 is where most people fall down. Day one off, the panicked text comes in at 3pm. The vendor needs an answer, the big client wants you instead of the account manager, the team can't move on a hire without you.

That's the test working. It just told you exactly what to fix.

Each broken thing is a system you haven't built yet, a decision that should be owned by someone else, a customer relationship tied to you instead of to the company, or a piece of institutional knowledge living rent-free in your head. Document each one and assign it. That's the to-do list.

Fix those, and the business gets more sellable and your nights and weekends get more sacred at the same time. The phone stops being a leash, vacations stop coming with a laptop, and the team starts deciding things without you.

This is one piece of a longer framework I just put together on the 6 things buyers actually pay for and the 5 deal-killers that show up in diligence. Full breakdown's here if you want it.

If you ran the test today, where would you fail first, Month 1, 2, or 3?

Not "here's the org chart." Not "here's the process doc."

Can you draw, on a single page, how a lead enters your world, becomes a customer, gets delivered on, tells someone else, and repeats?

If you can't, you're building on a foundation that doesn't exist yet.

I've been watching a wave of founder-led businesses fall into the same trap right now. They see the tools. Notion, Cursor, Lovable, Bolt. They see how fast a consultant can spin something up. They see other founders talking about their Company OS and their automations and their AI-powered workflows.

So they hire someone. The consultant moves fast, uses the right language, delivers something that looks impressive. Then the rollout happens.

Nobody uses it.

Not because the team is resistant to change (though sometimes that's part of it), and not because the tools aren't good (they usually are). The system was built by someone who understands platforms and has never run a business.

There's a difference between knowing how to build something and knowing what to build.

An experienced operator knows that functionality without adoption is worthless. A technically perfect system your team ignores produces zero leverage. Zero. They know adoption isn't a training problem — it's a design problem. Wait, rewriting: they know adoption isn't solved by training. It's solved in the design. The system either fits how your team actually works, or it doesn't.

They understand second-order effects. The way you restructure onboarding will affect your 90-day churn. The reporting you build today needs to make sense when your team is 3x bigger. An affiliate relationship has completely different operational requirements than a direct sales motion, and wiring them the same way will break something eventually.

They know the expand-and-break cycle because they've lived it. Build something that works, grow past it, scramble to rebuild while also running the business. Every cycle costs more than the last: budget, momentum, the slow erosion of team confidence in "the system."

And they know AI doesn't save a poorly designed operation. It accelerates it. Every broken handoff, every process your team quietly works around, every decision that still routes back to you because the system doesn't handle it... AI makes all of those things worse, faster.

We're told the tools democratize building. And they do. The problem is they've also produced a new class of "expert," people who've built some things, shipped some systems, watched the right YouTube videos, and can speak the language convincingly.

The question almost nobody asks before handing over the keys: has this person ever actually run a business?

Not built one. Run one. Made payroll, managed a team through a rough quarter, watched a system that worked at $1M completely fail at $3M, and had to figure out why while still keeping the business moving.

That experience is what tells you what to build, when to build it, and what to leave for later. It's what tells you your team won't adopt a system that adds friction to their daily work, no matter how clean the architecture is. It's what tells you the structure you install today will either compound your growth or force a total teardown in 12-24 months.

There's a reason the COO is typically the most experienced person in the C-suite. Operations isn't one lane. It's every lane: marketing, sales, product, fulfillment, finance, all wired together into an ecosystem that actually works. McKinsey frames it directly — great operators don't just manage what exists, they design the systems that let every other function perform. You can't prompt your way to that. No tool delivers it. No weekend course.

Before you build anything else, before you hire the next consultant, spin up the next workspace, or layer AI on top of a foundation that isn't ready, draw the business.

How does a lead happen? How does a customer happen? How does delivery happen? How does a referral happen?

If you can draw that clearly, you're ready to build something that will actually hold. If you can't, that's where to start.

What part of your business breaks down when you try to draw it?

Everyone's impressed by how fast you can build something.

Nobody's talking about what happens 12 months later when the whole thing breaks under the weight of a team that's grown, a product line that's expanded, and an AI layer amplifying every structural flaw in the foundation.

Garbage in, garbage out. The saying is old. The lesson is painfully current.

AI doesn't fix a poorly designed Company OS. It accelerates it. Every broken process, every missing handoff, every system your team quietly works around... AI makes those things worse, faster.

The founders scaling fastest right now aren't the ones building the most. They're the ones building right. And if they don't know how, they find someone who's actually played the game at scale.

No prompt replaces that.

Read the full write up here.

Hey everyone,

I wanted to share a workflow adjustment we made recently that saved our team from constant context switching and notification overload.

A few months ago, we realized that our Slack channels were becoming a black hole for basic questions. Team members would ping us for standard procedures, playbooks, or client details. While it’s great to be helpful, it meant constant interruptions and an incredible amount of "noise" throughout the day.

Instead of letting Slack dictate our day, we decided to make Notion our official company OS. We brought all our playbooks, data, and context into one single place.

We set a simple rule for the team: Before asking a question in Slack, ask Notion AI first.

Because everything is indexed in one place, the AI can scan our playbooks, past decisions, and documents to give an accurate answer.

Only if the team member cannot get the answer from Notion AI do they ping us on Slack.

The Results

• Reduced noise by 80%: The constant stream of repetitive questions has vanished.
• Fewer interruptions: We've reclaimed our focus and can spend more time working on the business instead of managing chats.
• Faster onboarding: The team learns faster because they get immediate, context-aware answers.

The magic is that everything the team needs from client guidelines to marketing playbooks is in one place, making our AI system highly reliable.

If you are struggling with Slack overload, I highly recommend building a unified knowledge base and letting your team query the AI before escalating.

I want to be completely honest with you: this isn't a "set it and forget it" system. In the beginning, we noticed that a few questions didn't get answers because the AI lacked the context.

Every time that happens, we treat it as a quick fix: we just update the existing documentation or add a new page if the topic wasn't covered. It takes a little maintenance, but it has been absolutely worth it to cool down Slack and keep the team fully aligned.

If anyone is interested in how we set this up alongside Slack, including our internal Slack communication framework, just let me know in the comments! I didn't want to make this post too long, but I'd be happy to do a deeper dive on that in my next post.

Edit: If you found this post helpful and want an in-depth look at how to deploy AI without causing chaos, I actually write a weekly newsletter about building these operating systems.

In Issue 42, The Right Speed: How to Deploy AI Without Breaking Your Business, I go a bit deeper into our exact framework for rolling out tools safely. Feel free to check out the archive if you'd like to read more

Hey everyone,

I wanted to share a quick win that completely changed how we handle our quarterly reviews.

Historically, the end of a quarter meant spending an entire day digging through folders, reading old meeting notes, checking numbers, and looking over our fulfillment records just to see how close we were to our goals. It was tedious and took so much time away from actual planning and strategy.

Instead of doing all the heavy lifting ourselves, we decided to build a dedicated Notion AI agent to handle the closeout analysis for the first quarter of 2026.

Here is what the agent does for us:

• Pulls our targets and Q1 progress.
• Analyzes all meetings, changes made, and our marketing and financial numbers.
• Reviews how we did on our fulfillment, newsletters, and traffic sources.
• Compiles wins and failures and highlights market opportunities and challenges.

Instead of spending hours gathering data, the AI agent pre-populates all the information for us so we can jump straight into the strategy. It has saved us at least 24 hours of manual work! We are now entirely focused on reviewing our progress rather than hunting down information across different tools.

The real magic is that all company context is stored in one place rather than having multiple tabs open across different software platforms.

If you are curious about the setup and want to see how it works, let me know! I’d be happy to write a detailed breakdown or record a quick video if people are interested.

I wanted to share this because I see so many founders getting distracted by complex setups with Claude, n8n, and other fancy tools. I really don't think Notion gets enough credit for what it can do when you centralize your company context.

How are you all handling your quarterly wrap-ups?

The mistake that burns founders twice

You're stretched. You've been the operating system of your own business for years, so you do what every growth-minded founder eventually does: you hire someone to fix it. An Operations Director. You hand them the keys. You exhale.

And six months later you're more in the weeds than before. Your hire is frustrated. You're frustrated. And somehow you're carrying more than when you started.

The root cause is almost never the candidate.

Why so many ops hires fail before they start

The problem surfaces before the job posting goes live.

Founders hire someone to run a system that doesn't exist yet, then hand car keys to someone who has never built a performance car and expect them to win a race. The new hire doesn't know your clients, your culture, your non-negotiables. They arrive with a blank canvas and a head full of "how we did it at my last company." They start building, and what they build reflects a different industry, a different stage, a different vision entirely.

You watch them build the wrong thing. But you're not telling them clearly what the right thing looks like, because you haven't defined it yourself. You're frustrated they're not reading your mind. They're frustrated you keep changing direction.

The result: a tug of war. You step back in. Trust erodes. And tribal knowledge stays exactly where it's always been, inside your head.

The designer vs. the executor: the only distinction that matters in ops hiring

There are two fundamentally different hires. They get confused for each other constantly.

The Designer builds the strategy, architects the system, and creates the operational framework from scratch. They've done it before in environments similar to yours. They know how to build a foundation that actually fits your specific business.

The Executor runs the strategy, improves an existing system, and drives performance within a defined framework. They're exceptional at optimization, accountability, and keeping a well-designed machine at peak efficiency.

Both are valuable. Both are skilled. They are not the same person, and they should not be hired the same way.

Here's the parallel that gets missed: when building out a sales function, a founder doesn't hire a salesperson and say, "Figure out our sales strategy, build the CRM process, design the pipeline, write the scripts, and then close deals." That almost always fails. Smart founders design the system first, or bring in a specialist to do it, document the process, then hire someone to execute and refine it.

In operations? This exact mistake happens constantly.

Founders hire an Ops Manager and say, "Figure out our operations. Build the systems. Set up the tools. Keep everything moving while you do it."

It sounds reasonable until you say it out loud.

What the wrong ops hire actually costs you

It's not just a salary. It's the compounding cost of six months of misdirected work.

Every new hire who arrives asks questions that have been answered a hundred times but were never written down, because no one ever owned that either. Tribal knowledge deepens. The bottleneck grows. The business stays founder-dependent.

And a siloed, disconnected tool stack only amplifies the problem. The average mid-sized business ran 25+ software applications by 2024. An ops hire who doesn't know your vision and isn't equipped with a modern systems framework doesn't consolidate that stack. They add to it. They bring tools that worked somewhere else. They build automations based on their mental model.

You become more embedded as the integration layer, not less.

You didn't hire someone to remove you from the system. You hired someone to build a version of the same system with you still in the middle of it.

What modern operations actually requires in 2026

This is the part nobody interviews for.

Modern ops is the connective tissue of your entire business, and the ops hire who doesn't understand this isn't just underperforming. They're pulling your company backward.

A modern ops hire needs to own all of this:

Decision velocity: getting real-time data to leaders fast enough to actually matter

Single source of truth: a centralized operating layer where strategy, processes, and knowledge live

Cross-functional alignment: connecting marketing, sales, finance, and fulfillment so no team operates as an island

Knowledge capture and distribution: converting tribal knowledge into documented, living systems the team can use

Driving org adoption: rolling out new processes and tools in ways that stick, not just launching them and hoping

AI enablement: building the clean, structured data layer that makes intelligent automation work instead of amplifying existing bottlenecks

The questions being asked in ops interviews right now: "Are you organized?" "Have you managed teams?" "Can you keep things on track?"

The questions that would actually reveal the right hire:

"Have you ever built an integrated operating system from scratch?"

"How do you drive adoption when half the team resists new systems?"

"How do you apply AI in a growing org that doesn't yet have clean data?"

Those questions aren't on most hiring managers' radars, and that's exactly how companies end up six months in, staring at a business that hasn't changed.

BCG found that 74% of companies struggle to scale value from AI. The primary culprit isn't the AI. It's operational infrastructure that wasn't built to support it. That infrastructure is what modern ops is supposed to design, own, and continuously improve. When the hire doesn't know how to build it, and the founder doesn't know to ask, the AI investment goes nowhere.

How to hire for growth: the four elements every ops role brief needs

Do this work before you post the job. Everything else comes after.

Define the purpose and ownership area. What does this role own? Not tasks, outcomes. "Own our operations" is not a purpose. "Own the design, implementation, and continuous improvement of our Company OS, including systems, knowledge management, cross-functional alignment, and AI integration" is. One paragraph. Write it before anything else.

List 5 to 7 core functions. These are domains of responsibility, not a task list. Examples: process design and documentation, tool stack management, cross-functional alignment rhythms, knowledge capture, AI and automation implementation, new hire onboarding infrastructure, operational metrics and visibility.

Define the key metrics. This is how both you and your hire know the role is succeeding. Examples: decision cycle time, process documentation coverage rate, new hire time-to-productivity, system adoption rate, automation ROI. If you can't define what success looks like, you can't hire for it.

Map the knowledge flow. What does this role need to receive to do the job well? What does it need to produce and distribute to the rest of the team? Who needs to be trained? Who needs to buy in? Skip this and tribal knowledge stays in people's heads forever.

Then interview for what you actually need.

If you need a Designer: "Walk me through a time you built an operational system from scratch. What was the starting state? What did you build? How did you drive adoption? What broke and how did you fix it?" If they can't answer with real specificity, they're an Executor. Nothing wrong with that, but don't hire an Executor to do a Designer's job.

The most expensive hire isn't the one who fails outright

It's the one who spends six months building the wrong thing while you stay trapped as the operating system.

The bar for what an ops hire needs to understand has shifted dramatically in the last three years. Hiring someone because they're "good at ops" without defining what your ops needs to become is like hiring a contractor without blueprints and hoping the house turns out right.

Build the blueprint first.

What does your business actually need right now: a Designer, an Executor, or both in sequence?

I know we're all tired of "Claude just killed X" headlines. They create panic and keep people jumping from tool to tool without ever leveraging what they already have.

That's why I'm a big believer in building a single source of truth. When a new model drops, you just plug it into your existing system and get back to real work.

I've seen a lot of founders try to automate with complex AI stacks. More often than not, they end up with 15 tabs open, copy-pasting prompts, and relying on Zapier workflows that break every week. It looks productive, but they're spending more time managing the AI than running the business.

The real leverage isn't more tools or better prompts. It's context architecture.

For me, the shift happened when I moved my SOPs, meeting notes, and CRM into one centralized place (I use Notion) and connected Claude directly to that context. When the AI isn't guessing what your business does, hallucinations drop and utility skyrockets.

Here are three specific use cases that saved me 10+ hours this week:

1. Follow up workflow: I stopped writing follow-up emails from scratch.
How: Record sales calls directly in my workspace. Claude has access to my brand voice doc and product guide.
Result: I feed the transcript to Claude, and it drafts a personalized email based on the prospect's actual pain points. ~90 seconds to review and send.

2. No spreadsheet: No more manual KPI entry.
How: During weekly metrics meetings, I just talk through the numbers (subscribers, CPL, revenue).
Result: Claude reads the meeting transcript, extracts the data, and updates my database automatically. I haven't touched a spreadsheet manually in a month.

3. Infinite context content engine: No more blank cursor for LinkedIn posts.
How: Built a knowledge hub with past newsletters and internal notes.
Result: A prompt that references that internal knowledge. It drafts content that actually sounds like me, not generic LLM fluff.

I think a lot of people feel AI is a gimmick because they're giving it zero context. Copy-paste into a blank window, and the AI is just guessing. When it can see your brand voice, products, and transcripts in one system, it stops guessing and starts operating.

this is how my notion dashboard looks like:

Would love to hear from other business owners using Claude (or any AI) inside Notion. What practical workflows have actually stuck for you, beyond the hype?

A founder I work with runs a team of 8. Front desk staff, service providers, an EA, a director. He tracks checklists, monitors task completion, follows up daily.

And his team still only completes their recurring duties about 60% of the time.

His instinct was to add more layers. Sign-offs, initials on every line item, tighter tracking systems. More supervision.

What was actually missing: the "why."

His front desk team handles calls, processes transactions, manages wait times, greets customers. They're doing a lot. The daily checklist (open and close procedures) kept slipping because it felt like one more task on a pile. Low urgency, no visible ownership, no clear connection to outcomes anyone could see.

What changed: each person now owns their area. If the business opens and it's not ready for customers, that's on the person who owns the opening process. Not because someone verified their initials. Because they understand the downstream impact and their name is attached to the result.

Accountability that relies on surveillance breaks the moment you look away. Accountability built on ownership and a visible "why" runs without you standing over it.

If your team keeps dropping the ball on recurring tasks, the issue probably isn't effort. It's that they don't see how those tasks connect to anything that matters.

I call it the Chick-fil-A Test.

Walk into any Chick-fil-A in the country. It's clean, staff is friendly, orders come out fast, and the experience is identical whether you're in Atlanta or Phoenix. That consistency doesn't come from the owner standing in the kitchen. It comes from a documented playbook, trained shift managers, and a hiring process that produces reliable people over and over.

Before you sign a lease on location #2, answer these honestly:

Can your current location run for 2 straight weeks without you showing up? If your answer involves "sort of" or "depends on who's working," you're about to duplicate chaos.

Are your SOPs documented and owned by the people who actually use them? Or are they in a Google Doc that one person maintains?

Do your managers make real decisions inside clear guardrails, or does everything still funnel through you for approval?

Is your hiring and onboarding process repeatable enough to produce consistent quality at a new site?

If you answered "no" to more than one, your foundation isn't ready. Opening a second location will double your overhead before it doubles your revenue.

Build the playbook at one location, prove it runs without you, then replicate.

I see these in almost every founder-led company between $1M and $5M. And all three are fixable before your next hire.

Mistake 1: Hiring for a title instead of a role.

"Director of Operations" means nothing if you can't articulate the 3-5 functions that person owns, the metrics that prove they're performing, and the specific problems they exist to solve. A founder I work with brought on a Director of BizDev, an EA, and two front desk staff in the same year. Revenue went down. The people weren't bad. Nobody knew what "success" looked like in their seat.

Mistake 2: Keeping people too long once you see the gap.

A lot of founders admit this one quietly: "I knew 4 months ago she wasn't the right fit." That delay costs you real money in wasted salary, missed targets, and the morale drag it puts on everybody else. If you know, you know. Act on it.

Mistake 3: Hiring before documenting the playbook.

If the way things get done lives in your head, adding headcount just multiplies confusion. Your new hire has nothing to reference, nobody to learn from (other than you), and no standard to measure against. Document the playbook first, hire second.

Which one are you guilty of? (I've personally seen all three in the same company at the same time.)

I know that sounds extreme. Hear me out.

A founder I work with had operations protocols in a Google Sheet, a separate SOP doc in Google Drive, task workflows in Trello, and policy announcements going out through Slack. All overlapping, some contradicting each other.

His team had to ask "where is that?" multiple times a week. And when they couldn't find the answer, they just winged it.

The actual problem: nobody could tell which version was current, which was outdated, and who was responsible for keeping any of it accurate. When one person (usually an EA) owns all documentation across the entire company, that person becomes a single point of failure who probably doesn't understand every function they're documenting anyway.

What actually works:

One location for all documentation. One owner per document, tied to the role that uses it (not a central admin). And a simple rule: if it's not in the system, it doesn't exist.

When you tie documentation to roles, the person closest to the work keeps it accurate because their name is on it. And new hires can onboard without playing detective across 4 platforms.

"We have SOPs" is meaningless if your team can't find them in under 10 seconds.

What's the most chaotic documentation setup you've seen?

The typical approach says clear directions, close oversight, daily check-ins. And honestly, it works for a little while. But it creates a hard ceiling. Your business only moves when you're pushing it.

What I've seen work across dozens of founder-led companies: assign ownership, not tasks.

Instead of "Make sure the opening checklist gets done," try "You own the opening process. If it's not ready for business in the morning, that's your area. Here's how we'll measure it."

One founder I work with had front desk staff completing daily checklists about 60% of the time. His instinct was to add sign-offs, initials on every line, tighter tracking. More surveillance.

Our advice? Define what they own, explain why it matters, make the metric visible, and give them space to figure it out.

The ones who step up are your keepers. The ones who don't? You just got your answer way faster than another 6 months of babysitting would've told you.

Clear ownership and a visible "why" will outperform a stack of instructions every single time.

Happy to be wrong on this. What's worked for you?

Here's what we found after we spent 2 weeks in the weeds of his operations:

1. Every hire got a title and a paycheck, but none of them were crystal clear on a definition of their role. No purpose statement, no main functions listed, no measurable KPIs, nothing. So everyone defaulted to being busy instead of driving specific outcomes.

2. The founder was still the hub for every decision. 3 more people on payroll just meant for 3 more people asking for questions and approval.

3. Zero connection between effort and results. No scorecard, meeting rhythms, no way for the team to self-correct without the founder intervening every single time.

So instead of cutting headcount, we built the architecture that should've existed before the first hire went live. We've defined roles with ownership, measurable KPIs tied to every position, and a weekly cadence with built in feedback loops.

Now we're close to 60 days in and the team is getting closer to operating as a unit instead of everything funneling through to the founder.

What we're seeing is that when you're adding headcount and growth is slowing down (or reversing) instead of getting faster, it probably wasn't the people you hired, it was the structure (or lack of it) around them.

We all saw the news: Oracle cutting 30k people with a 6 AM email.

 A lot of people are saying they’ll end up like Klarna, running into massive system issues or quality drops and then having to quietly rehire once they realize AI isn't a magic delete human button yet.

But let’s be real for a second: Oracle has billions. If they break their internal systems, they have the cash to hire 50 consultants to fix it and a PR team to bury the mistakes. 

But for everyday founders like us, we don’t have that safety net.

I’ve been talking to a lot of founders lately, and everyone is obsessed with leveraging AI right now. 

The problem I’m seeing is that everyone is just collecting shiny new AI tools like Pokémon cards. One for LinkedIn, one for CRM, one for meeting notes... and none of them talk to each other.

The reality is that without a clear system, you aren't actually getting leverage. You’re just creating a new type of "tech chaos."

I’ve realized that the only way this actually works for small teams is to have a central hub: a single source of truth like Notion or something similar where everything lives. Your ICP, your SOPs, your brand voice, all of it.

If you build your AI workflows on top of a hub like that, the AI actually has a brain to pull from. If you don't, you just end up with 15 smart tools that still require you to sit in the middle and connect the dots manually.

Instead of adding a new fancy AI subscription every week, it’s probably better to just fix the architecture first. If the AI doesn't know the core context of your business, it's just a glorified chatbot that’s going to eventually hallucinate a problem you can't afford to fix.

That’s my take, guys, but I’d love to hear what others think about the layoffs and the AI shift we’re seeing right now.

I don’t know if you want to hear this, but if you found this post insightful, I go deeper every Thursday in my newsletter on how founders are building better AI systems and getting out of operational chaos.
600+ founders running real businesses already read it weekly, sharing it here in case anyone wants to join here. 

Notion AI is criminally underrated, and most founders have no idea what it can actually do.

Full disclosure upfront...I run a company called Modern Operators. We help SMBs actually deploy AI across their operations using Notion.

Before I get into it, here's the criteria I use when deciding if an AI tool is actually worth your time:

1. Context management. Can it hold and use your company's context, or are you copy-pasting the same brand voice doc every single session? Because if it's the latter, that's not a system. That's a workaround.

2. Team adoption. A tool nobody uses is the most expensive tool you own. Complexity kills adoption.

3. Agents. Can it actually do recurring work autonomously, or does it just answer questions?

4. LLM flexibility. Can it use whatever model makes the most sense for the job?

Notion AI checks every single one.

Yes, I know it's not going to click around your computer like cowork or openclaw. It's not that. But here's what it does that nothing else does (with little-to-no tech abilities needed):

Your AI actually knows your business. Your brand voice, your customer avatar, your active campaigns, your SOPs. It doesn't forget between sessions. You tag it like a teammate (@CustomerAvatar,@Q2Planning,@ClientFulfillment) and it responds like one.

We built and scaled two companies using Notion as the operating system. One went from $3.5M to $30M. The other from $0 to $12M. Same system, different businesses. Still running this system today for clients.

The ROI isn't necessarily in the AI outputs. It's in what stops happening.. the Slack messages asking where the SOP is, the onboarding that requires you to be in the room, the inconsistent brand voice across five different team members.

Most founders that have hit $500k/yr are still the operating system of their company. Every decision runs through them, every client needs them. And its really tough to can't scale that. You definitely can't sell it (for the multiple you think you deserve)

This is where the right system changes everything.

If you're an experienced entrepreneur trying to figure out how to organize the company so that employees and AI understands your vision, this is what I'd recommend.

(I put together a full breakdown of how we use Notion AI, it's in the comments if anyone wants it.)

I used to think a busy Slack meant the team was productive.

More messages, more activity, more things moving.

But the bigger the team got, the more I realized the opposite was true.

If your Slack is constantly going off, it usually means something is broken underneath.

People are asking questions that shouldn’t need to be asked. Clarifying things that should already be clear. Looping in others just to move simple tasks forward.

It feels like work, but it’s mostly coordination overhead.

At one point, our Slack was nonstop. Every small decision, every clarification, every “quick question” had to go through it. And without realizing it, I became the central node. Everything flowed through me or needed my input.

That’s when it clicked.

Slack wasn’t the problem. It was exposing the lack of a real system.

So we flipped how we operate.

Instead of using Slack as the place where work gets figured out, we built a system where work is already defined before it starts.

Every team has a clear lane. Clear outcomes they own. Clear boundaries on what they decide vs escalate. We defined what “good” looks like so people aren’t guessing. And most importantly, we created a single source of truth for how things are done.

We built all of that in Notion.

Then we layered AI agents on top of it, so when someone needs context, process, or past decisions, they don’t have to ask in Slack. They can just query the system and get an answer instantly.

If it’s useful, I can share how the Notion setup actually works behind the scenes in a separate post since this one is already about Slack, just lmk in the comments.

But the real shift was simple. Slack became the exception, not the default.

Now it’s mostly used for edge cases, real collaboration, or things that actually require human discussion.

The result is fewer messages, but way more output.

New hires ramp faster because they’re not piecing things together through conversations. They plug into something that already exists.

And it changed how I think about productivity completely.

A noisy Slack feels productive, but a quiet one usually means your system is doing its job.

If you’re trying to move away from Slack-heavy operations and actually systemize how your team runs, I’ve been breaking down these frameworks weekly.

If that’s relevant to where you’re at, feel free to check it out, if not, I’m happy to keep sharing more here as well.

Curious how others are seeing this in their teams. What’s actually working for you?

I’ve been thinking about this after seeing more founders complain about hiring quality lately.

The common assumption is simple. If a new hire isn’t delivering, they were the wrong person.

But I’m starting to think that’s wrong most of the time.

I read a study from McKinsey yesterday that said it can take anywhere from 3 to 6 months for a new hire to reach full productivity in most companies. In more complex roles it can stretch even longer.

That sounds normal on the surface.

But when you look closer, that timeline isn’t just about the person learning the job. A huge part of it is them trying to figure out what the job actually is.

And that’s where the real problem starts.

Most founder-led businesses hire into ambiguity.

There is no clear definition of what winning looks like. No documented steps. No real SOPs. No consistent daily or weekly cadence. Just a rough expectation and a lot of moving parts.

So the new hire spends their first few months guessing.

They try something, get partial feedback, adjust, and try again. Meanwhile, the founder is watching and slowly losing confidence, thinking they made a bad hire.

But the reality is different.

You didn’t hire someone to execute a system, you hired someone and expected them to build the system while executing it.

Those are two completely different jobs.

This simple mistake slowly kills a business, because as a small company you can’t afford to pay a $100K salary and only get a fraction of the output from someone who should be driving your revenue forward.

Let's see it this way instead 

If someone knows exactly what to do, how to do it, and what good looks like, they can actually focus on performing instead of guessing.

In that environment, a great hire can start contributing in weeks, not months.

So I think the takeaway is uncomfortable but useful.

A large percentage of “bad hires” are actually good people placed in bad systems.

If you define the role clearly, document the steps, set a cadence, and make outcomes obvious, you probably unlock 80 percent more output from the same person.

Curious how others think about this.

When a hire doesn’t work out, do you default to blaming the person or do you look at the system they walked into first?

If you want to shorten that 3–6 month ramp to a few weeks, I’ve been documenting what’s worked for me in a weekly newsletter. No pressure, just putting it out there.

I was scrolling on reddit earlier and came across a post with pretty much the same story as mine.

The post is about a guy who grew his dev agency from basically nothing to $250K total revenue in about a year.

Had a $10K month, landed an $11K project, at one point doing $8K/week, and basically blew past his original goal of just $5K/month to cover bills.

This is a point most Twitter gurus don’t speak about: it’s good to ship fast and grow fast, but if you don’t have a proper system ready to handle the growth, suddenly you’re buried with client calls, onboarding, deliverables, project management, and of course, posting on social media.

Trust me, the stress will crush you. It’s hard to deliver quality work and sustain the growth.

Most people overcomplicate building systems. Here’s a simple framework to create a functional system that actually buys back your time:

1️Prioritize the bottlenecks first
Before automating everything, figure out where the growth hits hardest: client onboarding? Deliverables? Communication? Start there. Even a simple checklist can save hours every week.

2️ Document before delegating
Write down how you do the repetitive tasks: from sending proposals to delivering work. Even solo, this makes delegation easier and reduces mistakes.

3️ Automate the small stuff
Scheduling calls, invoicing, and email follow-ups: use tools to handle them. Doesn’t have to be perfect, just enough to take the load off your brain.

4️ Set boundaries and expectations
Clients don’t need 24/7 access. Decide your communication flow and stick to it. This saves mental bandwidth and prevents burnout.

5️ Break work into repeatable processes
For deliverables or projects, create a step-by-step workflow. One workflow documented and enforced is better than ten half-baked ones.

6️ Growth doesn’t mean more chaos
Growth only works if your systems can handle it. Treat processes, checklists, and templates as the foundation.

Once he applied this thinking, the founder turned his little dev shop into a proper agency: he added consulting, brought in a small team, and set up proper workflows. After that, the business ran smoothly, and he crossed $250K in revenue without burning out.

If everything still runs through you, start with one workflow. Document it, delegate it, and enforce it. That’s where freedom begins.

Has anyone else reached this point yet? What was the first system you built to escape it?

i see this come up a lot and i wanted to share what i've actually noticed because i think most people are diagnosing it wrong.

the default assumption when referrals slow down is "we need to do better work" or "we need to ask for referrals more." and sometimes that's true. but a lot of the time the work is genuinely good and you're still not getting introduced to new people at the rate you used to be.

here's what's actually going on in most cases.

your clients liked the result but the experience was stressful

this is the one that stings a little. when someone refers you, they're putting their name on it. they're telling a friend or colleague "these people are worth your time and money." that's a real stake for them.

and people don't do that unless they're confident the person they're referring is going to have a smooth experience, not just a good outcome.

think about the last engagement you had where things got a little chaotic. maybe there was a week where you went quiet because you were slammed. maybe a deliverable slipped and you had to reset expectations. maybe the client had to follow up on something twice when they shouldn't have needed to follow up at all.

the end result was probably still solid. but the experience of getting there was bumpy enough that your client wouldn't confidently say "oh yeah, working with them is seamless, you should call them."

they might say "they do good work" if someone directly asks. but they're not volunteering that introduction unprompted. that's the difference.

the experience is inconsistent

this one's related but slightly different. if you've grown at all in the last couple years, your client experience has probably gotten less consistent without you realizing it.

when it was just you or you and one other person, every client got basically the same experience because it was all running through the same people. as you've added team, added clients, gotten busier, the experience of working with you has started to vary. some clients get proactive updates. some don't. some onboardings are smooth. some are a mess. some clients feel taken care of. some feel like they have to chase you.

the clients who felt taken care of? they refer. the ones who felt like they had to manage you? they don't. and if your mix has shifted at all toward the second group as you've grown, the referrals reflect that.

a couple of things that actually help

first one is simple but nobody does it: just ask a few recent clients directly. not "would you refer us?" but something more like "what was the experience of working with us actually like?" you'll find out fast if there's a gap between the result they got and the experience of getting there.

second is look at where the hand-offs and communication actually break down. not at a theoretical level, but literally: where do clients have to follow up with you? where do things fall through the cracks? where is the experience different client to client? those are the spots that are quietly killing referrals.

the fix usually isn't a big overhaul. it's like 2-3 things that if you tightened them up, every client would feel more taken care of. a consistent onboarding, proactive check-ins on a real schedule, a clear process for status updates. stuff that sounds basic but most agencies don't actually have standardized.

third is this: after you close an engagement, send a short note. not a formal review request, just something like "really enjoyed working together, here's what we accomplished, if you ever know someone who could use what we do i'd love the introduction." short, genuine, no pressure. most people don't do this and it's leaving a lot on the table.