Why Our Customer Success Managers Are the Reason Offshore Works

I spent years running software companies, and now I run a services company. The same thing is true of both: keeping a customer you already have is easier and cheaper than going out and winning a new one. Everybody knows that, and hardly anybody staffs for it.

Which is how “customer success manager” became a critical role with kind of a weird job title. At a lot of companies it means the person who emails you a satisfaction survey after the relationship has already gone bad.

At Full Scale the role carries real weight, and the reason is specific. Offshore development almost never fails on the code. Engagements come apart over communication nobody escalated, a manager on one side who wasn’t managing, expectations nobody set, and problems that sat in plain view for two months before anybody said them out loud. Skill is rarely what kills the engagement, and I have watched enough of them die to be confident saying so.

Preventing exactly that is the job. Every Full Scale client gets a customer success manager, and it is critical to what makes us different and why our customers find great success with their teams.

I recently met with all of our CSMs to discuss what they do in detail. The rest of this article is a deep dive into the hard work they do every day.

A customer success manager is not a project manager, and that gap is the whole job

Full Scale doesn’t put a project manager between a client and their engineers. That’s the whole model: the client sets the priorities, the client runs the standups, and our engineers work in their codebase. Staff augmentation works much better than putting a project manager in the way. Which raises a fair question.

If the CSM isn’t managing the project, what are they managing?

Ed, who leads the group, summed it up perfectly:

“All the focus of a project manager is just project, not the people. They’re going to push the team in order to deliver the work. That’s it.”

Mike framed it as product roadmaps versus managing humans. A PM owns releases, priorities, and what ships this quarter. A CSM is making sure the person doing the work is in good enough shape to keep doing it next quarter. Ed also described it as sustainability.

	Project manager	Customer success manager
Owns	The project, roadmap, release dates	The people
Optimizes for	Short term results	Long term results
Will sacrifice	Whoever on the team complains least	Their own standing with the client
Judged on	Did it ship	How is the team?

A PM is measured on whether the project shipped in the short term. A CSM is measured on employee retention and long term results.

That split is deliberate, and it runs along the same line. Our clients stay close to the day-to-day delivery, because they own the roadmap, the priorities, and the decisions about what gets built this week. We stay focused on the long-term success of the team and of the client, which is what a staff augmentation partner is actually for.

Some companies need the opposite, and we understand that. When the work is a fixed scope with an end date and somebody else should own delivery, that’s project-based outsourcing, and it’s a legitimate thing to buy. It’s just built around a different goal than long-term team success.

Success runs on three cadences

Everything else hangs off three recurring meetings and one report.

Ritual	How often	Who is in the room	What it is for
Daily report	Every shift	Written by each engineer	Catching problems in real time
Team checkpoint	Weekly	CSM and our engineers	Finding out what is actually happening
Client checkpoint	Monthly	CSM and the client’s team	Hearing the client’s side of it
Kickoff call	Once, at the start	Everyone	Setting expectations before day one

One number for scale, because it matters later: each CSM carries 50 to 70 engineers. That’s a constraint more than a selling point, and I’ll come back to what it costs us.

The daily report is the tripwire

At the end of every shift, each of our engineers writes down what they did, what they plan to do tomorrow, and anything blocking them. Clients can receive those reports if they want them, and we sort that out on the kickoff call before anybody starts.

Historically a human had to read all those reports. That does not scale past about a dozen people, and our CSMs manage dozens each. Nobody is reviewing 600 daily status reports from the last two weeks looking for patterns.

Now we analyze them all using AI, and the patterns are hard to miss. One engineer reported working on the same password hashing task for several days running, which shouldn’t take that long. Another worked on ticket number TK-9999, which is not a number any real ticket system hands out.

What I want out of a daily report is simple. Are we making progress? Everything else is negotiable.

That is exactly what the analysis is for. It holds everyone accountable to real progress every single day, on every account.

We also do something standup reports don’t normally do. We ask our employees what would make them more productive and how their manager could help them. Getting better every day and getting our employees to adopt that mindset is essential to their growth.

The weekly meeting with our engineers is where the truth lives

