Your offshore team says yes to every request, every estimate holds until the week it is due, and then the date slips by two weeks with a polite apology. The problem is rarely honesty. It is that the team has learned that "yes" is the safe answer and "this is at risk" is the expensive one. You fix it by changing what a yes costs and what bad news earns, not by asking them to be more transparent.
I see this pattern in roughly every second offshore engagement I am brought into. The founder thinks they have a vendor problem. Usually they have a feedback-loop problem that they partly built themselves.
Why the yes is rational from their side
Put yourself in the seat of a mid-level developer at an agency in another country. You are two or three layers away from the client. Your project manager told you the client is important and a bit impatient. The client asks on a call whether the export feature can ship Friday.
You have three choices. Say yes, and you buy four days of peace and a chance it works out. Say "probably not, the reporting tables need a migration first", and you trigger an escalation, a call with your manager, and maybe a question about why you did not see it earlier. Say "I do not know yet", and you look unprepared in front of a client.
Yes wins almost every time. Researchers who study software projects have long noted that reluctance to report bad news is a real contributor to failure, and that it rises with personal risk. Hierarchy makes it worse: if the developer's manager is on the call, the developer will rarely contradict the plan in public.
None of this is a character flaw. It is an incentive. So the fix is also an incentive.
The signs you are getting yes instead of information
Before you change anything, confirm the pattern. The tells are consistent:
- Estimates never come back larger than you hoped. Not once in a quarter.
- Questions arrive late, usually in the last third of a task, not the first day.
- Status updates use "almost done", "in progress" and "testing" for more than a week on the same item.
- Your requirements are never challenged. Nobody asks "what happens if the user has no email?" or "do you want this on mobile too?"
- Slips are announced on the due date, not before it.
If three or more of these are true, you are not getting a project plan. You are getting a mood report.
Make yes more expensive
The cheapest change is to stop accepting a bare yes. Every commitment should come with three things written down: what will be shown, how you will check it, and what the team thinks could make it slip.
That last line matters most. "Yes, Friday" is cheap. "Yes, Friday, assuming the payment provider's sandbox works and we do not need to change the invoice table" is a real estimate, and it gives you something to watch. If the team cannot name a single risk on a two-week task, the estimate has not been thought through.
Then shorten the gap between a promise and its proof. A two-week deliverable with no intermediate check means you find out on day fourteen. A demo of a working slice on day four, even an ugly one, tells you most of what you need. This is the same logic as running a paid pilot before the big contract: small, checkable units beat large, trusted ones.
Make bad news cheaper
This is the half founders skip. If the first person who raises a risk gets a tense call and a "why did you not tell me sooner", everyone learns to raise risks later.
Three things that work in practice:
Thank the early warning, out loud
When someone flags a slip on day three, say on the call that this is exactly what you want, and adjust the plan without blame. Do it twice and the team notices. It is a small act, and it changes behaviour faster than any process document.
Ask questions that cannot be answered with yes
"Is this on track?" invites yes. "What is the part of this you are least sure about?" or "If this slips, what will be the reason?" invites information. Ask the developer doing the work, not only the project manager, and ask in writing so nobody has to disagree in front of a superior.
Agree a written escalation rule
Write one sentence into your working agreement: any task that will miss its date by more than a day is flagged the moment someone believes it, not on the due date. Pair it with a named person on your side who receives the flag and replies within a working day. The rule removes the judgment call from the developer. They are not complaining; they are following the agreement.
What you control on your side
Founders often feed the problem. Requests sent at 11pm your time with "need this tomorrow" teach the team that urgency is normal and pushback is unwelcome. Vague tickets teach them to fill gaps with guesses and keep quiet about it.
Fix the inputs. Each piece of work should have a short written description of what done looks like, who it is for, and what is out of scope. If you are not technical, that is fine, but someone has to translate business intent into checkable criteria. If nobody on your side can do that, the offshore team is guessing, and a guessing team will say yes because it has nothing better to say. We covered the operating rhythm for this in managing an offshore team when you are not technical, and time zones make it worse if overlap is thin, which is its own planning problem.
When it is not culture
Sometimes the constant yes hides something harder. The agency may have sold you a senior team and staffed juniors who genuinely do not know what they do not know. Or the developer on your project is split across three clients and cannot give you real dates because their week is not theirs to plan.
You can tell the difference with one experiment. Give the team a small, well-specified task with a clear check, and ask for an honest estimate with risks. If the estimate is sensible and the work lands, the issue was incentives, and the changes above will hold. If the estimate is still a bare yes and the work still slips with surprise, the issue is capacity or skill, and no amount of encouragement will fix it.
That is the point to get an outside read on the code and the team before you commit more budget. A short technical teardown will tell you whether you are looking at a communication gap or a staffing gap, and those need very different fixes.
FAQ
Is the yes problem a cultural thing?
Partly. Norms around disagreeing with a client or a superior vary between workplaces and countries, and hierarchy makes people less willing to contradict a plan in public. But I have seen the same pattern with onshore agencies whose clients punished bad news. Treat it as an incentive problem first; that is the part you can change.
Should I replace the project manager?
Not as a first move. Change the commitment format and the escalation rule for two or three weeks and watch whether early warnings start to appear. If they do not, the problem is more likely the people or the staffing than the process.
How fast should I expect a change?
If the team is capable, you usually see the first early warning within two weeks of making bad news safe. If a month passes with nothing but yes, assume capacity or skill is the real issue.
What if I cannot judge whether an estimate is realistic?
Then you need someone who can, at least part of the time. That is a common reason founders bring in fractional technical leadership for a few hours a week. You can book a call and we will tell you plainly whether that is worth it in your case.