An honest team working on something hard and a team managing its client produce the same status report. Both say progress is being made, both cite real obstacles, both sound confident. The difference is not in any single update. It is in a set of patterns that only become visible over several weeks.
None of the six below proves anything on its own. Three or four of them together, sustained, is a different matter.
Key takeaways
- Patterns, not incidents: Any one of these has an innocent explanation. The combination does not.
- Watch what happens to specific questions: Being managed usually feels like never getting a direct answer to a direct question.
- Access is the tell: Teams with nothing to hide give access easily.
- Slow and evasive need opposite responses: Diagnose before acting.
1. Specific questions come back as general answers
You ask when the payment integration will be finished. You get a paragraph about the complexity of payment providers. The paragraph is true, informative, and does not contain a date.
Once is a communication mismatch. Every time, across weeks, is a pattern. The test is simple: ask the same question in the same words the following week and see whether the answer converges on something specific or restates the general position.
2. Nothing can be shown outside their environment
Every request to see the work becomes a scheduled demo, a screen share, or a video. You are never given a link, a build or a test account you can use alone.
There are legitimate reasons for this, particularly early on or with integrations that need live credentials. But it is also the single most common way a project that is further behind than reported stays that way, because a controlled demonstration can be made to look finished long before the thing is.
3. The reasons are always external
Every delay is caused by a third party, a platform, an unclear requirement, or something you did. Real projects do have external causes, and plenty of delays genuinely are the client's fault. What is unusual is a project where none of the causes are ever internal.
A team that occasionally says "we got that wrong and it cost us a week" is giving you a much more reliable picture than a team with a perfect record of external misfortune.
4. The same area keeps being worked on
Ask what has been rewritten more than once. If the same module keeps appearing across months without the business requirements having changed, the work is being redone rather than finished. This consumes budget while producing the appearance of activity, and it is often invisible from the outside because each week's report describes genuine effort.
5. Estimates only ever move outward, and only in small steps
A team that understands its own work is sometimes early. A team that has lost its grip on the estimate moves the date by a week, then another week, then another. Each move is small enough to accept and the sequence is unbounded.
Watch for the third consecutive one-week extension. That is the point at which the estimate has stopped being an estimate.
6. Attempts to bring in a second opinion are discouraged
You mention having someone technical look at the work and the response is discomfort: it will slow us down, they will not understand our context, it will damage trust.
Good engineers are usually relieved by an informed reader, because they have been trying to explain a real constraint to someone with no way to evaluate it. Strong resistance to being read is the one item on this list that is hard to explain innocently.
Telling slow from evasive
These need opposite responses, so the diagnosis matters more than the reaction.
| Honest and slow | Managing you | |
|---|---|---|
| Access to the work | Given, sometimes reluctantly | Deflected repeatedly |
| Bad news | Arrives late but arrives | Arrives only when forced |
| Causes of delay | Mixed, some internal | Almost always external |
| Second opinion | Welcomed or tolerated | Resisted |
| Remaining list | Specific | General |
If most of your answers fall in the left column, you have a capable team on a hard problem, and the correct response is to cut scope, not to apply pressure. If they fall in the right, more meetings will not help, because meetings are the medium being managed.
What to do about it
Do not open with an accusation. You may be wrong, and if you are, you will have damaged a working relationship for nothing.
Start by asking for artefacts rather than reports: the remaining list in writing, a deploy count, access to try the thing yourself. The requests are reasonable, they are hard to refuse without a specific reason, and the responses tell you what you need to know. If they come back thin, that is the point to bring in someone who can read the actual work, which we cover in what a technical audit involves.
Ali Boran Gazel