Politics in IT: Separate Operators From Performers
There's politics in IT. Are you shocked to hear it? I didn't think so. But it can be negotiated. It comes down to knowing what sorts of people are around you. I'll get to that in a bit, along with some advice for dealing with the bad players, but first let me tell you about two times in my career when politics came to the fore.
Incident No. 1
I had just renegotiated a multiyear contract with a major outside IT service provider that would save the company $6 million in each of the next three years. I was feeling confident about my competence as CIO, but at the same time, I saw indications that my days at this company might be numbered. The CEO who had hired me was now leading a rival company. We had been close, and a couple of my peers on the senior management committee had asked me whether I would follow him. There had even been subtle suggestions that I might be feeding our former CEO information about how our IT function was used to outcompete the competition. It was a baseless suspicion, but it's not easy to remove such a stain even when you're completely innocent. Shortly after my success with the renegotiation, the new president and CEO called me to his office. Once I was there, he cordially congratulated me on my negotiating success. In fact, he said, my performance had been consistently superior, but due to reasons he could not discuss with me, he would have to let me go. My competence was not called into question, and that was gratifying, but I was out of a job anyway.
Incident No. 2
Seeing the executive who hired you move on isn't unusual, of course. When it happened to me another time, I was left reporting to a committee of three senior executives who didn't know what they wanted the IT function to do. They would ask me what I considered to be the best path to take, but my carefully weighed responses would be interrupted by them as they argued with each other. I was being given three competing lists of priorities, and pointing out their contradictions only prolonged the meetings. None of them would give an inch. If they all hadn't had other meetings to attend, those sessions might have never ended. No one can serve two masters, and I found myself with three. I wasn't learning anything, which has always been of great importance to me, and I had the feeling that my situation was going to end poorly, so I began looking for another position. As soon as I found one, I resigned. Again, my performance was not the issue, and even though I had moved on through my own initiative, another change in my career happened because of events I had no control over.
I'm a believer in focusing on performance and developing relationships. But as these two incidents illustrate, even when you do that, you can be hit by the unexpected. But you know what? That's OK. The point is that the proactive competence that I have been preaching will indeed serve you well in the course of your career, even if it can't save you from every bumpy political situation. The truth is that when you run into the sort of trouble that I just described from my own career, you are running up against people who aren't the sort of proactive leader that I advocate. And chances are that when things reach a point where you can't continue to serve a company, it's really for the best that you get on to the next chapter in your career.
Not that you can run away from every job that presents you with uncomfortable politics. You would constantly be on the run. It's actually possible to overcome many political situations. The first step is to learn how to read people.
Two kinds of people
When it comes to workplace politics, it's helpful to learn how to differentiate the performers from the operators.
Performers are the people whom you to want report to, whom you want to hire for your team and whom you're happy to see among your peers. They have a high standard of behavior, a committed work ethic and a well-developed sense of integrity. You can't identify them by their education; they could be Harvard graduates or high-school dropouts. But they exude knowledgeability about their profession, as well as intelligence. They exist at all ranks, and whether they are in the corner office or a cubicle, their conduct is basically the same. They perform in a consistently superior fashion, giving the impression that they would rather do a good job and have it appreciated than almost anything else. They believe that their efforts will be recognized and rewarded (naïvely so, if they're working for an operator). They might make mistakes, but they are quick to own up to them and waste no time in dealing with them. They learn from their mistakes and never make the same one twice. Performers are also genteel, considerate and effective communicators. They work well with and support others. You can be certain that they will do the right thing even when you are not there to know that they've done it. They are happy to share credit for successes. They honor your belief and trust in them. I admit that all of this sounds too good to be true, but I can give you names.
Operators focus on pleasing upper management, being in control of all aspects of their organization and using any achievement to their utmost advantage. They tend to hire people less capable than themselves, sycophants who can be controlled, mostly by intimidation. That helps assure that upper management won't see anyone more capable to promote or replace them with; by default, they look like the only go-to person in the department. Any direct report who is capable and unintimidated is seen as a threat. If the employees who are perceived as threatening can't be bullied, they are subjected to a campaign of informal new requirements meant to encourage their departure. An operator's ethics can be summed up as "whatever it takes," which means that any good ideas will be appropriated, i.e., stolen. They have no compunction about spending time and resources trying to find out whom to blame for a mistake. Again, educational background is not an indicator, but operators are not knowledgeable about what they do; in their minds, taking training would be an admission that they don't know something. Their management style is reactive, and so they often have to accommodate surprises that would not have happened if they had a knowledgeable strategy in place. Worse, they actually like things this way; they figure that if they are seen to be the first person to throw water on a fire, they will be perceived as a hero, even if they started the fire in the first place. If someone you have pegged as an operator makes you feel important, you can be certain that they need something from you and that the situation is temporary. Operators love to flaunt any symbols of power they accumulate. Even the remote possibility of the limelight attracts them. If they work hard, you can bet that the sole reason is to be perceived by upper management as a performer. They are masters of creative half-truths, innuendo and stalling tactics such as "I'll certainly get back to you on that." At bottom, they are very insecure, always scared of being found out. I have seen more than my share, and once again, I have names.
Operating with operators
I think I'm safe in assuming that most of the people who are reading this are performers; learning from someone else's experiences is not an operator mode of operation. There's no need to tell you anything about how to work with other performers, other than to pay attention and be prepared to learn. But performers need to protect themselves from operators at all levels, whether you report to them or have some on your own team. (It happens to the best of us.)
When it comes to your team, it's essential that you identify the operators and then either change their behavior or replace them. Doing nothing will sap the motivation and momentum of your performers, who may even begin to leave.
Identifying operators who work for you isn't as hard as you might think. I routinely had meetings with all levels of my staff and told the intervening levels of management that I wanted to deal with the team members directly without their involvement. Any manager who nonetheless showed up at such a meeting was behaving like an operator: Such managers felt compelled to find out who was saying what to me, and they couldn't bear the thought that their reports might be talking about them or how they were treated. If no managers show up but no one at the meeting can suggest any improvements and no one engages in unguarded dialog, you probably have found another operator. Staffers who report to an operator often feel too intimidated to talk honestly even when the operator isn't around. Another good tip-off that someone is an operator is an inordinate amount of self-serving credit-taking. Keep in mind that operators who report to you consider you to be upper management, and operators are always trying to present themselves to upper management as the one worthy and reliable person at their level. Everyone should be allowed to take a bow now and then, but with operators, this tendency is excessive.
If you report to an operator, you have more work of another kind to do, but if you are diligent, you will be left alone and have plenty of time to make good and lasting things happen with your team.
You should start to guard your flank as soon as you suspect that the person you report to is an operator. (You don't have to confirm your suspicion; the precautions that I recommend taking are in themselves innocuous, and if it later turns out that your boss is a performer, no harm done.)
Operators thrive on informality, which makes it easier for them to rewrite history or feign convenient amnesia as they contradict your version of events and agreements. To protect yourself, you must become a master of formality. You have to adopt the rigorous habit, as soon as possible after every meeting, of drafting a concise e-mail that reviews the course of action that was decided on, the direction that was given to you, the exact parameters of any assignment given to you, and time frames that were agreed to. My memos tended to start off with a statement such as "I have already begun to implement the actions we discussed at today's meetings, but before my people get too far along, I want to ensure that I haven't misunderstood anything." Then I would go on to outline everything as I recalled it, and I would always close with words such as "Please let me know if anything in this e-mail does not reflect what you understood."
Sometimes, you'll have to take action before you even leave the meeting. Your boss might give you a new assignment that you realize your team doesn't have the resources to handle because of earlier projects that already have you at maximum capacity. (If your boss really is an operator, then he or she probably already knows this and is simply seeing what can be gotten away with.) When it happens, you have to speak up, no matter what heat you might get for doing so. Tell your boss that you can probably handle this new assignment, though it could mean rearranging things and finishing some current projects later than planned. Be reassuring -- "If we can handle it, consider it done." Then do the e-mail thing again in a day or so to inform your boss that unless you can agree on a way to restructure existing priorities, the new assignment will have to wait. Again, end with words to the effect of "Please let me know if anything about this is not clear."
If your boss is an operator, he or she will push back on all this documentation and suggest that all of the follow-up isn't necessary. That is pretty much confirmation of operator status. Which means, of course, that you should not go along with the suggestion. Your e-mails are an insurance policy, making it much more difficult for an operator to pull you this way and that, according to whim.
Those initial follow-up e-mails aren't the end of it. As projects move along, you should have your team, on a monthly basis, keep track of the progress of all formally agreed-upon goals assigned them. Six weeks before your annual review (or your probationary period if you're in a new position), summarize everything carefully. Quantify as much as you can. Demonstrate progress against all your goals, showing how you achieved those that were reached and noting when your performance exceeded the target. Don't just say that projects were completed on time, for the agreed cost and as specified; provide the evidence. If your team was called on to handle ever more units of work, spell out their increased productivity. If they received kudos from your clients, forward them. (And it's a good idea to solicit as much praise from your clients as possible.) Then summarize all of this from the shareholder point of view, explaining how your team avoided cost, improved service or increased revenue.
About a month before your review session, send this report to your manager. Explain in a cover note that you thought this outline of the past few months' progress would be a handy guide during the review process. Of course, the operator manager is going to helpfully suggest that you spend your time on projects other than writing up things that the manager already knows all about. Don't be dissuaded. Just say that it was no trouble, because all of this material was generated by your direct reports anyway, as a way to allow you to objectively measure their performance; it was no trouble to gather it all together and send along to your own manager.
Formality is your antidote to operators' behavior, and dispassionately dealing with every exchange with them will serve you well. Even melodramatic, undisciplined bullies know when the evidence is against them.
Yes, these formalities will take some of your time. You'll find, though, that this will be a very small price to pay for making obstacles to your team's achievement simply vanish.
And your team members' recognition and rewards will be undeniable.
Al Kuebler was CIO for AT&T Universal Card, Los Angeles County, Alcatel and McGraw-Hill and director of process engineering at Citicorp. He also directed the consulting activity for CSC Europe. He is now a consultant on general management and IT issues. He is the author of the book Technical Impact: Making Your Information Technology Effective, and Keeping It That Way, from which this article was adapted. He can be reached at firstname.lastname@example.org.