Corporate Politics - Politics vs. Necessity

Politics vs. Necessity

Bob was a computer programmer working on a contract with a large local bank. The project was to convert some loans accounts from the system of an acquired bank to the client bank’s loans application. The software was being adapted from previous conversions and correcting existing bugs in the software using a manual adjustment process was more cost-effective.

One bug became a political issue because it affected a block of code that eliminated a huge amount of manual adjustments. The code block needed a rewrite, but the client group decided against it despite the projected benefits. The client group responsible for the conversion was afraid to do more than minor adjustments to this code. The problem came to a head when the minor adjustments were not enough, but the rewrite was still not approved.

Exact details and names in this case study have been changed for confidentiality reasons and the solution advocated is not transferable. The views expressed are personal, for illustrative purposes only and should not be related, or automatically applied to, other situations or scenarios.

Case Study

I had never heard of Asperger Syndrome, but I knew I was different from the people around me in subtle ways. I had a blunt manner of expression, lack of eye contact and a tendency to focus too closely on tiny details. I had learned that I would get along with some people, but others could take offence and keep it no matter what I did.

I was trying to make friends with my coworkers by swapping jokes with them, but doing so constantly caused me to lose credibility with my co-workers and managers. I enjoy getting along with other people, but I have always felt isolated from them. It was a constant struggle to try to understand them and fit in.

We were converting loans accounts using software modified from previous conversions. I had worked on the previous three conversions so I knew the overall strategy: convert what we can with software and handle the exceptions manually. I was also familiar with the code.

One piece of code in particular bothered me because it had a subtle design flaw that had remained in place for thee three conversions. I had fixed this problem at another bank, so I knew correcting the error would reduce the exception count by at least half. I had mentioned the flaw and the solution earlier to my project leaders, but could not get them to approve the change. The work was done at a hurried pace, so there was not a formal change process in place. All suggestions were made verbally to the group leaders, who responded verbally. I will call the code in question Code Block A.

Code Block A was written by another consulting firm for the first of the four conversions on which I worked. Their chairman was a friend of the chairman of the client bank, so their word was inviolate. Of the previous three conversions, they ran the first and third ones and created the overall code structure used in all of the conversions. They argued against changing Code Block A. It may have been because they did not want to look bad, or because I worked for a rival consulting firm, or other reasons. They almost missed the deadline for the third conversion and blamed problems with Code Block A. After that, the client group was wary of making any but the most superficial changes to the code. Missing a conversion deadline could get the whole group written up or fired.

This would be the first time I had worked on Code Block A directly instead of just contributing ideas. The other consulting firm was not involved in this conversion. Once again, I brought up the needed change and, once again, I was assured that minor adjustments were acceptable. Not wanting to cause problems, I resigned myself to adjusting Code Block A for this conversion only as requested.

All was well until one week before conversion. This particular acquired bank had more accounts than expected hitting Code Block A, so the error was becoming a serious problem to the client group. They were making more manual adjustments during testing than they could handle comfortably in the conversion time line of one weekend. On the plus side, I had Code Block A almost memorized from all of the adjustments I made. I told Mike, my group leader and a fellow contractor, that it would take about 2 hours to rewrite the code, but was told it would be too risky and that the client group was too afraid to allow it. The latter had a lot of political power, so the managers on the technical side would only insist upon a change when they felt certain they could win. As time wore on the test files became bigger, more problems were uncovered, the adjustments made less difference and the number of exceptions grew larger.

Finally, the client department told Mike that they did not think I was competent to make Code Block A work properly and they wanted someone else to work on it. They did this on prior conversions to prod the programmers to work harder and produce better results. This was insulting to Mike, who assured them I was doing what - could be done - effectively. It was insulting to me because at that time my programming skills were a source of self-esteem. I felt personally attacked and extremely angry. This was on a Friday afternoon. I was careful to say very little before I left for the weekend.

Friday night, I discussed the problem with a friend of mine at dinner. I decided to go in on Sunday for a few hours and rewrite Code Block A the way I had proposed earlier. I knew the client group could have me fired for scaring them, but they could also have me fired for not reducing the exception count significantly. On Sunday, I backed up the existing code, then made and tested the changes. There was a 90% reduction of exceptions with the most recent test data. Satisfied (and I have to say, a little smug) I went home.

