T.

The Art of Politely Declining a Calendar Invite

By In Technology

The Bare Minimum for Professional Etiquette

Picture this: you’ve just hustled to get your five-year-old to school, stressing him and yourself out, because you had someone ask for an early morning meeting as a favor. You finally pull into the office parking lot thinking you’ve just made it, only to receive a notification two minutes before the meeting starts that it’s been declined. No explanation, no courtesy text, just a simple “decline.” Frustration now leads to expletives and the visualization exercise of physically harming a person. THEY WERE THE PERSON WHO ASKED FOR THIS F&*!ING MEETING.

So, breathe Greg. Channel the anger into something productive. I know… a blog. Let’s talk about how to avoid being that person and how to politely decline a calendar invite, especially if you’re the one who F&*!ING initiated it.

0. Respect People’s Time and Humanity

Before ANYTHING. Before I even write “Number 1”, the you have to realize that there are other human beings in the world other than yourself. They have things to do, people to meet, and places to be. When you do something that affects another human being, you need to think about that, and acknowledge that.

1. Acknowledge the Invite Promptly

Ok, now the actual first rule of declining a meeting is to do it as soon as you realize you can’t make it. Don’t leave the inviter hanging, hoping you might attend. This allows the other party to adjust their schedule accordingly and respects their time.

2. Provide a Reason

You don’t need to divulge your entire life story, but offering a brief, genuine reason goes a long way. A simple “I have a conflicting appointment” or “I need to handle an urgent matter” shows that you respect the other person’s time and that your reason for declining is legitimate.

3. Apologize for the Inconvenience

Acknowledge the trouble your cancellation might cause. A polite apology can soften the blow of the declined invite. Phrases like “I’m sorry for any inconvenience this may cause” or “I apologize for the last-minute notice” are courteous ways to show empathy.

4. Suggest an Alternative

If possible, propose an alternative time for the meeting. This shows that you’re still interested in meeting and that you value the other person’s time. For example, “I’m unable to make the 9 AM slot. Could we reschedule for later in the day or perhaps tomorrow morning?”

5. Use the Right Medium

If the meeting is informal or within a small team, a quick email or a message on your company’s communication platform might suffice. For more formal or high-stakes meetings, a phone call or a detailed email is more appropriate. It demonstrates that you take the meeting seriously.

6. Follow Up

If you’re the one who called the meeting, follow up after the decline. This is crucial. A simple message acknowledging the inconvenience and reaffirming the importance of the meeting can keep the professional relationship intact. “I understand the reschedule may have been inconvenient, and I appreciate your flexibility. Looking forward to our meeting tomorrow.”

Example Templates

Here are some templates that I should not have to write, because they should be obvious:

Template 1: The Quick Decline

Subject: Meeting Reschedule Request

Hi [Name],

I’m afraid I have to cancel our 9 AM meeting due to an urgent matter that has come up. I apologize for any inconvenience this may cause. Could we reschedule for tomorrow at the same time?

Thank you for your understanding.

Best,
[Your Name]

Template 2: The Detailed Decline

Subject: Request to Reschedule Meeting

Dear [Name],

I hope this message finds you well. Unfortunately, I need to cancel our meeting scheduled for tomorrow at 9 AM. An unexpected issue has arisen that requires my immediate attention.

I sincerely apologize for the short notice and any inconvenience this may cause. I value our meeting, and your time, and would like to propose rescheduling it to [Alternative Date and Time] if that works for you.

Please let me know your availability, and I’ll do my best to accommodate.

Thank you for your understanding.

Best regards,
[Your Name]

Template 3: The Phone Call Script

“Hi [Name], this is [Your Name]. I wanted to call and apologize for needing to cancel our meeting scheduled for tomorrow at 9 AM. Something urgent has come up. I’m very sorry for the inconvenience. Could we look at rescheduling for later in the week? I appreciate your understanding.”

Conclusion

Cancelling a meeting, especially one you’ve requested, is never ideal. However, handling it with grace, promptness, and politeness can maintain and even strengthen professional relationships. It also shows that you are a human, who actually cares about other humans. Remember, EVERYONE’s time is valuable, and acknowledging that through your actions speaks volumes about your professionalism. So, next time you find yourself in a bind, decline with dignity and respect – if you don’t you’re going to end up .

And maybe, just maybe, save a fellow parent from a stressful morning rush.

