Improving a small IT organization

Dear Bob …

I’ve only been with my current company for about one year and have tried to influence change around verbal commands.  I have traditionally worked for large organizations (100-500 developers) and now sit in a small organization (5 developers).  OK back to my point ….Verbal Commands.  A typical day in the office starts out with someone in the hall or over the phone requesting something from IT.  I respond back to them asking that they write it up so we have a record, etc., etc., and guess what? I never get anything.  But sometime later my manager says you didn’t deliver this or that and I’m caught in a trap.

Now to my development team. When I do get something in writing instead of wanting to drill further into each item they go start development in the back room.  Ouch I say.  When I walk into the back room there are no design diagrams, no code reviews, no strong architecture leadership, no task assignments, etc.  All I hear from my developers is “well it works like this …,” the old tribal legacy being passed on.

If you can pull something out of the archives that would be great. Or is this new content?  Thanks for listening I feel better. No one here listens.

– Trying to help

Dear Trying …

You aren’t going to like what I have to say about this. You are right about something. At the end of your letter, you say, “no one here listens.” The statement is truer than you realize, because “no one” includes you.

It appears you’re operating under the common perception that a five-person IT department is just like a 500-person division, only smaller. That simply isn’t the case.

When you work in a 5-person department, there are exactly 10 pairs of people. That’s easily managed informally, by just talking with each other. A 500-person department has 124,750 pairs of people. It’s the single most important reason a department this size relies on well-documented processes: It’s impossible for this many people to understand each other well, anticipate how each other will react, and organize their work informally.

Working informally through relationships is far more efficient than working through well-defined processes when the number of people involved is small. Process imposes overhead but it scales better.

You also raised another point which is a hot-button for me: The idea that the documentation should be the primary communications channel. Whether you’re working in a 5-person department or a 5,000 person department, this is one of those consultant-driven ideas that’s ideally suited to covering IT’s backside, but poorly suited to getting useful work done. When someone shows up at your cubicle with a request, have a conversation. Interacting with someone face-to-face, where you can both sketch ideas on a whiteboard or piece of paper while seeing each others’ expressions and body language, is a far more efficient way to communicate than in written documents.

Once you’ve finished the conversation, you can document it so you have something to remind you of what you agreed to in the conversation.

I certainly agree with you that design should precede coding. It’s an important improvement, which you should introduce to your colleagues. If you want to succeed at this, the first step is to become one of their colleagues. Very few ideas have ever been successfully introduced to any organization by an outsider.

So your first step is to adapt yourself to the organization as it is. I suspect that once you do so, you’ll never want to go back to big IT, because small IT is usually a lot more enjoyable and rewarding. Once you’re part of the team, you’ll be in a position to suggest some better ways of operating.

Assuming, that is, that you still think they’re better.

– Bob