Full Scale’s CSMs meet with each client team every week, and Igor was clear about why that meeting matters:

“The primary source of what’s going on with an account is the weekly meeting, through our people, because those are the ones we can really control. They’re required to attend our meetings.”

We love meeting with our clients but they don’t always have the time to meet with us. Our own team members are often the best source of how things are going.

The hard part is that plenty of engineers won’t volunteer that a problem exists, either because they don’t want to bother anyone or because they’d rather quietly fix it themselves and never mention it.

Asking “how’s it going” gets “fine,” which is not usually helpful.

So we ask the better questions:

• Are you achieving your project goals?
• How are you getting along with the client and other team members?
• Are there any internal issues that seem to be going on at the client?
• Are they giving you everything you need to be successful?

Here is the most important question for the team:

Do you feel like you are winning or losing right now?

Some members are more vocal than others in these kind of group meetings. And that is OK. Anyone who stays quiet in the group call gets a private follow-up afterward.

Retchel was matter-of-fact about it:

“I create a rapport, joke around to lighten the mood, because different people have different ways of communicating. It really takes some time before you get to a point where they are comfortable talking to you.”

The detail that convinced me none of this is theater: one engineer was silent in every internal meeting we had with him, and turned out to be the most vocal person on his client’s calls. That only surfaces when somebody is paying attention over months.

At Full Scale we are well aware of the different cultural differences and communication styles across our employees. It impacts how we mentor and train each person individually. We wrote up a great article dedicated to Filipino work culture about this.

The monthly checkpoint with our clients

Equally as important, once a month our CSMs meet with each of our clients.

This is our chance to hear what is going really well and to give those team members the shout-outs they deserve. It is also our chance to uncover potential issues that we can work behind the scenes to resolve.

It’s not another status update, since clients already get those every day. It is the time to step back and really think about how the team is doing and how it could be improved.

The checkpoint exists because both sides sit on things they will never raise in a daily standup, and somebody has to set aside time to have those sometimes harder conversations.

Real things our CSMs have brought to a client:

• A client was planning to move to automated testing next quarter, and every tester on the account was a manual tester. We raised it early and helped with an upskilling plan.
• Our engineers weren’t clicking with one of a client’s in-house developers, and it was showing up in code review. We worked through how the whole group could operate better together.
• Two developers on one account were absorbing what looked like four people’s worth of tickets. It showed up in their daily reports weeks before it showed up in the client’s velocity.

Real things clients have brought to us:

• A client is having performance issues with a specific engineer. We talk to the individual to understand why and put together a plan to improve productivity.
• Additional training is needed on AI or new technologies for current or upcoming projects. We work behind the scenes on the upskilling needed.
• Someone on the team isn’t speaking up much during meetings. We talk to them to help identify why and train them on having the courage to speak up.
• Logistical help on how to upgrade equipment for the team. Be it new laptops, mobile devices for testing, etc.
• Our favorite is when clients reach out and want to do a special shout-out for one of our team members.

Both of those lists are why the meeting is monthly instead of quarterly. A quarter is long enough for any one of them to become the reason an engagement ends.

Some clients hardly provide any feedback at all. Igor’s read on those is the mature one: the CSM keeps showing up anyway, because the goal is to buil a long term relationship. We aren’t giving up.

Just like our team members may not feel super comfortable about asking our clients directly about some topics, it is easier for our clients to ask the CSM to help resolve certain issues.

The CSMs provide that very valuable go between to have some of the more delicate conversations.

Half the job is coaching people to say the hard thing

Full Scale’s CSMs spend a surprising share of their week teaching engineers how to raise something uncomfortable with a client. Sometimes that means drafting the message together and checking the tone before it goes out.

The pattern repeats. An engineer knows exactly what’s wrong, but saying it means creating friction with somebody senior on the client’s side, so they stay quiet and the problem compounds.

Three real examples, with the clients left out of it.

A client’s support reps were sending production issues straight to one of our developers. Every interruption pulled him off the roadmap work he was hired for. He never raised it. His CSM did, and got the client to put a triage layer in front of engineering so only real problems reached him.

