Corporate Politics: 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 conversion software was being modified from previous similar conversions. Existing bugs in the software were being ironed out unless 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 that was vetoed despite the projected benefits. The client department 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.

Names and minor details have been changed to protect client confidentiality. This case study should not be taken as an exact solution to a similar situation in another company. It is only presented as an example of one solution to this type of problem and is for illustrative purposes only.

Case Study

I was unaware of having Asperger Syndrome, although 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 by now that I would get along with some people, but others could take offence and keep it no matter what I did.

We were converting loans accounts by modifying software used on previous conversions. I worked on the last 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 those three conversions. In one case it nearly caused us to miss the deadline. 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. I will call it code block A.

This would be the first time I worked on code block A directly instead of just contributing ideas. Once again, I brought up the needed change and once again it was vetoed with assurances that minor adjustments were acceptable. Not wanting to cause problems, I resigned myself to adjusting code block A for this conversion as requested.

All was well until one week before conversion. This particular acquired bank had more accounts than usual 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 again I was warned off. As time wore on and the test files became bigger, the adjustments made less difference and more exceptions showed up in the test results.

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. This was a tactic they had used successfully 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. It was insulting to me because at that time my programming skills were a source of my 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 I could be fired for scaring the client group, but I could also be fired if the exception count was not significantly reduced. 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 valid. 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 was on good terms with Mike, Joanne and the client group.

Summary

Looking back, I can see that blunt explanations are not always the best strategy. The bank considered the ability to convert data from an acquired bank over a weekend to be a competitive advantage. This way, customers would see little or no difference in operations 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 going forward.

It would have been better to start by winning over my immediate group leader first, then the next higher manager, and so on. This would move the proposal across the spectrum from technical to non-technical people gradually. This would also gain support while progressing to the client group a little at a time. Having several people already on my side would reassure them that my proposal had merit. After all, it was tested in other brains and approved, thus reducing the appearance of risk. Success would not be guaranteed, but the chances for success would be much better. Some people are scared by bare facts – they need a softer explanation. Respect that, and you can win those people to your side.

It was especially important to keep my thoughts to myself when I was angry. 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 the injustice without firing insults at anyone. This left the door open for the improved relationship we had later. Insults flying back to the other side would likely have prevented that. I never mentioned the unannounced change to allowed data, so the client group would not become defensive about it and shut me out.

It was no less important that I did work with the client group instead of acting like a loose cannon with a bad attitude. I did things their way whenever I could and offered 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 without a bad attitude. 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, I saw about seven or eight other programmers wrestle with code block A by adjusting it to extremes. The idea to rewrite it came to me 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 the same way. In other words, I found the solution as a result of coping with Asperger Syndrome ten years before I even heard of it. My non-AS coworkers were very competent and creative but did not have that advantage.

Managing with Asperger Syndrome