Previous ArticleNext Article
I help companies turn their technical ideas into reality. CEO @Sourcetoad and @OnDeck. Author of Herding Cats and Coders. Fan of squash, whiskey, aggressive inline, and temperamental British sports cars.

Leave a Reply

The Near Impossible Task of Defining an MVP

In Technology

We set out with the best intentions: we want to be lean and agile, and we are going to put something out into the world that we are “slightly embarrassed by” and we’re going to pivot and iterate from there. Right? That’s how it’s supposed to work.

But in reality, stakeholders never, ever seem to remember what that agreed MVP was. They fixate on a roadmapping session from six months ago or have a visual design comp stuck in their head that shows three features that were agreed to be post-MVP items.

Why Does This Happen?

  1. Memory is Fallible: We can remember talking about something, and knowing it was important, but not remember that we agreed it was out of scope or budget.
  2. Stakeholder Tactics: Some stakeholders might want to squeeze as much as they can out of development teams. They might agree to a smaller scope initially, hoping developers don’t remember the negotiation, or they might be unethically disingenuous.
  3. Lack of Experience: Stakeholders might not have enough experience in product management or development processes. They see software as infinitely changeable and might not grasp why certain features were deferred.

How Can We Stop It?

  1. Do Everything Waterfall: Agile just might not be the best approach for first-time founders, especially non-technical ones. Having clear visual comps of EVERYTHING can ease them into the fast-paced world of tech businesses, though this has many disadvantages.
  2. Hyper-Organization Mode: Developers and PMs can track every decision meticulously. A “Git for decisions” tool would be ideal, where every choice branches out with roadmaps and budgets, showing stakeholders how their decisions impact the project. Without such a tool, a detailed decision journal could work as a good alternative.
  3. Selective Client Engagement: Developers might choose to avoid working with first-time, non-technical founders. For products like platforms, where the technology is integral, having a technically savvy founder is crucial. For tech-enabled services, like an app to schedule plumbing appointments, the tech isn’t the core value, so non-tech founders might manage better.

What Can We Replace “MVPs” With?

I’m not sure. We have to launch with something, and that should have some level of definition, but I have three ideas:

Idea 1. Time Based MVPs

Maybe MVPs should be time-based, like launching something after a set period, regardless of what we have. Launch dates could drive everything in this way. Imagine a 90 day launch window after design/discovery has been performed. Then you would have weekly sprints, where the stakeholders are hyper engaged for a short period of time. The theory here is that this focus would cut out all the need for the “who said what when” arguments and everyone would only work on what was needed.

Idea 2. The 5-feature Rule

This is something I’m making up (desperately) on the spot. Perhaps the way we should be working to MVP should have some over arching philosophy about what an MVP even is.

  1. Basic User Management: Ensuring the system can handle user registration, login, and basic user profile management.
  2. Payment Handling: If the application involves transactions, it must handle payments from day one. Keep it simple and avoid novel payment systems.
  3. Performance: The application must perform well on its main targeted platform, device, or browser.
  4. Core Value: It should offer one really interesting, killer, or useful feature to the user. That’s it. Just one.
  5. Baseline Analytics: Include basic analytics from day one to track user engagement and system performance.

Idea 3: The Walking Skeleton Approach

Another approach to replace the traditional MVP is the “Walking Skeleton.” This method focuses on creating a fully clickable interface, essentially a complete UI, built with code, before any underlying logic is implemented. Acting as a pre-MVP, the Walking Skeleton allows stakeholders to interact with the prototype, providing a tangible sense of the final product without the complexity of backend functionality. This method helps stakeholders learn agility by iterating on this version, refining the user experience, and understanding the project’s scope more clearly. Once the interface is polished and aligns with the stakeholders’ vision, features can be prioritized and integrated based on what needs to launch first. Building out the application this way could be a lower stakes method for learning collaborative development, but it also doesn’t throw the baby (or code) out with the bath water.

Conclusion

By simplifying the MVP to these core elements, maybe we can mitigate the confusion and ensure everyone is on the same page about what the initial product will deliver. I prefer to end my posts the same way ChatGPT does, with a positive conclusion. But today, I’m less sure I can do that. I’ve read countless books, articles, and posts on how to define an MVP. I’ve helped launch hundreds of tech companies, and I’ve launched a couple of my own as well. So why is so difficult to launch when working with well-intentioned, intelligent, well-funded, people who are going through this process for the first time? I’m going to at least try Time Based MVPs and my new 5-Features rule on my next two projects and see if that helps. Wish me luck.