Qui Pus Info

Updated September 2026: this November 2020 post described a leadership call where my manager's last-minute version of a document was set aside, I presented mine, and the leadership team acknowledged the work. I have rewritten it into advice on presenting your own work well when there are competing versions, without undermining your manager.

My manager and I had spent a weekend on a request from the leadership team. He kept asking for changes I thought unnecessary, then shared his own updated version just before the call. On the call, the onsite team was unhappy with his updates and wanted the latest information. I politely offered the slides I had prepared. After a short silence, the leadership team acknowledged the work, and the onsite team went ahead with my version.

When is it right to put your own version forward?

When the audience is asking for something your version contains and the other version does not. That was the situation on my call: the onsite team wanted the latest information, and I had it. Offering it served the meeting's purpose. Offering an alternative only to prove a point in front of senior people rarely ends well, whatever the outcome.

How do you offer it without undermining your manager?

• Frame it as additional input: "I have a version with the latest figures if that helps."
• Keep it about the content, not about whose document is better.
• Credit the joint effort if the version is accepted.
• Talk to your manager afterwards, privately, about how to avoid two versions next time.

How do you avoid two competing versions at all?

Agree one master document and one owner at the start, with a shared location both of you edit. Last-minute versions usually appear because someone was working in parallel without saying so. A single file and a checkpoint before the call remove most of that.

What should you do with recognition when you get it?

Record it. Save the email or note the call, the date and what was appreciated. Leadership recognition is strong evidence at appraisal time, and it fades quickly from memory if nobody writes it down. If it came in a meeting, a short follow-up email thanking them and summarising the next steps creates a written record naturally.

How do you repair things with your manager?

Assume they felt exposed, even if they said nothing. A calm conversation about what happened, focused on process rather than blame, protects the working relationship. The goal is the next document going smoothly, not winning the last one.

Keep reading

• Endless Iterations? Get a Clear Submission Date
• When a New Request Arrives on an Old Email Thread
• Blocked on Client Input: Handling a Stalled Deliverable

Updated September 2026: in June 2020 I was working with a demanding onsite lead while my manager kept suggesting alternative slides that the onsite team then discarded, and nobody agreed when the document was due. I have rewritten it into advice on getting a clear submission date when iterations keep coming.

The onsite team wanted customisation for the client. My manager opposed it and suggested an alternative slide on every call. I spent my effort on his slide each day, and each day the onsite team dropped it. When I asked my manager when the document would be complete, he said by the end of the week. I doubted it, given the iterations still coming, and asked him to confirm the submission date with the onsite team.

Why does the submission date matter so much?

Because it decides how many rounds of changes are possible. Without an agreed date, every stakeholder treats the document as open, and iterations continue until someone external forces a stop. With a date, changes have to be prioritised, and the late ones are either declined or traded against something else.

Who should confirm the date?

Whoever faces the client, usually the onsite lead or account manager. Offshore estimates, including a manager's, are guesses unless they match what the client has been told. Asking your manager to validate the date with onsite, as I did, is exactly the right question. The answer needs to come back in writing.

How do you manage iterations once the date is set?

• Set a cut-off for content changes a day or two before submission.
• Keep a change list with who requested each change and whether it made it in.
• Show the trade-off plainly when a late change arrives: what moves or drops to fit it in.

What if your manager's suggestions keep getting rejected?

Raise the pattern with your manager privately, with examples: the slides built, the day they were discarded and the hours spent. Suggest that his input goes to the onsite team as a proposal first, before you build it. That way good ideas still reach the client, and rejected ones cost a message instead of a day.

What if the date is simply unrealistic?

Say so early and specifically: how many changes are pending, how long each takes and what date is achievable. A clear warning a few days ahead is far better received than a missed deadline. It also shifts the decision to the people who can change either the scope or the date.

Keep reading

• Blocked on Client Input: Handling a Stalled Deliverable
• When a New Request Arrives on an Old Email Thread
• Asked to Take a New Project Just Before Your Leave?

