June 28, 2020

Two Leads, Two Task Lists: Handling Conflicting Instructions

Updated September 2026: in June 2020 I described being assigned an opportunity where my manager and the onsite coordinator each gave me different tasks, leaving me with two task lists for one deliverable. I have rewritten it into advice on handling conflicting instructions from two leads.

On the first day of that opportunity, the onsite coordinator asked for a few slide changes and some coordination with other teams. It looked simple, and I committed to finishing the next day. The following morning my manager added his own set of suggestions, unrelated to the client's requirements. I now had two lists: one from the coordinator, one from my manager, and the two of them already clashed over small inputs.

Why do conflicting instructions happen?

Because two people feel responsible for the same outcome and neither owns it clearly. The onsite coordinator is closest to the client; your manager is accountable for you and your team's reputation. Without an agreed split, both give direction, and the person doing the work absorbs the conflict.

What should you do when two leads give different tasks?

  • Write both lists down side by side and note where they conflict or overlap.
  • Ask one question to both: "Which of these does the client need for this deadline?"
  • Get a single priority order agreed in writing, ideally in one shared email or call.
  • Finish the agreed list first, and park the rest.

How do you avoid being caught between two egos?

Do not carry messages between them. If your manager's suggestion conflicts with the coordinator's, put both people on the same email or call and let them settle it. Relaying one person's view to the other makes you the messenger for a disagreement that is not yours, and it usually arrives distorted.

What if your manager's tasks do not match the client's needs?

Ask your manager to explain how the task serves the client's requirement. Sometimes there is a good reason you have not heard. If there is not, the question itself often makes the task quietly disappear. If it does not, and you are told to do both, state the time impact plainly so the deadline is renegotiated rather than silently missed.

How do you prevent it on the next opportunity?

At kickoff, ask who is the single point of approval for the deliverable. Write it in the scope summary. When everyone knows whose sign-off counts, competing instructions become suggestions to be approved, not tasks you must complete twice.

Keep reading

June 07, 2020

When the Client Changes the Plan: Handling Rework

Updated September 2026: this 2020 post described a day of addressing review comments, only for the onsite team to announce the next morning that the client had changed direction and the whole solution needed revamping. I have rewritten it into practical advice for handling a client's change of plan without taking on endless rework.

In June 2020 the delivery lead and I spent a full day on review comments and suggestions from other teams, and sent the updated document back hoping for light edits. On the next call, within minutes, the onsite team told us the client had changed the plan and we would need to rework the entire solution and approach. Before that call ended, I said we would deliver the revised version, and that any changes after it would be owned by the onsite team. They agreed.

Why do clients change direction late?

Because their own decision-makers see the proposal for the first time, budgets move, or a competitor's offer shifts their thinking. Late changes are part of presales work. The aim is not to prevent them but to limit how many times the same document is rebuilt from scratch.

What should you do in the call where the change is announced?

  • Listen and take detailed notes rather than reacting. The reasons behind the change shape the rework.
  • Ask what stays the same. Parts of the solution usually survive, and naming them early saves time.
  • Agree ownership before the call ends, as I did: who does the rework, and who owns any changes after it.

How do you make the ownership agreement stick?

Write it down straight after the call and send it to everyone present. A verbal agreement made in a tense meeting is easy to forget a week later, which is what tends to happen. In my case the onsite team accepted ownership on the call, and it still went the other way afterwards. A short email summary gives you something to point to when the next round of changes arrives at offshore.

How do you protect your team from repeated rework?

Build documents in modules, so a change of approach replaces sections rather than the whole thing. Keep each version, and mark which parts changed and why. When a third or fourth complete revamp is requested, the version history turns "we keep redoing this" into evidence your manager can use to renegotiate the effort or the timeline.

What is the lesson from that morning?

Saying clearly who owns the next round was the right instinct. Putting it in writing the same hour is what would have made it hold.

Keep reading