The main things buyers say about technical services companies, and the real problem underneath all of them.
Before I started OpsWerks, I was the buyer.
I was running a globally distributed engineering team, responsible for both our internal operations and the third-party vendors we brought in to help manage the load. I had the vendor relationships, the quarterly reviews, the authority to renew or walk away. I was sitting in the same seat you're in now.
The moment that changed everything happened on a post-mortem call.
We had just come through a P0 outage. Very public, revenue-impacting. The vendor walked through what happened and what they planned to do. My teams were on the call. We took notes. When the call ended, we dropped into our own internal session and the engineers started throwing out ideas for what we could do differently on our side.
I pulled up the RCA document they had just sent.
It was dated nine months earlier.
Same outage. Same root cause. Same document, essentially. Every proposed fix from nine months ago: changes to the monitoring tools, updates to the runbooks, adjustments to operational processes. None of it had been done. No progress updates. No follow-through. A copy, a paste, and back to business as usual.
I pointed out the date to my team.
No one said anything.
They knew. I knew.
We spent the next three months unwinding from the contract while rebuilding operational ownership in-house, on top of everything else we were already running. No new budget. Just the existing team, carrying more. It took another nine months to stabilize things to the standard we needed. Some of our turnover during that season came from the overwork. That cost still stays with me.
What I couldn't get out of my head was that the vendor people weren't bad. They were capable. But their model had no room for prevention. More incidents meant more headcount deployed. More headcount deployed meant more revenue. Fixing things permanently was, structurally, working against them.
We spent more time in the investigation convincing them the problem existed than we spent solving it. If they had redirected that energy from deflection toward diagnosis, it would have been fixed.
Eventually I made two decisions. Pull most of the work back in-house. And only partner with vendors who worked the way we wanted to work. That second part, figuring out what that even meant, is where OpsWerks started.
For years since, I've paid attention to what buyers say about technical services companies when we're not in the room.
The same complaints come up over and over. Different industries, different sizes, nearly the same words every time.
The senior engineers who won the work aren't the ones who show up to do it.
The urgency disappears the week after you sign.
Anything outside the scope line comes back as a change order.
The engineer you finally got up to speed is gone by next quarter.
And underneath all of them sits the same incentive: the revenue continues while the core problems stay open.
I recognize every one of these. Not from the outside.
I made a version of the same mistake myself, in a room I still think about.
Where the complaints come from. This one is mine.
I sat in that meeting feeling like a genius.
The customer was halfway through their list of problems when I heard one I knew I could solve. I stopped listening. Not on purpose, but I stopped.
I spent 48 hours building the fix and presented it to a full room. Then the senior customer lead spoke.
"Well, what about the bug that causes your junky software to crash every time?"
I had no idea what he was talking about.
I failed because I decided what that customer needed instead of finding out. The thing actually crashing their system sat untouched while I built them something nobody asked for.
Here's what took me years to see. Nothing punished me for it. The work was real, the hours were billable, and everything the company measured me on I had done well.
The only thing I got wrong was the part nobody was checking.
That gap is the business model. The complaints are what it looks like from your side of the table.
The complaint: the senior engineers who won the work aren't the ones who show up to do it.
You've met the senior engineers.
They came to the meetings before you signed. Sharp, specific, clearly not their first time. They asked the kind of questions that told you they understood systems like yours, and you left thinking these are the people I want on this.
Then the work started and you never saw them again.
I know how the subtler version of this works, because I lived it too.
We were buying on headcount, and we interviewed each engineer before they touched our systems. The first ones were good. They learned our environment, our quirks, our operational routines. Six months in, they knew us.
Then they started to disappear. It began slowly: more PTO, then more sick days, then a new face brought in for temporary coverage. We were reasonable people. We helped the new person get up to speed.
Then the original engineer was gone. And a few months later, the temporary coverage started disappearing too.
After watching it happen a few times and comparing notes with peers at other companies, I understood. The experienced engineers were the thing being sold. Once the work was running, they moved on to the next pitch. We kept cycling through whoever was next in the queue. The institutional knowledge walked out repeatedly, and we kept paying to rebuild it.
So we refused the trade. The engineers who run your systems day to day are the same ones who answer when something breaks. Not a tier. Not a handoff. The same people, on the good weeks and the bad ones.
Judgment is what you're actually buying. You can't sell it in a meeting and then deliver something else.
The complaint: the urgency disappears the week after you sign.
Then there's the week after you sign.
The energy of the sales cycle just stops. Kickoff moves. Names don't get assigned.
You find yourself chasing the people who were so eager to talk three weeks ago.
You told your leadership the work was starting.
Then you had to tell them again.
That's the part that never makes it into anyone's status report. The delay costs you time, and it spends a little of your credibility every time you walk it back.
You went out on a limb recommending this. Now you're defending it before it has done anything.
The reason is unglamorous. The deal is booked, and attention moves to the deals that aren't.
I learned this one from the other side. In technical services, silence creates anxiety even when the work is fine, even when you're on top of it.
Your customers want confidence as much as they want resolution, and confidence is something you have to send before they ask for it.
So we made it a rule: when we say the work starts, the work starts. If we can't be ready, you hear that before you sign, not after.
The complaint: anything outside the scope line comes back as a change order.
Something lands outside the scope line.
It's urgent, and it's obviously connected to the work already underway. The answer comes back as a change order and an estimate.
So the next time something lands outside the line, you think twice before asking.
That's the real cost, and it was never the invoice. It's that you stop asking.
I've watched good engineering leaders pre-negotiate with themselves. Running the math on whether a problem is worth the paperwork. Letting small things sit because raising them means a conversation with procurement.
Scope quietly becomes a ceiling on what your partner is allowed to care about, and you end up managing a contract instead of solving a problem. Meanwhile the small things stop being small.
Somewhere along the way I stopped asking how do I close this and started asking how do I leave this better than I found it. Those are different jobs.
A change order is what the first question looks like on an invoice.
So we priced it so you'd never have to run that math. The number is fixed, and a surge gets absorbed inside the agreement we already have.
When something goes sideways at 2 AM, nobody on your side should be wondering whether it's billable.
The complaint: the engineer you finally got up to speed is gone by next quarter.
You trained someone.
They asked good questions. They got good. Six months in they knew your quirks, the service that always breaks on Tuesdays, the thing nobody ever documented because the person who built it left in 2019.
Then they moved on.
Now you're explaining your environment to a stranger, and somewhere in the third or fourth telling it occurs to you that you're the one carrying the institutional memory of your own vendor relationship. You've become the continuity you were paying for.
The handoff into delivery is usually thin, and what you spent the sales cycle explaining gets explained again.
I was the engineer who left. I stopped applying for jobs somewhere along the way and started getting recruited into them.
Every one of those moves was good for me. It took me years to think about what they cost the people I left.
So we built it the other way. Knowledge lives in runbooks and a cross-trained team, not in one person's head. You hand off once. After that we teach each other, and the team absorbs it instead of the individual.
And those runbooks are yours as much as ours. Transition planning and documentation handoff are part of every engagement, because a partner who leaves you dependent on them has already told you what they're optimizing for.
The one underneath the rest: the revenue continues while the core problems stay open.
Which brings me back to what I saw from the buyer side.
An issue opens. It gets worked. It gets discussed on the weekly call, and the updates are all reasonable.
Everyone is responsive. Nobody is lazy.
Weeks pass and it's still open.
At some point you catch yourself wondering whether closing it is actually anyone's job.
That one is the system working exactly the way it was built to work.
Go back to my meeting for a second. I decided what that customer needed instead of finding out. One engineer, one bad instinct, two days spent on the wrong problem.
Now put a revenue model behind that same instinct. Not a person guessing wrong once, but a structure that never has to ask what's actually broken, because the answer doesn't change what gets billed.
I spent years being measured. On utilization. On billable hours. On whether the account renewed. Nobody ever measured me on whether the customer needed us less.
That's the whole thing. It's what I couldn't see from the inside, and what I couldn't unsee once I was out.
Which means the question worth asking isn't whether your vendor's engineers are good. Mine were good. I was good.
The question is what their model pays them to do.
Here's how it should work. When you buy a car, you don't care how it's built, as long as it's safe and delivers what was promised. As the customer, you define the outcomes. As the vendor, they deliver them. You agree on price. Everyone keeps their promise.
It should be that simple.
The reason it isn't is that most technical services businesses are paid to keep working, not to finish the job.
We built ours the other way. Our people aren't compensated for resolving more tickets. Their measure is delivering outcomes: problems removed, systems that get healthier over time. When you operate on fixed pricing with a fixed team, you have to get creative. You have to find and fix root causes, because new problems on top of unresolved ones will eventually bury you.
We don't see quarters. We see years.
Our eleven-plus years of client relationships are the proof that this approach works. It builds more slowly than other models. But it builds something that lasts.
I should be honest about what that costs. It's a harder business to run, and billing hours is simpler and steadier and much easier to forecast. Choosing otherwise means some quarters we work ourselves out of revenue we could have kept.
Conviction that costs you nothing isn't conviction. It's marketing.
The incentive, reversed: the problem closes even when there's no revenue in it.
I can tell you all of that. Here's the only way I know to show it.
One of our teams was in the middle of an emergency. A critical Linux kernel vulnerability, exploit code already public and active, thousands of production nodes exposed.
The standard remediation window for something like that is 30 days.
Their leadership said it had to be done that week.
That's the moment a model shows itself. A vendor measured on process has a very good answer available: the standard is 30 days, and we're inside it. Nobody gets fired for citing the standard.
We patched more than 5,000 EKS nodes in under a week. No SOW amendment. No change order tickets. No added cost.
"Thanks a lot for the amazing work this week. It was no easy feat to patch over 5,000 nodes within a week."
And somewhere inside that week, one of our engineers noticed something that had nothing to do with the vulnerability. A version mismatch across two teams that would have broken failover the next time anyone needed it.
It wasn't in scope. Nobody had asked. Raising it meant more work for us and no additional revenue.
They raised it anyway.
Both of those came from the same place. Nobody on our side was measured on the ticket closing. They were measured on whether the exposure was gone.
Anyone can say their incentives point the same direction as yours. The test is what happens on the day that alignment costs them something.
Most of the people in this business are good at their jobs and trying to do right by their customers. That was true of me when I was the engineer who got it wrong. It was true of the vendors I managed when I was the buyer. Good people, operating inside a model that made the right thing structurally difficult.
I'm writing this because once you can see that, you can ask a better question. Not whether their engineers are good. What their model pays them to do.
The most honest thing we can do is tell the truth, no matter what it costs us, because it is the right thing to do. Always.
You can't put a price on your character.
Steve Kwan is the CEO of OpsWerks, which owns 24/7 operations for platform and SRE teams. If any of this sounded like a relationship you're in right now, he'd like to hear about it.
Email partnerwithus@opswerks.com