Updated September 2026: in 2020 my manager allowed me to work from home just as Covid-19 was spreading, and within days I travelled to my hometown with only essentials, not knowing how long I would stay. I have rewritten it into a checklist for anyone planning to work remotely from their hometown for an extended period.

My manager's approval came almost at the last moment, and I left expecting a short stay. In 2020, a trip like that could easily turn into months, with only what had been packed for a few days. Many people now choose to work from their hometown for weeks or months at a time, and preparation makes the difference.

Is working from your hometown allowed?

Check your company policy before you travel, not after. Many employers allow remote work within the country but have rules on how long you can work away from your base location, on attendance requirements under hybrid policies, and on client restrictions for certain projects. Get your manager's approval in writing, with dates.

What should you take with you?

• Every piece of work equipment: laptop, charger, headset, and any security token or hardware key.
• Chargers and adapters for all devices, plus an extension cord.
• Documents you may need for work or banking, as copies stored securely.
• More than you think: in 2020 I took only essentials, and nobody could say how long the stay would last.

How do you make sure the internet is reliable?

Check broadband availability at the address before you go, and have a mobile hotspot as a backup on a second network. A second SIM from a different operator is inexpensive insurance against an outage during an important call. Test video calls from the room you will actually work in.

What about power cuts?

In many towns, short outages are common. A UPS for the router and a charged power bank for the phone keep you connected through most of them. A laptop with a healthy battery covers the rest. Know how long your setup lasts before you need it.

How do you stay visible while working away?

Keep your camera on for team calls when you can, respond within agreed hours, and send short status updates. Working away from the office makes it easy to be forgotten for new work. Being reachable and predictable prevents that.

What should you plan for the return?

Agree a return date or a review point with your manager. Open-ended arrangements tend to end suddenly with a return-to-office announcement, and a planned return is far easier than a rushed one.

Keep reading

• Asked to Take a New Project Just Before Your Leave?
• Working Under a Manager Who Won't Back the Team
• When a New Request Arrives on an Old Email Thread

Updated September 2026: in March 2020 an onsite team reopened an old email thread I had worked on, and I spent a day worrying whether it meant rework on a document built from thin client information. It turned out to be a new request. I have rewritten this into advice on handling requests that arrive on old threads, and on protecting leave when they do.

The reopened thread was from a service request I had spent little time on, with fragile client information behind it. When the onsite team scheduled a call, I could not tell whether they wanted to understand how I had built the old document or whether this was something new. On the call, the account manager explained the new requirements. The onsite team had simply reused the old thread because they did not know whom else to contact.

Why do new requests come in on old threads?

Because it is the easiest way for the requester to reach the people they worked with before. It saves them looking up names. For you, it creates confusion about scope, and it drags old history and old expectations into a new piece of work.

How do you clarify what the request actually is?

Ask before the call, in one line: "Is this a follow-up on the earlier document or a new request?" If it is new, suggest starting a fresh thread with a clear subject. It separates the work cleanly, and it makes the new request easier to find and track later.

How do you protect leave when a new request appears?

Say your dates immediately, as I did with the offshore delivery lead, and offer what you can realistically give before you go. In my case I offered extra working days and weekends up to the following week and made it clear I would be unavailable after that. That kind of clear offer lets the team plan cover instead of assuming you will be reachable.

Is offering weekends the right trade?

Only as a deliberate, time-limited choice. Offering weekends to protect a holiday can be worth it for a short, well-defined piece of work. It becomes a problem when it is open-ended or becomes the expected price of taking leave. Put the limit in writing, and hand over properly on the last working day.

What should the handover include?

• The client requirements as stated on the call, in their words.
• What is finished, what is in progress and who owns the rest.
• Where the files live, and any access your cover needs.
• The next expected date from the client side.

Most of my anxiety before that call came from not knowing what the request was. One clarifying question up front would have removed it.

Keep reading

• Back From a Long Vacation to No Work: What to Do
• Endless Iterations? Get a Clear Submission Date
• Presenting Your Version When Documents Compete

