blog

You didn't plan to end up in Operations. Neither did most of us.

Madeline — Sun, 29 Mar 2026 12:58:29 GMT

Operations professionals seldom spring up from intentional or calculated educational and work experiences.

While there are "Operations" majors and specific roles that might have helped along the way — most of us arrived here sideways — through a role that kept expanding, a problem that kept sliding into our Slack DMs, a skill set that turned out to be weirdly applicable to something nobody else wanted to do.

Coming from personal experience, that can feel isolating in ways that are hard to explain to people inside and outside of it. You look around at your peers in other functions and they have a language for what they do, a clear professional identity, a body of literature and certification pathways that validates their expertise. Operations often doesn't offer that in the same way. So you can find yourself questioning the very fiber of what you know — wondering if what you're doing is a real discipline or just a collection of things that fell to you because you were good at figuring things out.

I've been there. I'm still there.

But I've started to think about it differently. Because the thing that can make operations feel illegitimate is actually one its greatest strengths.

The fact that ops professionals come from all different sides of a business — often multiple sides, across multiple industries, in the same career — means that the strategies and instincts that make operations special have endless applications. We aren't trained to see one function. We're trained to see how functions connect. That's not a gap in our credentials. That's the credential.

This mindset is relatively new to me, partly because I'm relatively new to operations. I came by way of customer experience before I landed here, and for a while it felt like I was still catching up to people who had been doing "real ops" their whole careers.

What shifted it for me was looking at it through a different lens. My older sister is also in operations — she got here before me, and in a lot of ways it feels like joining a family business and following in her footsteps. But here's the thing: she came from economics. I came from anthropology and psychology. Which means our understanding of operations, our approaches to problems, and the specific abilities we bring to the work are fundamentally different.

Most of the time that makes me feel insecure (thank you childhood trauma), but it should be celebrated.

Not managed. Not reconciled into some unified methodology. Celebrated. Because the ops professional who came up through finance sees risk and structure in a way I don't. The one who came through customer experience — hi — sees the human side of a process in a way a pure analyst might miss. The one who came through marketing understands how to communicate change and build buy-in. We all ended up in the same place. We got here very differently. That diversity of etiology is what makes a strong ops function, whether that's a team of one or a team of twenty.

If you're new to thinking of yourself as an operations professional — if you're still in the phase where you're not quite sure you've earned the title — I'd offer this: the winding road that got you here isn't a liability to explain away. It's the thing that makes you good at this.

You didn't plan to end up in operations. Neither did most of us. We're in good company.

What If Your Company Had an Operating System?

Madeline — Fri, 27 Mar 2026 19:48:59 GMT

Here's a question I've been sitting with for a while: if you asked your leadership team right now — not in a meeting, not with prep time, just off the top of their head — to describe how your company operates, how consistent would their answers be?

Not the mission. Not the values. The actual mechanics. Who owns what. What processes run the business. How you know when something is working or broken.

My guess, based on having been in and around operations roles for the better part of a decade, is that the answers would be wildly different. Not because anyone is wrong, but because most companies don't have a single place where that information lives. It's scattered across a Notion that nobody updates, a Confluence that nobody reads, an org chart that's three reorgs out of date, and the institutional memory of two or three people who've been around long enough to know how things actually work.

That's fine when a company is small. When you're 15 people, the operating system is basically the founders' brains. When you're 50 people, that stops working. When you're 150 people, the absence of a real operating system is costing you in ways you can measure — slow onboarding, inconsistent execution, accountability gaps, leadership flying blind until something breaks.

Ops OS is starting as a template library because that's the most immediate, tangible problem to solve. Most companies don't have documented processes. Most RevOps leads don't have a starting point. The playbooks give you something to work with today.

But the bigger idea is this: what if you had a platform that could show you, in real time, how your company was actually operating? Not based on what people reported. Based on what was actually happening in your tools. Whether your pipeline review got done. Whether deals are stalling. Whether onboarding is on track. Whether the processes you built are being followed.

That's what Ops OS is being built to become. A layer above your existing tools that connects documentation, ownership, and real operational data into one view.

We're building it from the ground up, starting with the templates, because the people who use the templates understand the problem most clearly. The platform will be shaped by what they actually need — not what a product team assumed they needed from a distance.

If you've ever been the person responsible for making a company run better and felt like you were doing it without the right tools, that's exactly who this is for.

The operating system layer is missing. We're building it.

If this resonates, we would love to hear from you. Leave a comment below!

GTM Ops: Your Launch Plan Exists. It's Just Not Written Down.

Megan — Fri, 27 Mar 2026 19:43:01 GMT

Most GTM failures I've seen weren't failures of strategy. The strategy was usually fine. The positioning was thought through, the timing made sense, the team was capable. What broke was the execution layer — the handoffs, the dependencies, the twenty small decisions that needed to happen in the right order by the right people.

That's a different problem than "we didn't have a plan." It's closer to: the plan existed in a slide deck and a few people's inboxes, and when the quarter got busy and capacity got thin, the gaps started showing.

