Previous post in the series: Different Types of Projects
As I’ve mentioned several times before – as a consultant, many times you’ll face new scenarios, new people, and sometimes you may get into some delicate situations. In this post I’ll give some examples and discuss issues that I find important when working with clients (who are sometimes less forgiving than employers because of the nature of the relationship).
Be Respectful
This is a very sensitive issue and many people have stories about this. One that I specifically remember is when I was at a client site sitting in front of the computer with a developer, looking at PL/SQL code. The code was written quite poorly, but because I was cautious I asked him “did you write this?” When he said he didn’t, I allowed myself to mention out loud that the code is quite bad. I didn’t consider the fact that the person sitting behind us was the developer who actually wrote it, and when he said “it was actually me who wrote this” – I felt quite bad. This is not an extreme case and I quickly recovered from this, but this behavior can be risky. There are cases where this type of comment can cause a lot of damage to your relationship with the client.
Remember, there are always people behind any code, design or whatever you are working on. They make mistakes (and so do you, see below), make poor decisions, write poor code, etc. Still, you need to build a good relationship with them even if they didn’t or don’t do a good job (otherwise, they won’t want you to do yours and help them). Respect them, explain carefully what’s wrong and why. Teach and instruct them instead of being hard on them. This might give you more work in the future as they will appreciate you and will want to learn more from you.
I try to approach these cases as learning/teaching opportunities. Maybe they don’t know how to do things better? Maybe they need guidance and help? You can offer them assistance, courses or anything else that will make them better at their job. I always remind myself, maybe I know how the database works better than them, but they know how to develop better than me (in case of developers) and they know their business (and I don’t). We need each other to make things better.
Don’t Be Condescending
I mentioned this before (here) and it is very important to discuss it here as well. I’ve met some condescending people, and some of them were consultants. The problem with condescending people is that people usually don’t like working with them. As a regular employee, this can cause issues for you in the workplace, but it can be worse if you are a consultant. If you were a DBA in your client’s organization, and someone, especially an outsider, came and told you “oh, you are doing it completely wrong, it’s stupid, this is how you should do it…” you wouldn’t like working with them either and would probably not recommend working with them on future projects.
There are two problems with speaking and behaving like this. First, people don’t like it and they can complain about you so you won’t continue to work there, and second, sometimes this system is new to you and you are simply wrong. There are many aspects of their business or systems that you are unfamiliar with and might be the reason for doing something the way they did. I have had a few cases where I looked at some code or script and thought it could be done in a much better or simpler way until I understood some restrictions and factors I hadn’t considered.
Being Political
When you are a consultant, sometimes you are called in by a manager, but are then actually working with the DBAs/Developers/sysadmins (who may not feel like they need an external consultant). Especially in these cases (but not only), you need to play a political role. The risk here is that the DBA or developer might feel threatened. If you say they did a bad job, they might be considered as “bad employees” by their managers. This is a interesting topic and I will dedicate my next post to it.
When You Make a Mistake
It’s unpleasant to admit, but we all make mistakes, even the super professional people with tons of experience. If (or more correctly, when) this happens, you need to know how to minimize the damage while managing the mistake in the best possible way.
The most important thing is transparency. If you don’t explain what happened (and yes, you can definitely say it was an honest mistake), and the client realizes that a mistake happened by themselves, you are most likely out. But if you come to them first, explain what happened, apologize and start planning how to fix it (or even better, come with a plan ready), you are most likely be respected and understood and the client will be on your side.
Mistakes have obviously happened to me (or my peers) in the past a few times, here are a few examples: Once I almost deleted a production table (but I didn’t, so it doesn’t count), once I rebooted a production database because of a bad judgement call (I thought there was a serious problem that only reboot will fix, but this wasn’t the case) and once someone I know dropped a production schema instead of the test one. And these are only a few out of many stories.
In most cases, the damage is relatively small, so be honest and act quickly. Even if you fix the issue (like in my case of wrongly restarting the database), go to the client, explain and apologize and it’s usually going to be fine (I can’t guarantee anything of course).
In some cases the damage is real (like when dropping a production table or schema). In these cases you need to understand that you are the one who made the mistake. If it takes hours to restore, don’t charge the client for this time (and tell them that right at the beginning). You can bite the bullet and compensate them with some free hours or something to show them that you accept and pay for your mistakes.
In my career I have been involved (directly or indirectly) in a few serious mistakes but not even once did I have to go to court or pay a penalty for the mistakes (even though in some cases the contract allowed them to sue us, and they would have probably won). We (we were a team) handled the mistakes quickly and professionally and legal fall-out was avoided. We did compensate the clients, as it was only logical to do so.
My experience shows that the way to avoid such mistakes is to have ingrained habits and procedures in place to double check yourself before performing critical operations. Even now (after 20 years as a DBA), I select from v$instance before I shutdown a database, run “hostname” before I restart a server, etc. These habits will be the ones to save you from your next potential mistake.
One last point about mistakes is your contract with the clients. Make sure that the contract makes sense and will not bring you to your knees in case of a mistake. Clients can always sue you and the court will decide, but if a contract is reasonable, you are more protected. One example I can give (and I’m not a lawyer) is a contract I received with a paragraph saying that I am liable (with an unlimited amount) for any damage I cause them, directly or indirectly. I didn’t sign this contract (so many things can indirectly cause them damages, I can’t agree to have unlimited liability for that) and I lost this client.
When You Don’t Know Something
You can’t know everything, nobody knows everything (especially people who say they do), but for some reason, sometimes people expect consultants to know everything. When facing a case where I don’t know something, I find myself googling it or asking people without feeling any shame or a need to explain myself.
For example, if I talk to the storage person and I don’t understand how something works in their storage, I ask – even if this is considered common technology knowledge (and not a specific configuration). If you are pleasant and willing to explain the database side, they will usually be happy to explain their side in return. I’ve learned so many things this way, so just be open and ask.
I’ve also had extreme scenarios before. One of my consultants went to a client and searched Google for the syntax for a specific command. I got a phone call from this client complaining that my consultant is not expert enough (which was completely wrong, he was one of my most talented consultants). If something like this happens, you need to be patient and political and explain the situation.
In any case, it’s completely legit not to know everything. Use these cases as opportunities to learn by yourself or from others, and everyone wins.
When You Are Wrong
This is also something that happens (even if we don’t want to admit it sometimes). There are cases where we plan something, or give a recommendation, and we are simply wrong. It doesn’t work as we said, it doesn’t perform well or anything else.
Again, transparency and honesty are probably the key here. I have no problem saying “you know what, I was wrong” after I verified that it is, indeed, the case. In my opinion, people respect that, and even though I’m supposed to be the “senior consultant who knows it all”, we are all human.
Remember, being a consultant is all about the relationship with the client. Being technical and providing good solutions is only part of the job. Having the clients respect and trust you is just as important (if not more).
What about you? Do you have any examples of cases where your personal skills made you a better consultant or employee? Feel free to leave comments or follow up questions below.
Get updates when I publish new posts – subscribe here:
Becoming a Consultant series:
Upcoming post: Communication
All posts: