Previous post in the series: Personal Skills
When consultants meet new clients, they also get into a realm of unknown politics. It can help you a lot along the way, or cause significant damage that may be hard to recover from. In many cases, very technical people are not interested in politics, or simply decide to ignore it saying: “I’m a technical consultant. Someone calls me to solve a problem, I solve it. I don’t care about the politics around it”. In my opinion, this is a dangerous frame of mind, and let me explain why.
What is “Workplace Politics”?
According to Wikipedia, “Workplace politics is the process and behavior in human interactions involving power and authority”. When you, as a consultant, set a foot in a new place to solve a problem, work on a project or whatever you are requested to do, you are entering an unknown territory with politics that you’re not aware of. You will probably be introduced to the manager who invited you and the technical people you’ll be working with, but you have no idea what the relationships there may be. These relationships can vary and they can be very complicated at times.
Let me provide a few hypothetical examples:
Example #1 – the boss belittles their team. In this case, if you manage to solve an issue they were unable to resolve, or explain that they made mistakes; the boss might get angry at them and maybe even fire someone. This is not your fault of course, so why would you care? Because you don’t know the relationship between the manager and the team, but do you know who does know this? The employees. If they think this might be the outcome, you can bet that they will do EVERYTHING they can to prevent you from being able to fix the issue or find problems. Now it becomes your problem too, as you probably will not be able to solve anything without their cooperation.
Example #2 – one of the employees on the team tends to take credit for everything, even if someone else actually came up with the main idea to solve the problem. So when you find and fix the issue, this person might try to take over and take the credit. If you fight back against this – it may look petty as the new person that nobody knows. If you let them take the credit, the managers might think that you did not contribute anything, so why should they call you again?
See what I mean? Read the situation wrong (or don’t read it at all) and it might be very difficult for you to explain why they needed you or why they should call you again. These were extreme examples, but let’s leave the hypothetical scenarios and talk about few very real ones that I personally experienced and how I dealt with them.
A Simple Harmless Example
I’ll start with a very simple and harmless example where not being familiar with the internal politics could have caused an issue. One day I got called by a technical writer to help with documenting a product. This was a large software company in which the product development had been completed by the development department, and the product was transitioned over to the support department. The support department had hired this writer to document the product and since it had a large database part, I was contacted to work on the database chapter. When I asked how I could contact the developers to get some information on the product, I realized that this was a political mess.
The documentation was supposed to have been written mainly by the development department, but the support said they did a crappy job. So the support decided to build new documentation, but they were not supposed to do this, so they were not allocated funds for it. I don’t know where they got the funds from, but it seems like it wasn’t a completely above board task, so I wasn’t supposed to “expose” that this is what I was working on when talking to the developers and asking questions about the product. Told you, a mess…
In this case I only needed to be careful, but this did not affect my ability to do the work they requested or anything, so it was harmless. Let’s move on to some more sensitive examples.
Politics of Solving Issues Fast
Many years ago I was called to look at a performance problem. A large system at a large client’s site had been slow for a couple of days and everyone was stressed. The DBA team was very competent and reputable, and had great people, but it seems that they weren’t able to figure this out. I got there around 2pm and started asking questions. It didn’t take me long to ask “when did it start?” and “what changes happened during this time?” The answer was that it started after an upgrade of the database from 32-bit to 64-bit (I think this was 9i, where Oracle on UNIX had both 32-bit and 64-bit versions). I immediately remembered reading about this not too long before, and read that the shared pool needed to be doubled in this case (which makes sense since all the pointers and some memory structures have doubled).
The DBA team didn’t believe that this was probably causing the issue, but they tried changing it anyway. This indeed solved the problem, but the team wasn’t very happy (as it seemed such a simple thing that they “should have” been aware of). Without any bad intention on my side, they may have been worried that their boss might think they are not technical enough, as I managed to solve it so quickly after they had been working on it for a couple of days (I think it took about 2 hours in total, although they kept me there for another 2 or 3 hours “just to make sure that it doesn’t come back”).
The key in such situations is to be cautious when talking to the management and explaining the solution. As a general principle, I try to never imply that the team is “inexperienced” or “unprofessional”. On the contrary, I will always try to say things that will empower the team, and explain that I happened to have run into this problem or read about it in the past, but that if I hadn’t – it wouldn’t have been trivial to identify the cause of this problem (so to chalk it up to specific experience and not overall technical ability/skills). The goal is to please everyone: the manager will be happy because the problem is solved (and THEIR manager is off their back), the DBA team will not feel like you swooped in and threatened their authority and you will be appreciated.
Just as a side note, I ran into the DBA team leader about 10 years later and they still remembered this case. I’m not sure if it was a negative or positive memory, but it’s there, even after 10 years…
Politics of Solving Issues At All
Being sensitive to the potential politics between the team and their manager is not only relevant if you solve the problem quickly, but also each time you manage to solve the problem at all. In many cases you’ll see that the technical people you work with are intimidated. This is not because of you, of course, but because of the situation “you” got them into.
In another project I had, it took a few days and the performance problem I was asked to handle was indeed solved. During the conclusion part we had a meeting with two department managers (one was the DBA manager and the other one was the dev manager whose team was experiencing the issue), and I started explaining the reason behind the problem and the solution. During this meeting, the DBA I had been working with jumped in a few times and added to my explanation. This looked to me like they were trying to express themselves and demonstrate their contribution to the process of solving the issue. I could have interrupted them and been the only speaker at the meeting, but instead I helped them and gently took over sometimes when they didn’t get it completely right or when I wanted to clarify or add something.
Here, again, this created a win-win situation. The DBA knew that they needed me to solve the problem, but it also allowed them to demonstrate to their boss that they had helped and learned something during the process. Now they both (the DBA and the manager) appreciate me and will happily call me again if needed.
Politics of Being the Outsider
In another story I was called to solve an issue and was working with the local DBA. After my research, I wanted to implement some changes and some of them were quite trivial. However (and this is very important, check the “respect” part in my previous part), I didn’t try to belittle the DBA or make it sound like they didn’t know this (trivial) stuff about Oracle. When I explained what I was thinking, they actually said “I KNOW! I’ve been telling them I want to do this for a year now! They wouldn’t let me”. So this DBA was actually quite knowledgeable and the fact that this trivial solution had not been implemented was in no way their fault.
This is where you can play the local politics for the benefit of the project. When you are brought in as an outside consultant, considered by management to be very experienced and paid good money for your expertise, they will usually (although not always) listen to you (even if you are saying something similar to what their own DBA has been saying). You can use this to help the local DBA and raise the internal respect for their abilities. You can explain to the managers what you think should be done and mention that you discussed this with the local DBA. Explain that they already knew this and had suggested it in the past, and that you completely support their thought process and decision making in this case. I know that you may be worried that this will make them realize that possibly they don’t need to call you in the future as it may sound like “your DBA is great, why do you need me?”, and yes, maybe sometimes it will prevent them from calling you for more trivial things in the future. But if it works well, and the DBA recognizes you giving them the credit that was due, they will not feel threatened by you, will remember you, and call you whenever they really need some assistance.
The Risk of Ignoring Politics
One last topic to talk about is what happens when you just don’t care about this stuff. When you are only focused on the technical solution, you can easily annoy people. I’ve heard stories of consultants belittling the local DBAs, getting into heated arguments with them and even using inappropriate language (this is more of a respect issue, not politics, as no-one should be using inappropriate language whether you are an internal employee or an external consultant).
In most of these cases, the consultant ended up losing the contract. In one extreme case, human resources even got involved. You don’t want to get into this situation. In a few cases, the managers may appreciate the consultant’s technical skills enough to keep them on despite their behaviour, but I’m sure their job won’t be enjoyable or easy as people won’t want to help them. Also, people they work with will remember them negatively. When these people move to other positions and other companies, I’m sure that if such a consultant’s name comes up in the new company/role, the person would spread a very bad reputation about this consultant to avoid working with them again. Think about a case in which your actions will cause a manager to fire an employee or another consultant. What will happen with those people in future when they are with new companies? They will definitely not want you there. I’ve seen it happen.
Don’t be like this, work with the DBAs and not against them. Help them grow and in time, they will help you as well.
How to Handle Politics
When you are a consultant, sometimes people believe that you being there is a statement that they weren’t able to do their job, so they push back. I truly don’t believe that. I’m not at all sure that I would be able to do their job better than they can. I want to believe that I am doing MY job better than them, and MY job is to help them do whatever is needed. I may have more experience or exposure, but they are the experts on their systems and processes.
In many cases people are nice and helpful and want to solve the issues, and all goes well. But be aware that politics exist, even with the nicest people and even if you are not part of the workplace. Just like us all, people working there want to be appreciated and don’t want to feel unnecessary or incompetent. Work together, always listen to their side and input (they know things you don’t, especially about their systems), and let them be part of the solution.
When I work on a problem with someone, I always explain what I am doing and why. This is important for several reasons: first, it helps me think out loud and organize things in my head; second, it keeps them in the loop on the thought process and they might throw out a piece of information I am not aware of or an idea that will help; and third, it keeps them engaged, appreciated and invested in working together to solve the problem as a team.
When it’s time to present conclusions to management, I always use “we” and not “I” when explaining what we did. I willingly let them take part of the conversation/explanation (and if they make a mistake or are unclear, carefully clarify without pointing out their inaccuracy). Don’t hesitate to give them credit, and make sure to explain that although you are the “expert” called in to help, the solution was a joint effort and couldn’t be achieved without them. You don’t have to specifically say this in those words of course, but if the meeting with the management is full of respect and explanation about joint work, your respect for their abilities and contribution will be very clear to both the DBA and the management.
And lastly, this is where future work can be planned. If you notice a gap in the DBAs knowledge, explain this gently (they might have realized it themselves while working with you) and offer more services (like training). If you managed to solve the immediate issue, but saw that something is not perfectly stable yet, you can use this conclusion meeting to explain that you have made great progress, but that you noticed that there are still things that can be done to improve the system and that you’ll be happy to continue and help. But if there are no such items, don’t force it. As a consultant, I’ve said in the past: “your DBA is very knowledgeable and experienced – listen to them. I’ll be happy to come again, but you don’t really need me, unless they feel that I can contribute”. I know that this probably cost me a few hours, but will open the door to projects in the future with people who appreciate me, where my expertise will really benefit them, so it’s worth it.
How do you view workplace politics? What do you think? Do you have stories of your own? Please shared them or add any comment below.
Get updates when I publish new posts – subscribe here:
Becoming a Consultant series:
Upcoming post: Communication