Monday, November 23, 2020

Scanning QR Codes Safely in India

Updated September 2026: in 2020 I noticed that my iPhone scanned a shop's QR code straight from the camera while many Android phones then needed a separate app. QR scanning is now built into almost every phone, and QR scams have grown. I have rewritten it into a guide to scanning QR codes safely in India.

At a local shop, the owner announced they were now online and invited customers to scan a QR code at the counter for a surprise gift. My iPhone read it directly from the camera. At the time, several Android phones needed a separate scanner app, which I thought was a strange gap.

Do Android phones scan QR codes without an app now?

Yes, most do. Google Lens is built into the camera on many Android phones, and recent Android versions offer a QR scanner in the Quick Settings panel. Phone makers such as Samsung also include scanning in their camera apps. A separate app is rarely needed.

What are the risks of scanning QR codes?

  • Payment scams: a fraudster sends a QR code claiming you will receive money. Scanning a UPI QR code is only ever for paying, never for receiving.
  • Fake links: codes pasted over genuine ones can lead to phishing sites.
  • Malicious downloads: codes that prompt you to install an app.

How do you scan safely?

Check the link preview before opening it, and do not proceed if the address looks odd. When paying by UPI, confirm the merchant name shown in your app before entering your PIN. Be wary of codes offering gifts or refunds.

What should shops do?

Display QR codes where staff can see them, check regularly that nobody has stuck a different code on top, and use the payment provider's sound box or confirmation to verify each payment.

What if you have been scammed through a QR code?

Call the national cybercrime helpline 1930 immediately, report on the cybercrime portal, and inform your bank. Quick reporting improves the chance of stopping the money.

Is QR scanning still worth using?

Yes. UPI QR payments are fast and convenient. A few seconds of checking make them safe.

Keep reading

Sunday, June 28, 2020

A Proposal Built on Assumptions: How to Close It

Updated September 2026: in June 2020, after more than a week on an opportunity, I asked onsite on a check-point call about the plan ahead and learned the client had not answered their questions, so the whole solution rested on assumptions. My manager gave no support in limiting more work. I have rewritten it into advice on handling a solution built on assumptions.

I had worked with the onsite team and my manager for over a week and wanted to close. My manager would not tell onsite that my work was finished. On a daily check-point call, I asked about the next steps. The onsite team said the client had not responded to their clarifications, so the whole solution was based on assumptions. I was frustrated, and my manager did nothing to stop more work being requested.

Is a solution built on assumptions a problem?

Not necessarily. Many proposals are submitted with stated assumptions when clients are slow to answer. The problem is when the assumptions are hidden or keep changing, so the work never stabilises.

How do you make assumptions work for you?

  • List every assumption clearly in the document.
  • Agree them with the onsite team so they are the team's, not yours.
  • Price and plan against them, noting what would change if they are wrong.

How do you stop endless extra requests?

Propose a closure point: "The solution is complete against the agreed assumptions. Further changes can wait for the client's answers." Put it in writing to the onsite team and your manager.

What if your manager will not help?

Communicate the closure point yourself, with your manager copied, focused on facts. You are not overriding them; you are giving everyone a clear status.

Why ask about the plan ahead?

Because it surfaced the real situation: nothing more could be firmed up until the client responded. Asking that question on the call was the right move.

What happens when the client finally responds?

Compare answers with assumptions and update only what changed.

Keep reading

Sunday, June 7, 2020

The Last Working Days Before a Long Leave

Updated September 2026: in 2020 I reached my hometown early because of the pandemic and had to work from home for a few days before a long vacation, anxious that my manager would pile on work if he saw I was free. I have rewritten it into advice for the last working days before a long leave.

I logged in from home anxious about new work. There were no new emails from onsite, which was a relief. I spent the day browsing, still uneasy, because I feared my manager would give me unnecessary work if he knew I was free, and would try to get as much done as possible before my leave.

Should you hide spare capacity before leave?

It is tempting, but it rarely helps. Managers usually learn you were free, and it can look worse than being open. Better to use the time on things that make your leave go smoothly.

What should you do in the last days before a long leave?

  • Close or hand over open work, with a short note for each item.
  • Update shared files so others can find the latest versions.
  • Tell stakeholders your dates and who covers for you.
  • Set your out-of-office with one clear contact.

How do you respond if new work arrives?

Take on only what you can finish before you go, and say so plainly. "I can finish the first draft by Thursday; after that, Ravi will take it forward." Managers usually accept a clear plan.

How do you work from home well for a few days?

Set up a quiet space, keep your usual hours and stay responsive on chat. Brief, regular updates show you are working, which removes any worry about being idle.

How do you manage anxiety about your manager?

Focus on what you can control: finishing and handing over well. A good handover is the best protection against being called during leave.

What should you do on the last day?

Send a short summary to your manager: what is done, what is handed over and to whom. Then log off properly.

