So the past few of my posts has been on development going faster due to help from the management perspective. Things like management removing impediments and not feeling high on themselves but instead taking the opinion and perception of the people they are helping as an indicator of the success or failure of their efforts. While I was writing that, my friend raganwald has asked us to stop blaming management. Now while I agree with that statement on the surface it goes a little deeper then I think his article implies.
So for a very long time programmers at the low to mid level have blamed architects and management for their problems. In some cases they even blame the business for their issues. What I have said in the past is that in order to address this blame game you first perceive that management is helping them. Step 2 is to make sure that you have your house in order. Step 3 is that the people running the environment you work in have to 'want' to help as well. Hence the remaining bulk of this post.
IT departments (from the top down) are more often then not run in a "command and control" fashion. What this means is that IT departments are often attempting to find ways to restrict what users can do, keep them from shooting themselves in the foot, make things as homogenious as possible in the name of making sure that they can support anyone and everyone in the company. THIS command and control idea is a fallacy and here is why I think so.
I believe very strongly that IT departments should be about enabling users to get things done. I believe that they should be more then willing to provide solutions that fit their needs, and when presented with something that doesn't fit the mold they have laid out precisely still be willing to accept things that make their end users go faster and get more work done. I believe they should be TECHNOLOGY ENABLERS not disablers, controllers, commanders.
Now what I am NOT saying is that IT should just willy nilly allow anything suggested, but rather they should work with people asking for 'different' things then what is currently being offered to understand what the need is and then move to fill that need. I mean that they [IT] should pro actively add features and functionality to provide users with choices. The down fall of NOT being this flexible is that users will want to work around the controls placed upon them. Human nature is to try and break free and do things perceived to be needed. The stronger the grip the more people rebel against it and the more things will slip through the grip.
So - which way does your IT department think? Are they enablers for their users, or are they command and control? I strongly think they should be the enablers - if for no other reason then not having to fire people working around their command and control systems.
Subscribe to:
Post Comments (Atom)
6 comments:
There's a lot of talk on the 'tubes about designing software to be flexible, either by designing it as a tool, or just through smart OO. This piece comes to mind:
"Many times what has happened is a company started out with a great idea and some knowledge of the domain. They built a piece of software that is a very literal embodiment of their view of the domain. So long as the whole domain and all the customers fit their view, life is good. However, for most non-trivial (i.e. interesting market size) domains, nobody knows the whole domain. You learn as you go. Customers throw curve balls. If the only way to adapt to that is to either keep adding tons of features to the software, or do expensive custom work on each deal, that’s way too much friction to scale. A domain specific language makes it possible to maneuver a bit at low cost and give customers what they want."
I think maybe what happens is that IT doesn't or isn't able to build a system this way early on, so their systems don't accommodate new needs easily. Thus becoming command-and-control like you describe is probably a defense strategy to keep down the number of changes they have to make.
OK - so I agree in part with what you are saying, large IT organizations have a lot to deal with and command and control is certainly a way to keep it from spiraling out and becoming unwieldy. The counter is that it should certainly be possible to have a team of folk that is fairly well versed setup a 'light touch' infrastructure such that they are capable of 'incorporating' new things and ideas/tools without making the whole thing be fragile. In some cases this might even stem from the IT group not having good monitoring or other infrastructure to meet the needs (this is a gross generalization, but in some cases of growth companies can certainly be true).
I think all too often command and control becomes a defense mechanism and all it does is make user LOATH having to deal with IT to get anything done. Whatever happened to good ol' fashion team work for the betterment of the company? Maybe I am being too idealistic, but when something as simple as getting a new tool into the system because you need it for your team to do their job takes over 7 months and still has not happened... there are too many roadblocks.
Oh yes, agreed there. What I'm getting at is that the source of the problem is likely to be that the system was not designed well to begin with, and is now far more difficult to adapt than it should have to be; so IT goes into evasive mode to prevent becoming overloaded with work they can't finish. Unfortunately, I don't see an easy way out of this.
So the fundamentals were not resilient. I agree - and I also don't see an easy path out... but IT digging in their heels certainly doesn't help. 8-)
It's not that I think what is out there is working; I don't. But I also don't think more individuality in the process will help either. There is so much work that goes into software, it is expense, hard to produce and easily subject to numerous instabilities. From a company's perspective, the best they can hope for would be the ability to fully leverage any of the work going into development. This works best if you can convince the several species of small furry animals to get together in a big cave and groove with a pict (inspired by a Pink Floyd song title). If everyone is working towards the same goal, it tends to happen faster. Somebody has to set that goal, and assume the responsibly for it.
Paul.
I think that there is another post in that comment alone. 8-)
I agree with you on the base level though - what is out there isn't working, but adding individuality is not going to help.
Yes it does work better if we are all moving in the same direction, granted. Its certainly hard to attempt to herd the cats into line. I am not attempting to foster 'more' individuality, but what I am saying is that you should always use the right tool for the right job - and have a policy that says you will attempt to use those right tools OR find an equivalent that is not less than the functionality that you were attempting to get to.
Like I have said in the past there is no one tool for all jobs so you should try to organize around grouping functionality and addressing needs rather then keeping people from what they perceive they need. It should be possible to do this without letting it get all willy nilly AND you shouldn't have to resort to a flat out NO unless the users are asking for access to their favorite pr0n site, just because. 8-)
Post a Comment