LinkedIn Post Ideas for COOs

For our first 40 employees, one spreadsheet ran fulfillment, inventory allocation, and customer commitments. I built it. I was proud of it. At 55 employees, it broke in a way that mattered: two regional managers had overlapping edit access, both allocated the same inventory batch to different customers on the same afternoon, and nobody noticed until a customer called asking where their shipment was. We spent 11 days manually reconciling six weeks of allocation history. Three customer relationships took real damage. One churned entirely — a $140K annual account. What I got wrong wasn't building the spreadsheet. At 15 people, it was the right tool — fast, flexible, zero implementation time. What I got wrong was not setting a trigger for when to replace it. I was watching headcount as my scaling signal. I should have been watching concurrent-edit collisions and reconciliation hours per week. We moved to a proper inventory system in six weeks flat, war-room style, because we no longer had the luxury of a normal rollout timeline. The lesson I now apply everywhere: every workaround tool needs an explicit kill criterion set on day one, not discovered during the incident that kills it for you. What's the spreadsheet you're still running past its expiration date?

COOs get hired to add process. My best quarter last year came from deleting it. We had a purchase approval chain requiring four sign-offs for anything over $500 — a threshold set when we were a 20-person company, still in place at 180 people. Average approval time: 6.4 days. Finance wasn't the bottleneck. The chain itself was. I cut it to two approvals under $5,000, one above. Finance kept full visibility through weekly spend reporting instead of pre-approval gatekeeping. Result: approval time dropped from 6.4 days to 9 hours. Procurement cycle time for standard software and equipment purchases fell 71%. Nobody's fraud risk increased — we added a monthly spend audit instead of a four-person pre-check, which actually catches more anomalies than four tired approvers rubber-stamping a form. The bureaucrat stereotype attached to this title exists because most operational "improvement" really is additive — a new dashboard, a new checkpoint, a new form. It feels like progress because it's visible effort. Subtraction doesn't feel like work while you're doing it. It just is the work, most of the time. What process did you delete last quarter, and what actually changed because you did?

Our weekly ops review used to run 90 minutes and cover everything. Now it runs 45 and covers only exceptions. Here's the exact structure. Minutes 0-10: Scorecard, eight metrics, red/yellow/green only. No discussion unless something's yellow or red. Green metrics get zero airtime — that's the whole point. Minutes 10-30: Exceptions only. Each function lead gets two minutes per red or yellow item: what happened, what they're doing about it, what they need from the room. If it's green, they don't present at all that week. Minutes 30-40: One forward-looking risk. Not a status update — something that could become next week's red item. We spend real time here because this is where the review earns its keep. Minutes 40-45: Decisions and owners logged live in the doc, visible to everyone before they leave the room. What escalates beyond this room: anything red for two consecutive weeks automatically gets a dedicated 30-minute session with me and that function lead, separate from the group review. The change that mattered most wasn't the time cut. It was removing the incentive to over-report good news for airtime. Nobody presents just to be seen anymore. Steal the format. The exception-only rule is the part that actually saves the 45 minutes, not the timer.

Three numbers I check every Monday that most operators I know still check monthly. By the time a monthly view flags a problem, you're already six weeks into it. 1. Pipeline-to-capacity ratio. Sales pipeline value divided by fulfillment capacity at current headcount. When this ratio crossed 1.4x two quarters ago, I started hiring for delivery roles five weeks before the sales team even closed the deals — because a monthly view would have had me reacting after the backlog already hurt renewal conversations. 2. Hiring velocity against plan. Not just open reqs — time from req approval to signed offer, tracked weekly. When it drifted from 34 days to 52 days, I found out our comp bands had gone stale against market in one function, three weeks before it would have shown up as a missed quarterly hiring target. 3. Cash conversion cycle, calculated weekly instead of monthly. A four-day drift in receivables looks like noise monthly. Weekly, it's a signal — usually one customer's payment terms slipping, catchable before it becomes a cash crunch. None of these are exotic metrics. The value is entirely in the cadence. Weekly turns each one into an early warning system. Monthly turns it into a postmortem. What do you check weekly that most people in your seat check monthly?

I delayed hiring a logistics manager for six months because the org chart said we weren't "big enough yet." I was wrong, and I can price exactly what it cost. The signals I ignored: two missed SLA commitments per month, climbing to five. A 20% increase in support tickets related to shipping delays. Me personally spending roughly six hours a week on logistics firefighting that should have been someone else's full-time job. The actual cost, tallied afterward: one customer worth $85K annually churned, citing delivery reliability by name in the exit conversation. Two of my own direct reports told me later they'd nearly left that quarter — not because of the logistics problems directly, but because they watched me visibly burning out on work beneath my role and lost some confidence in my judgment. I finally made the hire when the math became undeniable. Within eight weeks of the new manager starting, missed SLAs dropped to zero and my own six hours a week came back. The lesson: "we're not big enough yet" is a headcount-planning heuristic, not a data point. I should have been tracking SLA misses and my own time allocation as the actual trigger, not a headcount threshold pulled from a planning spreadsheet. What hire did you delay too long, and what did it actually cost?