Keep reading

Friday, March 13, 2020

When Can You Treat Reviewer Silence as Approval?

Updated September 2026: in March 2020 the offshore delivery contact and I finished most of a request in two days, sent a work-in-progress version to onsite and heard nothing. We decided that no comments meant we were on track, and completed the rest. I have rewritten it into advice on when to treat silence as approval.

We worked quickly and covered nearly all the client's requirements within two days. On the first day we sent a work-in-progress document to onsite for review. By the next day there were no comments or even an acknowledgment. We decided that if nobody commented, we would assume we were on the right track and complete the rest.

Is it safe to treat silence as approval?

Only if you say so in advance. Proceeding quietly on the assumption of approval can backfire if the reviewer later claims they never agreed. Stating it openly makes the assumption legitimate and gives the reviewer a fair chance to object.

How do you state it?

In the email that shares the draft: "Please send comments by 3 pm tomorrow. If we do not hear by then, we will proceed on the current approach." Clear, polite and hard to dispute later.

What if the reviewer objects after the deadline?

  • Point back to the deadline in your email.
  • Assess what the late feedback would change.
  • Agree whether it can fit before submission, or goes into the next version.

Why do reviewers go silent?

Usually because they are busy, waiting for client input, or satisfied and not thinking to say so. Silence is rarely rejection, but it is not a formal yes either.

Is moving fast worth the risk?

Often, yes. Finishing early leaves time to absorb late feedback. Waiting passively for comments tends to push all the work into the last day, which is where mistakes happen.

What should you record?

The version shared, the deadline for comments and the decision to proceed. A short note in the thread is enough.

Keep reading

Wednesday, February 12, 2020

Getting Up to Speed Fast on Someone Else's Request

Updated September 2026: in February 2020 my manager pulled me in at the last minute to complete a colleague's service request. I could read only a few client documents, teammates gave little insight, and I built a table of contents from standard repository content. I have rewritten it into a guide to getting up to speed quickly on someone else's request.

I had to understand the client's requirements fast. I tried reading the documents the client had shared but covered only some. My teammates offered little beyond general points. Drawing on similar past requests, I started with standard content from my repository and drafted a rough table of contents.

What should you read first?

  • The request itself: the RFP or client brief, especially the questions and evaluation criteria.
  • The latest client email, for recent changes.
  • Any existing draft, to see what is already done.

Skim long background documents for headings and numbers; read deeply only what the questions refer to.

How do you get useful insight from colleagues?

Ask specific questions rather than "what do I need to know?" For example: "What did the client react to on the last call?" or "Which section is the client most concerned about?" Specific questions draw out specific answers.

Why start with a table of contents?

It turns a mass of documents into a structure. Mapping each client question to a section shows what is covered by standard content and what needs new work, which is exactly what you need to plan.

How do you use standard content well?

As scaffolding, not the final answer. Tailor each standard section with the client's name, context and requirements. Generic content left unchanged is easy for evaluators to spot.

What should you confirm early?

The deadline, the approver and anything already promised to the client. Send your table of contents to the delivery lead for a quick check before filling it in.

How do you avoid being the last-minute rescuer every time?

Do it well, then ask your manager to involve you earlier on similar requests.

Keep reading

Sunday, January 5, 2020

Is It Reuse or New Work? Clarify Before You Commit

Updated September 2026: in January 2020 I joined a call expecting to pull existing slides from the repository, but the delivery lead started briefing new work and asked me to set up recurring calls. My manager still thought only reusable slides were needed until I pointed out it was a new request. I have rewritten it into advice on clarifying whether a request is reuse or new work.

My manager and I joined the call to help the delivery lead find slides from the repository. Instead, he began explaining a new piece of work and asked me to schedule recurring calls with onsite for the coming weeks. I waited for the call to end to discuss it with my manager, who still believed the task was sharing reusable slides. When I stressed that this was new work, he understood.

Why does reuse become new work?

Because "just share the existing slides" is often how new work is first described. The requester thinks old material will cover it; once they explain the need, it clearly will not. Without a pause to clarify, the assignment grows unnoticed.

How do you clarify on the call?

Ask one question: "Is this a new request we should plan for, or are we sharing existing material?" It is polite, and it forces the scope into the open. Note the answer.

What should you tell your manager?

  • That the request is new work, not reuse.
  • The expected effort and duration, including the recurring calls.
  • What else you are working on, so they can decide priority.

Should you set up recurring calls immediately?

Only once your allocation is confirmed. Scheduling calls commits you to the work in everyone's eyes. A short "I will confirm with my manager and send the invites today" is enough.

How can reuse requests be handled faster?

A well-organised repository lets requesters find material themselves. Point them to it with a link, and reserve your time for tailoring.

What did this teach me?

That managers often agree to requests based on a one-line description. Speaking up early, as I did after the call, lets them decide with the real picture.

Keep reading