What an embedded operator actually does

Most outside help arrives as advice. Someone studies how your team works, writes up what should change, and leaves you to make it happen. That works when the missing piece is knowledge. It fails when the missing piece is time, because the people who would carry out the recommendations are the same people who were too busy to fix things in the first place.

An embedded operator fills that second gap. They join your team for a period, do the work themselves, and stay until the new way of working holds up without them. At Crosshatch, every engagement is built around this.

What an embedded operator does day to day

The work changes with the client, but the pattern is steady. In the first weeks the operator mostly watches and asks. How does a request come in? Who touches it? Where does it wait? Which steps depend on one person remembering to do them? The answers rarely match what the team would have written down in a meeting, and that gap is where most of the fixes are.

Then they start doing. If the problem is video production, they produce video. If it's a reporting mess, they build the report and run it every week. If a team has nobody steering it, they run its planning and priorities until someone permanent takes over. Doing the work is how you find out what breaks at real volume, which a plan on paper won't tell you.

Everything they build gets written down as they go: the SOP for the process, the prompt library for the video pipeline, the notes on why an automation is set up the way it is. We run this in four passes (find, build, run, hand over), and each pass leaves the team with something it keeps.

How it compares with hiring or a consultant

There are three common ways to fix a broken process.

You can hire someone. That's the right answer when the work is permanent and you know what the role is. It's slow when you don't, because you end up recruiting for a job you can't describe yet, and the new hire spends their first months working out what the job is.

You can bring in a consultant. You get an outside view and a set of recommendations, and then the problem comes back to you with a document attached.

An embedded operator sits between the two. They carry the work like an employee for as long as it takes to make it stable, and they leave like a consultant once it is. The engagement ends with a process your own people can run, the documentation behind it, and usually a clearer idea of what the permanent role should be if you still need one.

What a good engagement leaves behind

We hold our own work to one test: if the operator left tomorrow, could the team carry on? Early in an engagement the answer is no, and that's expected. By the end it has to be yes. In practice that means:

• The process is written down in a form people actually open. (More on that in how to write SOPs people use.)
• Anything that ran on someone's memory now runs on a checklist, a schedule or an automation.
• One named person on your team owns each part of it.
• The team has run it themselves, with the operator watching, more than once.

If any of those is missing, the handover isn't finished, however good the new process looks.

When it's the wrong fit

Embedding someone works best when the problem is operational and the fix needs hands. It's a poor fit for pure strategy questions, where a short advisory engagement costs less, and for work that is clearly permanent from day one, where you should just hire.

It also needs real access. The operator has to be able to use your tools, sit with the people doing the work, and reach whoever approves changes. An operator kept at arm's length turns back into a consultant.

How engagements are priced

We bill embedded operators by the month, because the work is ongoing and the scope moves with what we find. Defined pieces of work, like building a specific automation or writing a set of SOPs, are scoped as projects and billed by the hour. Most clients use both: an operator for the running work, and projects for the pieces with a clear finish line.