computers should be less friendly

If your IT department is even the smallest bit like mine it may seem that is almost totally impossible to create a place where you can safely try out new technology. In my IT shop though we have carved out a small niche where we have a hand full of folks with a small percentage of their time to really seek out impossible problems and help solve them. At first this seemed like an impossible sell to senior management, however using the following logic we were able to get the time we needed to see if some of any new technology could help our business.

1. Agile Development
• Im totally guessing here, but in most IT shops I assume you probably use some locally bastardized version of the Waterfall method. In our R&D team we use an over simplified version of Scrum, the idea is to remove all the unnecessary artifacts from the process and “Shutup and make it work,” to use one of our teams mantras. The basic idea is get testable code in another team’s hands as frequently as possible; this could mean every night or every week.
• The reason this is number one is that it will allow you ( and/or your team ) to prove value instantly. People go nuts when you deliver the 1st version of working code before other teams have even decided who writes the spec
• Using this type of process automatically distinguishes you from your colleagues, it allows you to move fluidly with the ever changing IT landscape, it is a huge win over your normal process and a big key to my team’s success
2. Flatten your Team
• This may seem like a no brainer but odds are there are lots of people between you and your user community. To be successful at delivering code as fast as you will need to justify your spent time you must be as close as possible to your user base. This means you can’t have a rigid structure the person who knows the most about the area needs to make the decisions. Suck up your pride and let them run the show.
3. Get smart people
• I have a really hard time phrasing this statement but, suffice to say, you have to get the cream of your organization. If you want someone to go decide if Ruby on Rails is a good idea you better trust that person’s ability to learn and their ability to judge technologies. In the end it’s better to have fewer people then an army of people you have to micro-manage.
4. Research is failure
• This is one of the hardest concepts for an IT shop to grasp — they mostly deal with uptime and throughput but when experimenting with new ways of doing things you have to be able to deal with a certain amount of risk and this finally brings me to the reason for this blog, a recent post ( really go read it ) by Carmine Coyote at Slow Leadership, really a great job about the fear that makes these teams fail. Which brings me to my last point
  
5. Fear Nothing
• You can’t be a “disruptive innovator” ( thanks Shai ) without risking something every once in awhile
• Make your management understand that fear is costing them $
• “Thrill your users” ( thanks again Shai ) any fears your management has will go away

Good luck, if IT in the US is to stay we must stop being a commodity and start delivering really measurable value to our businesses again. The simplest way to do this in the enterprise space is to simply make those ugly back end systems usable.

btw — this blog was written somewhere south of Greenland at about 33k feet. On board internet is great.