Updated September 2026: in February 2020 I joined a call unsure whether I was expected to have built something, when I was actually waiting on the onsite team for inputs. The onsite lead agreed the work should pause until stakeholders responded. I have rewritten this into advice on handling a deliverable that is blocked on someone else.

With no email from the onsite team all day, I had no inputs for the deck. I spent the time uncertain whether I should be building sample slides anyway or asking other account teams. On the call, when asked for updates, I said I had none because I was waiting on theirs. After a pause the onsite lead agreed the slides could not move without stakeholder input, said he would chase it, and told me to hold. The call was over in minutes.

What does it mean to be blocked on a deliverable?

It means the next step genuinely depends on information or a decision from someone else. It is different from simply not knowing what to do, which is something you can usually resolve yourself by asking. Being clear about which one you are in is the first step.

How should you report being blocked?

Early and in writing, not only when asked on a call. A short message such as "The pricing and scope slides are waiting on the client's volume figures, requested on Monday; nothing further can move until then" makes the dependency visible to everyone. It also protects you from the impression that nothing happened because you did nothing.

What can you do while you wait?

• Prepare the structure and the parts that do not depend on the missing input.
• Draft placeholders that show exactly where the input will go.
• List the specific questions for the stakeholder, so they can answer quickly.
• Check the repository for similar material you can adapt once inputs arrive.

Should you build sample content without inputs?

Only a light version, and only if it helps the stakeholder respond. Detailed guesses are often thrown away and can anchor the discussion in the wrong place. A simple outline with clear gaps is usually more useful than a polished draft built on assumptions.

When should a blocked deliverable be escalated?

When the missing input threatens the deadline. At that point the question is no longer yours; it belongs to whoever owns the relationship with the stakeholder. The onsite lead taking that on, as happened on my call, is the right outcome. Make sure the new timeline is agreed at the same moment.

Keep reading

• Endless Iterations? Get a Clear Submission Date
• When a New Request Arrives on an Old Email Thread
• Presenting Your Version When Documents Compete

Updated September 2026: in January 2020 I wrote about a call that was supposed to be a quick request for existing material from our repository and turned into much more. I have rewritten it into a guide to building a proposal repository that actually makes reuse quick.

My manager had lined me up for a service request starting the following week, and I felt prepared: I had reusable material and had worked with the same team before. Then an account team asked to borrow "some existing materials from the repository". I joined expecting a short call. It was not short, and it showed me how much depends on how that repository is organised.

Why do repository requests take so long?

Because most repositories are folders of old proposals, organised by client and date. To find one good architecture slide, someone has to remember which deal used it and then check whether it is still accurate. Every request becomes a search, and the person who remembers where things are becomes the bottleneck. When that person is busy or on leave, the whole team slows down.

What should a useful repository contain?

• Approved standard slides: capabilities, methodology, team structure and case studies, each reviewed and dated.
• Reusable components: architecture diagrams, timelines and pricing templates as separate files, not buried in full decks.
• Case studies with permission noted: which clients can be named and which must be anonymised.
• An owner and a review date for each item, so stale material is retired.

How should it be organised?

By topic and use, not by client. Someone preparing a proposal thinks "I need a migration approach slide", not "which deal from 2018 had one". A simple folder structure by topic, with a one-line description in each file name, beats any elaborate system nobody maintains.

How do you handle requests from other teams?

Point them to the repository first, with a link and a short guide. Offer a fifteen-minute call only for tailoring. If a request grows into building new material, treat it as a separate piece of work with its own estimate, agreed with your manager, rather than absorbing it as a favour.

Who should maintain it?

Everyone contributes, one person curates. After each proposal, add the best new slide or diagram to the repository and retire what it replaces. It takes minutes per proposal and saves hours on the next one, which is exactly the situation that call in 2020 would have been easier with.

Keep reading

• Back From a Long Vacation to No Work: What to Do
• When a New Request Arrives on an Old Email Thread
• Blocked on Client Input: Handling a Stalled Deliverable