GTM Ops sits at the intersection of Marketing, Sales, and Product — which sounds like a privilege until you realise it means you're the person coordinating across three teams with three different prioritisation systems, none of which were designed to talk to each other. Campaign assets depend on Product timelines. Sales enablement depends on campaign assets. Field events depend on all of the above. When one thing slips — and something always slips — the whole sequence compresses.

What I've found is that most GTM teams aren't under-strategic. They're under-documented. The campaign brief exists but the execution checklist doesn't. The launch timeline exists but nobody owns the dependencies. The post-mortem happens but the learnings don't make it into the next launch process.

Coming from marketing, I used to bristle at the idea of systematising creative work. It felt reductive — like turning a campaign into a conveyor belt. What I actually found is the opposite. When the coordination layer is documented and owned, the creative work gets better. You're not spending your best thinking on remembering steps. You're spending it on the work that actually needs your judgment.

The GTM Ops playbook is being built for operators who are good at their jobs, working with good teams, and still finding that launches feel harder than they should. Not because anyone is dropping the ball — but because the ball is being passed between four people with no defined handoff.

That's a process problem. And process problems have solutions.

People Ops Is Just Operations. It Happens to Involve Humans.

Megan — Fri, 27 Mar 2026 11:55:23 GMT

There's still a version of People Ops in a lot of companies that is basically HR paperwork plus a vibe. Benefits administration, compliance, the occasional virtual team event, and a strong intuition about whether someone is a "culture fit."

That's not people operations. That's people administration.

People Ops, done properly, is one of the most process-intensive functions in the whole company. Hiring has a funnel. Onboarding has stages. Performance reviews have a cadence. Offboarding has a checklist that, if skipped, creates real legal and operational risk. Every one of those things is a process that can be documented, owned, and improved over time.

I ended up in operations partly because I'm the kind of person who, when faced with a recurring task, immediately wants to write down the steps. It drives some people crazy. In People Ops, it's the whole job.

The People Ops playbook is being built for operators who own the people systems — usually as one part of a broader ops role — and need a starting point that isn't just "copy what we did at the last company and hope it fits."

It covers hiring process from intake to offer, onboarding from day one through 90 days, the performance review cycle, and offboarding — including the parts nobody wants to think about until they absolutely have to.

Good people processes make a company feel like a place worth working at. That's not soft. That's strategic.

Why Customer Success Operations Is the Most Underbuilt Function in Most Companies

Madeline — Fri, 27 Mar 2026 11:55:13 GMT

Customer Success has had a bit of a moment over the last few years. Almost every SaaS company has a CS team now. What most of them don't have is a CS operations function — the documented processes, the structured handoffs, the consistency that turns a good CS team into a reliable revenue engine.

The result is CS teams that are full of talented, customer-obsessed people running on instinct and tribal knowledge. The best CSM knows exactly how to run an onboarding. The problem is that knowledge lives in their head and not in a document, which means when they leave — and eventually everyone leaves — that knowledge walks out the door with them.

I came up through customer experience before I moved into operations, and I saw this pattern everywhere. Great individuals. Inconsistent processes. High effort, variable outcomes.

The Customer Success Ops playbook is being built around the moments that matter most in the customer lifecycle: the first 30 days after a deal closes, the quarterly business review, the health check call, the escalation that comes in at 5pm on a Friday, and the renewal conversation that determines whether you retain the revenue.

Each of those moments deserves a documented process — not a script, but a framework. Who owns it. What the trigger is. What the steps are. What success looks like. What happens if it goes wrong.

That's what we're building. Because your best CSM shouldn't be your only CSM who knows how to do it.

