Broken teams can’t react quickly.

As I jump between different organizations on consulting engagements I find lots of different dynamics which effect how well employees are able to perform their various functions. It is certainly an educational experience and over the years I’ve started to identify some common forces which leads individuals to become ineffective.

I blogged recently about our internal DevCentre but in reality that is probably an unusual scenario that isn’t repeated often in other organizations but I wanted to explore the impact of something as simple as the political forces between teams can have of productivity, and therefore costs.

Recently I came across a situation in one company where the development team was being hampered because they couldn’t set up a piece of critical infrastructure in a timely fashion.

The infrastructure component really needed to be managed by the development team because the infrastructure teams within the organizations didn’t have the skills to do it themselves and probably wouldn’t have been able to respond to configuration change requests in a timely enough fashion – and when they were executed, it would need to be a developer that did it anyway because of the nature of the beast.

Unfortunately for the organization in question this simple requirement causes a fair bit of consternation simply because it isn’t normal practice from an IT management point of view to give users the keys to the kingdom.

But what is this about “users”? Well if you are a developer reading this blog then you will doubtless know that there is a massive divide in IT between the “systems guys” and the “code guys”. To over simplify the reasoning the “systems guys” are responsible for making sure that the environment is stable and generally available for all standard business users and the “code guys” are responsible for creating new stuff and changing existing stuff – two goals that are seemingly at odds with each other.

This creates a natural political division that has been reinforced in most organizations by having two branches of IT management, one for projects (often software development related, but not always) and another for operations.

I’m not sure what the solution to this gridlock is but I suspect that developers need to start being realized as “non-users” in the say way that the “systems guys” are and given a level of access and systems management responsibility that a user wouldn’t normally get.

I’m not suggesting that developers should have administrative rights across the domain (although I have seen this work to varying degrees of success depending on the quality of team members), but they do need to be given the management responsibility for the servers that they use day to day, even to the point where they should be able to put on a custom server build if they want to.

In the scenario that I am thinking of this would allow the development team to provision a system that was instantly more useful to them and allow a very costly resource to be more productive. The fix for the broken team is realize developers and systems guys are fighting for the same cause and ultimately developers share some of the operational skills that system administrators have.