10 Simple Rules for Success in the IT Department

In 2003, I put together a brand new team to build the infrastructure for a brand new medical school in Northern Ontario.

It was a heady, exciting time.  We were in a full tilt run creative mode for two years.

There wasn't any time for the extraneous.

No time for things that waste time like creating long policy manuals that nobody read.

No time to be derailed by silly things that would detract from our mission.

So I came up with a list of 10 Simple Rules that covered most every situation I've ever encountered in IT.

Interested?

Read on...


I have modified this list slightly over the years, but the core essence hasn't changed.  Each of them were used as a discussion topic for team meetings, so we could define as a group what the principle really looked like in action.

Feel free to use them, but be warned.   If you don't really believe that these are true, then your team will pick up on it faster than immediately.

Here they are:


Kevin’s Ten Simple Rules for Success in the IT Department

Rule 1: Production is job number one.

If technology (or lack thereof ) is preventing people from teaching/learning/working… then we will do what it takes to get them productive again.  If there is a reasonable workaround, we will be expedient, but not necessarily immediate.

Rule 2: Go ahead… Backup.

Protect the data. Backups are sacred.  Privacy is important. The technology unit should be leading by example.

Rule 3: There is one technology unit. 

There is no Operations/Development split.  We are in this together and are all responsible for the success of the unit.  We share the gain, share the pain, and share the glory.

Rule 4: The CIO can be wrong.

If anything the CIO asks detracts from Rule #1, Rule #2, or Rule #3 then he is wrong. Tell him so.  (This is not a CLM (Career Limiting Move).  Note… this goes for the rest of you too.

Rule 5: We are a team of professionals.

Our constituents (faculty, students, and staff) are the reason we are here.  At times, people can be frustrated and demanding, but that is no reason to respond in a like manner.  The technical team will always respond in a professional manner, and then find a safe way to vent. There is NEVER any excuse for less than professional behaviour.  (This is a CLM)

Rule 6: Always have a Plan B.  (Murphy was an optimist).

Things will go wrong.  People will be absent.  Avoid with all your might situations where there is a single point of failure whether it is a piece of equipment or a person.

Rule 7: Never say no to a user – just put a price tag on yes.

It’s not our job to determine what people need to do their job.  We do not win points by being negative, no matter how obscure the request may seem.  It’s our responsibility to provide a realistic assessment of when/how much.

Rule 8: If you don’t document it, it didn’t happen.

Create a ticket for everything you do. Document your development projects.  We can learn from our mistakes, and effectively plan for the future.  It also provides a way to integrate new people if you win the big lottery and move to Mexico.

Rule 9: Your version of “intuitive” might be different.

Technical people are unique.  We like to fiddle and tweak and are not typically bothered by complex convolutions to make technology work.  Our typical constituent on the other hand, would likely prefer everything to happen with the push of one button – automatically.  

Rule 10: Don’t let the best be the enemy of the better.

Avoid analysis paralysis.  Decide what is needed and move forward.  Be confident in your decision. If you base your systems on standards and design for expansion, you can add new technology later.  Get value out of technology now, but ensure that it’s flexible, extensible, and secure.