The Rotting Stink of Corporate IT

My friend Lisa has a prejudice against those lip glosses that come in a little jar. The kind you dip your finger in and rub on your lips? She calls them little petri dishes, with all the bacteria and germs from your fingers just living in there waiting for their next home.

I see many similarities between lip gloss germ factories and corporate IT. There are good bacteria, and there are bad bacteria, but what they have in common is that they fester. The good developers fester in frustration, the frustration of change request forms. The frustration of knowing the right thing to do, and not being able to do it until four months later when the "budget is there." The bad programmers are festering in sloth, in the fact that their work goes largely unnoticed and as long as their tie matches their shirt we can ignore the fact that their classes go on for days, and their code is illegible, and their methods are bloated. In these environments you are taught that to care is to waste time, and the only thing that is important is that it GETS DONE, not if it is done right. A culture of apathy and wanton disregard for standards is all that is being enforced.

The biggest issue here is not the bad programmers, it's not the suffocated good programmers, as they say "A fish rots from the head." Management is who decides what the priorities are. If the priority is to "get it done so it works for now and ship it out" you will get exactly what you asked for. It starts at the top, when the CTO puts pressure on the IT Directors who put pressure on the Department Managers who in turn flip on their coders and turn the screws that bind them. Some symptoms of this are projects that are constantly coming back for work, deadlines that are constantly pushed, and the blame game from QA to the developers to the testers.

Can a large corporation have a healthy team? Yes. I didn't used to think so, but I have kept my eyes and ears open. I haven't experienced it, but I have met people that have shared their good experiences. The friends I have that are in corporate IT that are also happy have always had one thing in common: small teams. When you break up a big group into small teams, and hold the leaders of those teams personally responsible for the health of the team it succeeds. When you give them the tools they need for success, when you make it about who is contributing the best, when managers take the time to examine who is touching the code and IF what they are doing is the best solution, that's when you can succeed. When you allow for enough time and budget to make sure that things only need to be done once, and changes can be easily made, that's when you can succeed. The Five Dysfunctions book is a great place to start if you are looking to do so. I can imagine it's hard work, but when you look at companies like Microsoft and Google the reward is obviously worth it.