8/9/05

Work was interesting today. At least it was to me, but probably not to you. I received some praise from another development group that we have teamed up with on one project. My boss was present at the meeting to hear it and commented to me about it later. He talked about how it’s that kind of recognition we need to break down some of the barriers and misconceptions about our team. I wouldn’t be surprised if other IT departments in other companies encounter this same scenario, but who knows? Maybe they know how to prevent it better. Well-intentioned IT management encourages and facilitates the review of many similar products to choose the one best fit for a particular project and within the current systems infrastructure. Well, at least that’s the intent. The problem is that quite often those that are doing the evaluation have no idea what they’re looking at or looking for to begin with. But I won’t get into that now.

What I’m talking about is the situation in our department where we have programming teams using different tools working in isolation. Both sets of tools have their strengths and weaknesses. Wait, what weaknesses? We don’t have any weaknesses! Bring your work to us! That’s what I’m talking about. These teams get so caught up in their evangelism for their chosen tools that they forget to work together. When they do work together it’s at an arm’s length so no one’s fingers are allowed to get dirty and really understand the environment they are touching. Technically they shouldn’t have to, but if no one knows what’s really goes on on the other side, then how do we know what we are doing? There are other reasons they use to not get familiar with the other side too: a) “it’s not in my job description,” or b) “I have enough remember to do my own job without learning someone else’s,” or c) “I don’t want to learn something that my superior product will just replace at the first opportunity.”

I have been lucky enough to be part of a project with someone else who isn’t afraid to get his hands dirty and learn a little about what we do. When we both put our heads together and take the time to learn what each side can do, we can build a better product for the end users.

It’s kind of funny.