Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Corporate IT is an Innovation Barrier

April 17th, 2008 · 6 Comments

A few days ago I overheard someone talking about outsourcing. At one point, they said “it’s hard to outsource innovation.” I couldn’t help snickering at this – it’s probably just as hard to insource innovation. In fact, it may be harder.

Corporate IT is, by its very nature, a barrier to innovation. This is true at many levels, starting with your management chain. How many layers of buy-in are required to try something new? What if you actually have to buy something to try it? Hierarchical organizations make innovation harder because they impose a decision-making layer of bureaucracy upon the innovators.

Most large organizations are hierarchical, with varying degrees of bureaucracy, but Corporate IT takes it several steps further than just the natural problems of a large organization. We’ve created special processes designed to resist innovation and change. I’m talking about the project management “best practices” (yes, I mean this sarcastically) of change management, upfront requirements, and “contracts” between business and IT.

How many times have you heard an IT manager try to tell the business something like the following: “Don’t tell us how to do it. Just tell us what you want done and we’ll figure out how to do it”? This is a typical response to our business partners doing their best to explain a problem and a potential solution.

Sure, sometimes the business tells us to solve problems in crazy ways that might ultimately be harmful to the organization. I’ve seen that first hand on multiple occasions. But I think there is a better way to avoid the negative outcome of crappy software than telling the business to stay out of IT.

One of the things that often happens when IT managers send this message to business partners is a counter-productive power struggle. Managers on both sides start this escalation process through their reporting chain until they either merge or one of them has to back down because of the eminence to the other. Guess who almost always has to back down? IT.

I think this problem would go away if IT managers would stop seeing business “design” as a bad thing. I prefer to think of it as an attempt of our business partners to move away from the legalistic relationship that plagues IT and collaborate with us. It doesn’t necessarily mean we design it the way they suggest, but it does mean we let them play. Anyone who can contribute should be allowed to. Designs express intent, and often that intent is more important than the requirements the business might write down and throw over the wall. By letting them play in design activities with us, we understand their intent better and are more likely to create a solution that solves the problem we are focused on. In the process, we help the business to have confidence in our skills as technology problem solvers.

When the business is confident in you, innovation becomes easier. They will take risks on you – spend money on the possibility of a big win, and together you will fail or succeed. When the business believes in you, your management will tend to get out of the way, whether they believe in you or not. Everyone in IT knows where the bread is buttered, and it’s not on the IT reporting chain.

Collaboration is the key to innovation. The best collaboration happens when you set aside the restrictions organizations create around roles and let people play. Here are some rules I’ve come up with over the years that I think encourage collaboration and innovation:

  • Be title-blind contributors
  • Anyone who can contribute is allowed to
  • Know the difference between different and better
  • Have thick skin, shed no tears, and bear no grudges
  • If you enjoyed this post, make sure you subscribe to my RSS feed!
    Stumble it!

    Tags: Project Management

    6 responses so far ↓

    • 1 Tom Clarkson // Apr 18, 2008 at 3:07 am

      Once IT gets involved the legalistic relationship is more or less inevitable. As well as often having to deal with multiple groups of stakeholders, IT can’t provide the definite price the business wants without knowing what needs doing up front.

      However, I think we are getting closer to the point where a lot of projects can avoid these problems by leaving IT out of the process altogether through technical solutions that allow users to create their own systems. We’re not quite there yet, but I can see this approach working well for some types of project.

      My last project involved fixing up a power user created SharePoint site. This site contained some of the worst code I have ever seen, but the project went well for both developer and user. Development was a matter of replacing bad code with good code, with no understanding of the business required. With a (partially) working system in place already the users’ expectation of the new system wer far clearer than is possble with documents. And with a platform that supports both ugly hacks and professional development there was no platform change and the users could see the improvements without waiting for the existing functionality to be reproduced.

    • 2 David Christiansen // Apr 18, 2008 at 7:58 am

      I think any project that can materialize the user expectations early on is much more likely to succeed than one that postpones this until the very end, as is the case in document-centric projects. When you rely on documents, interpretations are always wrong to some degree and users are inevitably disappointed.

      Something I always do to avoid this problem is build the UI right away, even before there are requirements. It’s usually just a hack mock-up, but it shows the user what they will get. We typically start the mock-ups after a one hour interview with the business, then we adjust it every day (with them and some representative users) until it is right. That usually takes a week.

      This is a much more productive (and exciting) way to start a project than your typical analysis/requirements baloney. I find it ironic that more IT PM’s don’t use this type of approach, because they are trained so heavily in risk management and this dramatically reduces the overall risk of the project.

    • 3 freak3dot // Apr 21, 2008 at 10:10 am

      A thought that has crossed my mind more than once lately is that business should be run by IT. IT has the know how to make the system make the processes require as little human intervention as possible. IT has the know how to make the system user friendly.

      At least in my corporation, the business wants everything yesterday and doesn’t care how bad it is as long as the happy path works. I can’t stand this mentality. IT has created itself such a support nightmare with this going on for years.

      I think what got me started on this path is your blog “You Weren’t Meant to Have a Boss.” This is interesting because it is true that the groups do not communicate cross-department well at all.

      Now of course I don’t mean the IT should literally run the business. I just mean that the processes should be as automated and user friendly as possible so that fewer people in the organization puts IT closer to the business.

      Empowering the users with tools to create their own software sounds like an exercise in bloatware. Just look at a WSIWYG HTML editor. It puts in way too much unneeded code.


    • 4 Lucy // Apr 23, 2008 at 7:54 am

      Really….Corporate IT is innovation barrier nicely explained….

    • 5 Michael Bolton // Apr 30, 2008 at 3:53 pm

      David, you might like to have a look at “Creating a Culture of Innovation”, by Mark Federman. See

      Freak3dot, your post deeply confuses me. I can’t quite reconcile the notions “user friendly”, “little human intervention”, and “IT has created itself a support nightmare”. And when you say that HTML editors put in “too much unneeded code”, too much for whom? Is this a possible cost of doing things in a user-friendly way? You might like to read “The Social Life of Information” and think about some of the issues raised there.

    • 6 freak3dot // May 16, 2008 at 1:42 pm


      By “user friendly” I generally mean that the system should do what the user expects. It should also have as few steps in the process to get to an end as possible. It should just plain be intuitive.

      By “little human intervention”, I mean that if there is a process that can be automated it should. For example, one error I saw on a system said something like please correct date to mm/dd/yyyy format. If I entered the date in mm-dd-yyyy format, it should be able to convert it automatically (although it might tell me that it did correct it if the system is something where I would want to verify changes).

      I think the “support nightmare” comment is mostly a problem in my company. A lot of issues have to be resolved by IT because it is not automated or just plain left out of the system.

      I like to write my code with a text editor and make my code a lean as possible. Some people still use dial up and even on high speed it is nice to have a very responsive system. So to answer your question, too much for me.

      I will definately want to read “The Social Life of Information.”


    Leave a Comment