What Should I Refuse?
May 28, 2009
I know that may sound strange; after all should IT providers refuse anything?
Should they say No?
If yes, what should be refused?
And yes, I ask that question of myself –
I don’t ask it in the; to improve this can we ….? sense of the term.
I ask it in avoiding exceptions as much as possible.
Exceptions create complexity, and eventually, that complexity will kill your IT infrastructure.
As an example, At my organization, at sometime in the past all corporate departments had been given complete access to the software development teams computer file storage work areas.
The amount of data ‘accidentally’ deleted … ouch, well, you can just imagine.
Then someone had to tried to partially fix it by creating security permissions on individual files and folders. Which made a complete bowl of spaghetti mess – uggh – still I shudder.
What I did was implement a sandbox, (in tech terms, a staging area) – testing or review of this stuff by others who are outside of the software development team?
Use the sandbox!
So when someone asks me to give access to another person to that private software development area again?
Should I refuse?
I do! – I say use the sandbox.
And yes, there is often a but, but we need… Yes I know, but the extra minute or two doing it cleanly up front will save hours of headaches later.
I must caution you though – as a general manager in the SMB space, your IT provider should not be refusing to allow those non development staff to do what they need to do. And that is not what I did.
What I did was set it up so that no matter what accidents those non-technical staff could do, it would not be truly painful for the development team.
There is a huge difference between a random ‘no’ that harms business outcomes or productivity, versus a ‘no’ for something that is being used as a shortcut, or without looking at the longer term consequences.
You can get updates to this blog by clicking the RSS icon on the Home Page!