The most common question I get from founders considering their first COO hire: how do you actually split decisions without constant friction? Here's our real decision rights matrix, not the idealized version. CEO owns: fundraising, board relationships, product vision, and any decision involving a founder-level relationship — key partnerships, key early customers who joined because of her personally. I own: hiring below VP level, vendor selection, all operating cadence and process, and budget execution once the board approves the top-line number. Shared, discussed before either of us acts alone: any hire at VP or above, pricing changes, and anything that touches company culture visibly — return-to-office policy was the one that took us three long conversations to align on. The one ambiguity that still causes friction, eighteen months in: when an operational decision has a strategic-feeling consequence. I cut an underperforming product line last quarter as an operating call. She saw it, correctly, as a strategic signal to the market that I hadn't fully considered. We didn't have a rule for that boundary and we still don't, cleanly. What we do have now: a standing rule that either of us can pull anything into the shared bucket, no questions asked, if it feels bigger than it looked at the start. Founders evaluating a COO hire: ask for the real matrix, not the mission statement version.

Scaling from 50 to 200 people, the systems broke in a specific, predictable order. If you're heading toward this range, prepare for this sequence. First to break, around 65 people: onboarding. What worked as a founder walking new hires around personally stopped scaling the week we hired four people in one month. Ramp time to productivity quietly doubled before anyone measured it. Second, around 90 people: internal communication. Slack channels that worked for company-wide visibility at 50 people became noise at 90. Decisions started getting made in threads half the company never saw, and we had two instances of conflicting guidance going out to customers because two teams didn't know the other had already answered. Third, around 120 people: procurement. What used to be me buying a laptop on a company card became six people independently buying software that did the same thing, discovered a year later during a cost audit — $60,000 in redundant tooling spend. Fourth, around 160 people: planning. Quarterly planning that fit on two pages at 50 people needed a genuine cross-functional process by 160, or teams optimized locally against goals that quietly conflicted. The pattern: each system held roughly 30-40% past the headcount where it was designed to work, then failed all at once rather than gradually. If you're at 60 people today, you have maybe one quarter before onboarding breaks. Start there.

One day a quarter, I take support tickets myself. No observing, no shadowing — an actual queue, with my name on the responses. I started this after a dashboard told me CSAT was steady at 91% for two straight quarters while, separately, our churn ticked up 2 points. The dashboard and the reality had quietly decoupled. What the ticket queue told me that the dashboard didn't: a huge share of "resolved, satisfied" tickets were customers giving up on a feature request, not getting a fix, and rating the interaction well because the support rep was pleasant. The dashboard measured interaction quality. It had nothing to say about product gaps compounding underneath it. Since I started doing this, I've personally routed three product roadmap items directly from ticket patterns I saw firsthand — items that had been sitting in a backlog for two quarters because they arrived through the support team's monthly summary, filtered and softened by the time they reached leadership. It also changes how the support team sees operations leadership. When I take a bad ticket badly, in real time, with a customer as frustrated as they can get, my team stops treating my dashboards as the whole truth either. Walk the floor, whatever your floor is. The summary of the ground truth is never the ground truth.

Eight months into deploying AI across our operations function, here's the honest split — not the vendor pitch version. Where it works, measurably: document processing. Invoice matching that took our AP team an average of 14 minutes per exception now takes under 3, with accuracy that's actually higher than our manual baseline once we tuned it for our specific vendor formats. Demand forecasting improved our inventory accuracy by roughly 12 percentage points once we fed it two years of seasonal data instead of relying on the vendor's generic model. Where it flails: anything requiring judgment about an exception it hasn't seen. We tried AI-assisted customer escalation triage. It routed a genuinely urgent enterprise account complaint to standard queue three times in the pilot month because the account hadn't triggered any of its "high value" flags — the customer was newly expanded and the system hadn't caught up. A junior human support rep would have read the tone and escalated it in ten seconds. The pattern across both: AI is excellent at high-volume, well-bounded, pattern-repeating work. It's unreliable at anything requiring context the data doesn't capture yet, which in operations is usually exactly the moment things are going wrong. Operators who deploy it for the first category and keep humans firmly on the second are getting real returns. Operators betting on the second are getting expensive demos. Where has it actually worked for you?

Every company I've operated has at least one process that's clearly broken, that everyone works around, and that nobody has fixed because it's not quite bad enough to force the issue. Ours: our expense reimbursement system requires three different logins across two systems that don't talk to each other, and takes the average employee 22 minutes to submit a routine expense report. We know it's broken. We've known for over a year. It's never made the top three priorities in any planning cycle because nothing catastrophic has happened yet — just a slow, steady tax on 180 people's time that never shows up as a single dramatic incident. Operators, I want your version. What's the operationally broken thing your company tolerates because it's a thousand small cuts instead of one visible wound? I'm asking partly out of curiosity and partly because I suspect the answers will tell me more about where real efficiency gains are hiding across companies our size than any benchmarking report would. The catastrophic failures get fixed fast because they have to be. It's the tolerable ones that quietly cost the most over time.