Hi Ryan,

Picked up your Blog after following you on Scobleizer.

As an IT guy I have to admit to being fascinated by the thread too.

I guess communication is definitely the key.

While not being one to blow the IT Trumpet but I think IT often have to deal with the 'Big Picture' - in our small software house everyone knows IT and we make an effort to get to know everyone (we handle everything from inductions to leavers - real cradle to grave stuff). Short of HR we 'touch' more people than anyone else in the company.

As such you need to have some basic standards and procedures in place - if you don't then you end up with high blood pressure and a shortened life span as you run around madly trying to accomodate everyone and not annoy to many people (which you inevitably end up doing any way).

IT's pet peeves would have to be
* new hires no one tells us about
* being expected to 'magic' up equipment for new projects that have no budget
* expecting people to budget and plan their r & d cycle
* we must have (mythical) corporate licenses for everything right ?
* gadget nuts that expect us to configure whatever new toy people bring in
* keeping old hardware/software running because they fired the only people who knew how to build a product and it never got documented or went through a formal hand-over
* old hardware that has no vendor support that suddenly becomes critical to a build process
* seeming to be obstructive when pointing out old hardware shouldn't be re-used for anything critical (see item above)

I just think R & D guys should spend a little more time getting to know the in's and out's of a company beyond their own code to see how they fit into the big-picture.

:-)

Raj.

Raj, I agree. Something I've noticed in big companies is some developers end up with really specific roles, like maintaining one area of the code. They never see the build process or how the servers are maintained so it's hard for them to see the big picture.

I think role decentralization is a healthy thing for a company to do, everyone should know a little of everything plus a lot about a few things (generalist plus local expert). Not only does this help people see the big picture and be sympathetic/understanding of their teammates roles but it also makes them better team players.

Another thing that helps is transparency. Even if a developer isn't actively involved in the build process, if he can read about it on the intranet he's more likely to be sympathic to the difficulty of IT work. It seems like a lot of up-front work to maintain documentation like that but it might be worth it in a large organization. Smaller organizations can maybe just have better verbal communication.

Of course it goes the other way too. If IT is so tight with their policies that it's impossible for people to be creative, then that's bad. Developers have to be able to try out new tools to keep up with the biz. They also have to have enough freedom to think out of the box -- it's that out of the box thinking that sometimes beats the competition. If developers are so tied up by IT that they can't experiment then morale suffers too.

Hi Ryan,

A couple of the ways we're finding of getting around 'being the bottleneck'

* sudo is your friend - esp for those Oracle types that need to keep tweaking things
* vmware is a godsend - people can mess around all they like and share they dev environment with others without damaging anything + its machine independent and you can use the enterprise stuff to host build, test and qa machines for almost any ia32 OS

Raj.