A manager on a client’s team sat silent through every standup while his own team floundered around him. Our engineers noticed and would not touch it. Their CSM brought it into the monthly checkpoint instead.

A newly hired project manager on the client side started assigning work and setting due dates in a way the team disagreed with. The CSM did two things at once: coached our engineers on how PMs actually think and how to negotiate with them, then worked the client side separately to adjust.

“Some clients are not clear on some items, so the CSM fills it in so our members understand the gap. And the other way around too.”

Ed

Nothing improves if nobody says anything. That is even true in engineering orgs. Somebody has to be the person who speaks up.

They coach the client’s people too, which nobody expects

Here is the one I did not see coming. Our CSMs regularly end up coaching staff that actually work for the client.

A manager on one client’s team had just been promoted for the first time and was struggling with a couple of difficult reports. She asked Mark for advice, and that call ran an hour. She doesn’t work for us. And that is just fine!

We have also mentored somebody into the role they were hired for but were not yet performing, in one case a product owner who was operating like a business analyst. Weekly coaching, for months, on pushing back and owning a roadmap. And when an engineer is heading into unfamiliar territory, we put one of our own solutions architects alongside them for the first few weeks so it never becomes the client’s problem.

An engineering manager who is good at managing people is the single biggest predictor of whether our engineers succeed on that team. Helping a client’s manager get better at the job is one of the easiest things we can do to help our own success. Everybody wins, and we win too.

This is most of the reason our retention number holds

Full Scale keeps 93% or better engineer retention, which is unusual in offshore development, where losing a client’s favorite developer is closer to the normal pattern.

I asked the CSMs how much of that they think comes down to their work. They landed around 80%.

They would say that, obviously. They are also probably not wrong.

Ed’s version of it is the one I find hardest to argue with.

“It’s not always the money that people leave. It’s also about who their managers are.”

One of our engineers came to us from a large global consultancy, and he keeps bringing up the same contrast. At his old employer, once you were placed with a client, that was the end of it. Nobody checked on you, and you might not see your own manager for six or eight months. Here, somebody gets involved and takes your side. He used the word “protected” to describe what it feels like to work for us.

Handing somebody a resource and wishing everyone luck is a cheaper way to run a staffing business. It’s also why so many offshore engagements quietly fail over time.

You can hope for success or you can work hard every week to make sure it happens.

Late in the call Ed said there was one thing they had all forgotten to mention. CSMs end up being career guides, especially for the ones on the fast track, and we have a lot of those. Most of them have not worked anywhere else. Full Scale is their first company, so they have nothing to measure it against and no reference point for how a career is supposed to go. The CSM ends up being the mentor by default.

That is the whole argument of Product Driven, and Ed got there faster than I did in an entire book.

Where this model breaks down

Every vendor claims their account management is excellent. Here is what ours cannot do.

It depends on the client showing up. We can see our side in detail. We cannot see whether the work is actually landing for a client’s business unless they tell us, and some never do. Then we are managing on one eye.

Escalations that arrive late are mostly unfixable. By the time some clients mention a performance problem, they have already decided to replace the person. A development plan built after that decision is paperwork, not a plan. Raised while it is still a coaching problem, we can usually solve it. Raised after, we are staging a recovery nobody intends to accept.

Our own people misreport sometimes. An engineer says no blockers, and two weeks later the client escalates. Mark named that as the hardest part of his job, and the reverse happens too: a client reports no problems right up until they drop somebody for performance. The daily reports and the weekly meetings exist precisely because self-reporting on its own does not work.

Fifty to seventy engineers per CSM is a real number. A CSM is not sitting by the phone waiting for one client to call. Somebody dedicated to a single account full time is a different product at a different price, and we would rather say so now than have a client discover it in month two.

And we cannot make everybody happy. Including our own employees. Mike said the hardest conversation he has is telling a team member who rated themselves “exceeds expectations” on their quarterly review that they did not. At the end of the day we are still managing people and nothing about the process is perfect.

Ready to meet yours?

If you want engineers who stay, and somebody whose actual job is making sure they do, schedule a call and we will walk you through what your first month would look like.