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.


7 thoughts on “Broken teams can’t react quickly.

  1. Neale NOON

    The larger the organisation the bigger the divide! When our team was small we built the boxes, now we have to fit in with another group who now has this responsibility.

    We have recently commenced using virtual environments for development and I’ve almost convinced the infrastructure guys that they can safely let the developers manage one of those VMs. How much damage can we do if they can undo the damage just by copying a vhd?

  2. Pingback: PaulStovell.NET » Deployment with Virtual Machines

  3. Paul W

    As a ‘system guy’, I am find your opinion to be very short sighted. While dev guys, need access to dev and test their products, they do not need access to production systems. Sure you can have a good system guy ths is also a developer but it is my experience that many dev guys now little about the underlying systems on which they develop. As well, with the rapid change of technology, many do not completely understand their dev platforms before they are off trying to master a new one.

    As a system guy, developers work on single web applications but systems guys are responsbile for 10’s/100’s on the same site. If the dev guy does not the inter action between their applications and other applications — we can have a system failure and who will get blamed? The system guy.

    Dev guys never admit to any mistakes, because of their God complex.
    Systems guys usually admit their mistakes because they understand technology.

  4. Mitch Denny Post author

    Hi Paul,

    I guess the point that I am making is that developer != standard user (if there is such a thing anymore). Ultimately developers will do what they have to do to do their jobs, their job is to create and ship software. They will put up with artificial barriers for a while in the interests of “team spirit”, but their #1 motivator is shipping that code.

    So whilst all the arguments about why developers shouldn’t touch production systems are actually irrelevant, because if they need to (in their eyes) to get the job done – they will.

  5. Pingback: Ken Schaefer : Broken teams can't react quickly - what can we do?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s