Skip to main content

The art of the professional apology

In my line of business it's often assumed that it's unwise to apologise. The same probably goes for most businesses. To apologise is to admit liability for at least part of a mistake that has been made. As a provider of a professional service, to apolgise is to reveal a vulnerability in the expertise that your customers have come to you for.

Yet a sincere, unlaboured apology can be an important part of the ongoing development of a business relationship. It can also test a relationship. Is the receiving party going to take advantage of the situation and press for discount, raising a volunteered admission of mistake as justification? And in that case, is this the type of customer you really want to be dealing with (if you have a choice)?



[This joker doesn't look particularly sincere - https://medium.com/@laurenholliday_/how-to-write-a-damn-good-apology-8b554513f8eb]

A sincere apology usually takes courage. It can in-fact be viewed as a sign of good judgement. An apology is often acknowledgement that you wish to surface an issue for discussion and seek to improve performance as a key outcome - and can signal that you wish to move on quickly and efficiently. Isn't that a desirable and valuable trait in a professional?

On the other hand, an unscrupulous apology can simply be a way to get gullible/naive people off your back when you are in the process of trying to swindle them. For this reason, careful attention to any apology volunteered in a business situation is prudent.

As a provider of a specialised service, it's of course also important for a customer to have confidence in your ability to deliver a quality outcome. In that regard, an apology shouldn't be volunteered frivolously. It takes practice to judge when an apology should be offered, certainly.



[Learn how to apologise proper - https://www.parentmap.com/article/the-power-of-real-apologies-in-a-fake-apology-world]

The art of the professional apology is not easy to master. In my opinion, to steer clear of using it altogether though can stunt the potential for development of deep mutual understanding - and productivity - in a business relationship. Like any powerful tool, the apology should be handled with care - with practice though, and used judiciously, it can enhance customer outcomes and enrich business success.


Comments

Popular posts from this blog

HOW-TO: Add/edit a field in Team Foundation Server 2012 using Visual Studio 2012

It's been a while since I made a purely technical post...

So, today I wanted to make a change to a Microsoft Team Foundation Server 2012 (TFS2012) instance that I am working with to reflect "Actual" time spent on a task - mainly for reporting purposes, and because I have found in the past that making this minor process adjustment yields a relatively useful metric over the long-term.

I am using the Microsoft Scrum 2.1 Process Template (http://msdn.microsoft.com/en-us/library/vstudio/ff731587.aspx) for a project that I am working with. So that I don't forget how to do this (again!) I will blog-post the procedure I've used to add this field to the template as a screen-shot-based tutorial, as follows...
Before Assuming you are familiar with the Scrum Process Template (2.1-ish) - open a task and take a look at the "Details" section, as follows:


 This is where I want my "Actual" field to show up.
Get the Power Tools Download and install the latest v…

HOW-TO: Apply a “baseless merge” in Team Foundation Server 2010 (and 2012)

Another purely technical post on TFS...
The scenario We wish to migrate code between branches that do not have a branch/merge relationship, in order to expedite urgent changes being made by a project team, without disrupting on-going BAU development work. Sample branch hierachy/strategy Imagine the following branching strategy in TFS (visible by connecting to TFS via Visual Studio 2010 or 2012):

Essentially you have a "DEV" branch, which has a "QA" branch, which in turn has a "PROD" branch. DEV is the branch that you would be using for BAU development. As a piece of development matures, you move it into QA, where it is tested by your internal QA team. There may be further changes made in DEV that are moved into the QA branch as the QA team pick up issues. Once the QA team are happy with a packaged of changes, they will move them into PROD, which is essentially the hand-over to the customer. The PROD branch represents the software that the customer has.

Mo…

Eclipse/Android error: "Multiple dex files define [...]"

Wow, I am really going nuts blogging this-evening - 2nd post in less than an hour. 


Anyway this is a particularly nasty error that I keep running into with Eclipse/Android when starting the emulator after I have not run it for a little while. Since I run the risk of permanently forgetting the solution to the problem every time I walk away from my Android project (and thus having to spend a painful hour-or-so digging up the procedure again), I will blog it here, for my benefit, and for the benefit of anyone who may also suffer the same problem.


The gist is that when you start the emulator in debug mode (that is, you hit the button in the following image), you get the following error message come out on the console and a nasty popup telling you nothing more than there is an error with your program and you need to fix it:








[2012-04-06 23:20:57 - Dex Loader] Unable to execute dex: Multiple dex files define Lcom/google/gson/ExclusionStrategy;
[2012-04-06 23:20:57 - SimpleList] Conversion to Dal…