Monday morning. I arrived late due to a doctor’s appointment. I found an upset Mike warning me that I was in very deep trouble. It took several minutes to calm him down enough to find out that a new test file had come in and my program blew up. The code changes were discovered and reported to the client group who promptly panicked and demanded an immediate return to the original code. I tried to explain but Mike was too upset to listen, so I asked for the details of the program error and saw that it would only take a few minutes to correct. Mike started telling me to leave it alone so the original code could be restored. I could not reason with him, so I snapped at him to just give me ten minutes, okay.

Sure enough, a combination of input values that was never supposed to be allowed in a million years was in the test data, and it was newly approved. My, how time flies. The error happened in the new Code Block A but it would have happened in the original code, too. It only took ten minutes to correct and retest the code. The reduction of exceptions compared to the previous test was very near 90%. I showed Mike the results and apologized for snapping at him. He forgave me even as he expressed shock at the test results.

Half an hour later, the client group called Joanne, Mike’s boss and a manager with the bank, and raved about the results. I went from zero to hero in less than an hour. After that, whatever I said was gold. I was careful to keep most of the satisfaction to myself. The conversion was deemed one of the best ever and I ended up on good terms with Mike, Joanne and the client group.

Review

Looking back, I can see that blunt explanations are not always the best strategy. Prior to doing contract work, I was an employee at the same company for 15 years and stayed out of company politics, so I had little experience to draw upon. I tried to be confident and self-assured, but my attitude came across as cocky and arrogant. To my bosses it was offensive and looked like a challenge to their authority.

Even though my apparent attitude was unintentional, I alienated them. They needed me to show that I understood and respected their authority, responsibilities and roles on the project as well as my own. No manager will last for long without the voluntary support of the employees. I also did not understand how subtle nonverbal cues worked alongside of words. My nonverbal cues were not synchronized with my words. To them I was not sincere about what I was saying.

I also was lonely and craved acceptance and friendship from my coworkers. I constantly made wisecracks and told jokes to win them over. Not only were they wary of me, but they thought I was weird. Only my simplest suggestions were taken seriously. For anything else, the answer was “I’ll have to think about that” and nothing further was said. I would have been much more effective if I had shown my bosses a more professional person and kept the humor in check. They needed me to be someone they knew they could count on. With my poor presentation of myself, I became my own worst adversary in any argument.

The bank saw the ability to convert data from an acquired bank over a weekend as a competitive advantage. Customers would see little or no difference in their transactions from Friday to Monday. The client group in charge of converting these loans had nearly missed the deadline on past conversions, so they were naturally wary of rewriting anything. It would have been better for me to start by winning over my immediate group leader first, then the next higher manager, and so on. This would have moved the proposal across the spectrum from technical to non-technical people gradually without missing anyone in the chain of command.

One sure way to alienate most of your bosses is to bypass any of them. Keeping them in the loop respects their desire to do a good job. This would also have built support on the way to the client group and reassure them that my proposal had merit. After all, it was tested and approved in other brains they trusted, reducing the appearance of risk. Success was never guaranteed, but the chances for success would have been much better. Different people need different presentations. Respect that, and you can win those people to your side.

It was especially important to keep my angry thoughts to myself. The wrong words, properly delivered, can damage any relationship beyond repair. My statements to people higher up were chosen to focus on the project without making personal statements about anyone. When I felt attacked, I protested without firing insults at anyone, which allowed the improved relationship we had later. Insulting the people in charge could have prevented that. I could have scolded the client group for the unannounced change in the test data, but then they would have become defensive and shut me out.

It was no less important that I worked with the client group instead of acting like a loose cannon with a bad attitude. I did things their way whenever I could and tried to offer alternatives in a respectful manner. However, once the situation degraded to the point that I had no choice, I decided what to do and did it while projecting the best attitude I could muster. Snapping at Mike was an absolute last resort after several attempts to reason with him. I apologized as soon as possible and let him know it was not personal.

Oddly enough, seven or eight other programmers had wrestled with Code Block A by adjusting it to extremes. I had the idea to rewrite it because I had tended to focus too much on tiny details, so I had to make a habit of backing out my point of view from details to a broader perspective. I backed out my point of view from adjustments to a rewrite using the same method. In other words, I found the solution because of coping with Asperger Syndrome ten years before I even heard of it. My non-AS coworkers were at least as competent and creative as I was, but they did not have that advantage.