What a Fractional COO Actually Does, Week to Week

People hear "fractional COO" and picture someone tightening up your Slack channels and building an org chart. Sometimes that's part of it. But if that's all you're getting, you're underusing the role, and probably overpaying for it.

The COO title gets attached to a lot of different jobs. Mine skews technical. I'm not coming in to run payroll or manage your office lease (though I can!). I'm coming in because the operational problems at an early-stage tech company are usually tech problems wearing an ops costume: the stack doesn't talk to itself, the thing you built for one client can't be sold to the next one without a rebuild, and your engineers are in the room for sales calls because nobody else can answer the questions that actually get asked.

Here's what that my work in this space looks like in practice.

Tech stack and vendor selection

Most early-stage companies accumulate their stack the way you accumulate junk mail: one tool at a time, each one a reasonable decision in isolation, none of them talked to each other. Part of the job is going through that stack line by line and asking what's actually earning its keep, what's redundant, and what's about to become a liability as you scale. This isn't a preference exercise. It's understanding what a vendor's contract actually commits you to, what happens when you outgrow the platform, and where the integration gaps are going to cost you six months from now instead of today.

Productization

This is the one people don't expect from a COO, and it's often where the highest-leverage work is. Early companies build things for one client and then discover, too late, that the thing isn't a product. It's a bespoke solution wearing a product's clothes. Turning that into something repeatable, something you can sell to client two and three without rebuilding the whole thing from scratch, is an operational problem before it's an engineering one. It touches pricing, packaging, documentation, and what your sales team is actually allowed to promise. I worked with one AI startup where this was the whole engagement: taking a service that had been delivered manually, client by client, and figuring out what needed to be systematized before it could scale.

Technical sales support

Founders and early sales hires are often selling something they can only half explain, because the technical depth lives with the engineers and the engineers aren't in the room. Part of my job is filling in that gap. That means being able to answer the hard technical question on a sales call without pulling in an engineer every time, and also making sure sales isn't promising something that the product can't deliver. It's a translation function, and it only works if you actually understand both sides well enough to be trusted by both sides.

Cross-functional quarterbacking

The through-line across all of this is the same one I use in my legal practice: I'm not trying to be the smartest person in every room. I'm trying to make sure the right specialist is in the right room at the right time, and that nothing falls through the cracks between functions because everyone assumed someone else owned it. At a ten-person company, that connective tissue often doesn't exist yet. Someone has to hold the whole picture. That's usually me.

None of this is about running your standups or building you a wiki (although sometimes that happens too) because the operational basics still have to work. The actual value is in the technical judgment: knowing which vendor decision matters and which doesn't, knowing when something is ready to productize and when it isn't, knowing how to keep sales and engineering honest with each other.

If your ops problems keep turning out to be tech problems in disguise, that's usually the sign you need this kind of help rather than a traditional operator.

—James