Your CRM Is Lying to You (And It's Probably Your Fault)

Madeline — Wed, 25 Mar 2026 19:32:54 GMT

Either you know someone or are someone who lets the CRM get bad. But let's be honest, it was probably a team effort. I personally have been the person who let the CRM get bad. I understand how it happens. I have also been the person cleaning up said CRM spending hours filtering through stale leads, broken companies, and duplicate contacts.

As someone who has been on both sides, I understand that one missed update easily becomes two, two becomes ten, ten becomes "we don't really trust the CRM data" which becomes "so why are we even using it."

The CRM hygiene audit SOP is the least glamorous thing in this playbook and probably the most important. Thirty minutes, every Monday morning, before the week gets away from you. You're looking for seven things: deals with no owner, deals with stale close dates, deals missing a next step, deals with no value recorded, duplicate contacts, closed-lost deals with no reason recorded, and contacts not attached to a company.

That's it. Seven checks. Thirty minutes. Every week.

The reason this matters beyond the obvious is that everything downstream depends on it. Your pipeline review is only useful if the pipeline data is accurate. Your forecast is only trustworthy if the deal stages reflect reality. Your board reporting is only credible if someone has been keeping the source data clean.

CRM hygiene is infrastructure. Nobody claps for infrastructure until it breaks.

Why Deals Die in the Negotiation Stage (And How an Approval Process Stops It)

Megan — Wed, 25 Mar 2026 19:32:54 GMT

There's a version of this that has happened at almost every company I've worked at or talked to.

A rep is close to the finish line on a big deal. The prospect asks for a discount. The rep, because they want to close and they have the autonomy to do it, gives a 20% discount on a $120K deal. That's $24K off the table. Nobody approved it. It just... happened.

Multiply that by ten deals a quarter and you've quietly eroded a quarter million dollars in revenue without a single alarm going off.

The deal approval SOP is not about distrust. It's not about micromanaging your sales team. It's about the fact that individual humans, under pressure, make discount decisions that make sense in the moment and don't make sense at the portfolio level.

The process itself is lightweight. Anything over a certain deal size or discount threshold goes through a quick approval — RevOps validates the data, the CRO makes a call, and the answer comes back within 24 hours. That's it. No committees. No three-week legal review. A 24-hour SLA so deals don't stall in the gate.

The thing I've found is that once you put this in place, reps actually like it. It gives them cover. Instead of a prospect grinding them on price and them having to say yes or no on the spot, they can say "let me get you an answer tomorrow." That's a power move, not a weakness.

Build the gate. Make it fast. Watch your margins hold.

The Pipeline Review You Keep Skipping Is Why Your Quarter Is Broken

Madeline — Wed, 25 Mar 2026 19:32:53 GMT

Every RevOps person I've ever talked to has said some version of the same thing: "We know what the problem is, we just don't look at it consistently enough."

That's the pipeline review problem in one sentence.

It's not that your deals are bad. It's that no one is looking at them on a schedule. A deal that stalled three weeks ago was probably salvageable two weeks ago. By the time it shows up in your forecast conversation, it's already a write-off — and your CRO is looking at you like you should have caught it sooner.

You should have. That's not blame, that's just what the weekly pipeline review is for.

The SOP is genuinely not complicated. Every Friday, you pull the pipeline, you flag anything with no activity in 14 days, you flag anything missing a next step, and you make sure someone is accountable for every deal before the week ends. The whole thing takes 45 minutes if you run it tight.

The hard part isn't the process. It's the commitment to doing it every single week without exception — even the week before a holiday, even the week of the all-hands, even when everyone is traveling. Especially then.

If your pipeline review is a "we try to do it most weeks" situation, your forecast is fiction. And somewhere in your gut, you already know that.

The fix is boring. That's the point.

The QBR Prep That Takes Four Weeks (Because One Week Is Always a Disaster)

Megan — Wed, 25 Mar 2026 19:32:52 GMT

I have been part of exactly two kinds of quarterly business reviews in my career.

The first kind: someone opens a blank slide deck the Thursday before the QBR, pulls numbers from three different sources that don't agree with each other, makes some charts at 11pm, and presents something that technically answers the question "how did we do" but raises seventeen new questions that nobody has time to answer.

The second kind: a document that leadership actually read before they walked in, covering the quarter honestly, with a clear view of what's changing next quarter and why.

The difference between those two is a four-week preparation process. Not because QBR prep is complicated — it isn't — but because the data needs to be clean, the analysis needs time to breathe, and the draft needs at least one round of fact-checking before it goes to leadership.

Week one is data. Pull everything, run the hygiene audit, make sure the closed-won and closed-lost records are complete. Week two is analysis — quota attainment, win rates, pipeline by source, what the next quarter looks like. Week three is the draft and the review. Week four is final prep and distribution.

The goal of the meeting is discussion, not data revelation. If leadership is seeing the numbers for the first time in the room, the QBR has already failed.

Send the deck 48 hours before. Put a one-page summary at the front. Let the meeting be about decisions, not catch-up.

Your Forecast Is Only as Good as the Process Behind It

Madeline — Wed, 25 Mar 2026 19:32:52 GMT

I used to work somewhere that did the forecast in a Google Sheet that lived in a folder called "OLD - Forecasting (2)" and everyone was pretty sure that wasn't the right file but no one wanted to be the person who asked.

That's not a joke. That's a real thing that happened in a real company with real investors looking at those numbers.

A forecast isn't just a number. It's a signal of how well your revenue system actually worrks. When a forecast is consistently accurate, it means your CRM data is clean, your reps understand their pipeline, and someone is holding the whole thing together with a consistent methodology. When it's consistently wrong, one of those three things is broken — and usually it's all three.

The monthly forecast SOP is about standardization more than anything else. Commit, Best Case, Pipeline — defined the same way, built the same way, reviewed the same way, every single month. The goal isn't a perfect number. The goal is a number you can learn from, because you built it the same way you built last month's.

Forecast accuracy is a lagging metric. It tells you how well your process worked. Run the process consistently for six months and you'll start to see patterns — which reps over-commit, which deals in which stages actually close, where your assumptions are off. That's the real value.

The forecast is the output. The process is the product.