Does Enterprise 2.0 actually mean a bigger IT Department?
by Jevon MacDonald
Initially it seemed like Enterprise 2.0 packages would unseat IT Departments. I have been a big proponent of the “dump your IT” school of thinking. IT gets in the way, they are cranky and always turning up their nose… right?
My mind was changed just a little bit a while ago when working with a client. Part of my work was to go in and have a look-see at the IT Department. Who are the bottlenecks? Who are the innovative and curious personalities?
This usually doesn’t end well, but it did this time.
You see, IT Departments can, in the right environment, be like little startups. Creative hubs of people who really do things and don’t just produce vendor requirement documents all day.
There are then, as I see it, two ways your IT department could fair out in this whole thing:
- They disappear. SaaS is so prevalent that all of your support and delivery is taken care of by a cadre of google’esque SaaS vendors
- Your IT Department grows by at least 100% from it’s current size, but your software costs are reduced by at least 60%
Let’s think about option number 2, because it is new to me.
Why expand your IT Department?
With the growth in Open Source solutions, and the ability to rapidly develop SaaS-style applications with frameworks, internal development or deployment of services can be increasingly attractive. Agile methods can also allow for just-in-time delivery of solutions as their need emerges, rather than being at the mercy of a vendor who may or may not be able to fit you in to their development cycle.
Reduced software licensing costs and the ability to manage most support internally through a properly configured development group will both contribute to funding this growth significantly.
In order to create an IT Department with these capabilities, you will need to change a lot about how you hire.
Hire for delivery, not manageability.
1 amazing developer can produce an inordinate amount of delivery-ready application as opposed to 10 easily manageable developers. Hire people who have done things on their own. Full-cycle development experience, self-motivated and creative personalities are all things you need.
Less managers, more developers
You need to promote your best developers into hybrid management/development positions. Let them work with other management on developing ideas and assessing needs, but expect them to get down and start coding along with everyone else when it is time to deliver.
You will also need to plant the seeds of some cultural shifts. To do this you may need to fire some individuals, and you may need to promote some others. Be open to this and ready to execute on your plan.
A sandbox culture
Managers, CxOs and others need to be introduced to the idea of working directly with IT in small iterations to deliver solutions that fit their needs. IT needs the ability to connect with individuals across departments and utilize them to inform software/service development. In an ideal world, this would not be a process, but a cultural quirk.
Tuesday morning meeting about a new system idea? Get IT in there, they’ll have a prototype by Friday.
Love of failure
Not all of these ideas and experiments will work, but each failure will inform a larger goal of establishing a rapid-development capability for your organization. Failures also become far less costly. Having an unsuccessful 2-week project to develop a customized CRM system is far less costly than having that Oracle project go bad.
New Vendor Relationships
Now that you have the competency to design, develop and experiment internally, your vendor relationships, and the type of vendors you deal with, will change dramatically. You will be most compatible with vendors who embrace standards, who are tightly focused on a few core competencies and who have equally creative and open cultures.
