Yeah, I know, I haven't been around much lately. Between my new house getting started (foundation is done!), my increasingly interactive son, the MBA classes, an interesting side project, and my day job I'm pretty much crushed for time. However, I felt the need to share a recent experience of mine, with names and locations omitted for the protection of the not so innocent.
I show up for the new project all bright eyed and ready to write some quality code. What I experienced led me to do something I have never before done in my career: I walked off a project after less than a month. Upon reflecting on this experience, I've decided to share my observations with the blogosphere in the hopes that some department mangers pick it up and learn from my experience.
Sin #1: Politics
Politics are evil. Politics will happen. It is the job of the executives in an organization to prevent politics from causing undue hardship on employees. Certainly everyone has their pet projects and their own career in mind at some level, but this should never be allowed to impede the direction and goals of the department. Here are some examples of how politics can wreak havoc on your IT operations:
Manager in customer department A hates manager in customer department B: and intentionally designs application requests to cause hardship for department B. The way to combat this is to make sure that when the flow of data crosses departments you make sure to involve someone in the other department.
Us Versus Them: This is one area where I really favor the agile teams concept where you construct your teams not by job responsibility but by project so that you end up with a developers, dbas, quality assurance, and end users as a team for the duration of a project. This helps eliminate the us versus them attitude that can crop up across teams.
If you can't say something nice: One of the first things I do in a new organization is go around and interview the people I will be working with across teams and departments. It is a huge turn-off when you discover that no one has anything nice to say about everyone else. This type of backbiting is not only very unattractive for the new hire to see, but also points to a managerial problem that grudges have been allowed to fester. This is especially important if you are in a leadership position. It's downright unprofessional and destructive to badmouth other workers.
Sin #2: Zealotry
Zealotry is bad mmmkay? Zealotry blinds you to new ways of thinking. Zealotry rears it's ugly head in several ways in IT.
If we didn't code it, it can't be good- You've all met this developer. They never want to take advantage of third party tools. Rather than spending $250 on Peter's Date Package they would prefer to spend thousands of dollars worth of labor hours to build their own date control that isn't as good.
I've done it this way before- Yeah, and when you were small you used to handle going to the bathroom by crapping your pants. =) If you're going to advocate an architecture or pattern instead of just assuming that the way you've done it before is right and proper be willing to explore other avenues, this is how we grow. In particular if there are Microsoft KB articles specifically stating that the approach isn't the best option maybe you should avoid it (personal gripe).
If it's not <company> it can't be good- Yeah, I love Microsoft products. But I don't mind working with Oracle, SAP, etc. It is the goal of IT to make use of the most appropriate tools for the task, not to stay in your individual comfort zone. Both this issue and the previous one are tied to fear of the unknown and a resistance to learning, which is a bad thing for anyone involved in technology.
Sin #3: Closed Communication
I personally believe that every IT department should strive to staff itself with workers who are able to interact with the end users in writing and speech. Yes, if someone is a uber programmer and has the people skills of a rock maybe you should hire them and put them back in a dark corner, but for the most part you want your IT people to be able to come to meetings with the advocates from the user community. People who can explain technical concepts in terms business users can understand are gems, hire them! Personally I think one of the best things you can do for your programming career is pick up some business knowledge whether through classes or just reading books. You'd be amazed at how much more trust you get from other departments if you can speak their language and understand business enough to suggest alternatives that make more sense for their goals.
Many times I encounter IT departments that are hidden away behind a wall of QA. QA talks to the users then QA talks to the developers. Oftentimes something is lost in the transition. Oftentimes the users see IT as an invisible pod full of trolls who want to make their lives miserable. Getting your IT staff out and visible helps put forth the human side of things.
Previous Topic
