10 Rules Enterprise Technology Groups Need to Start Living By

Over the past ~15 years or so I’ve had the opportunity to engage with enterprise technology groups in one form or another whether it be designing solutions with them, consulting for them, selling to them and now, actually working within one.

As a result I’ve had a front seat as they’ve been dragged into a new world where they’re no longer the place where employees are amazed at the cutting-edge technologies they get to work with at the office, but instead a place where just keeping up with the latest technologies has become a massive challenge (Hands up if you work at a big corp and you’re still on Win XP, Office 2003 & IE6).

Compounding the problem is the accelerating pace of technology evolution – not just for the applications and hardware already in the organization, but the growing number of applications and devices they’re expected to support. 25-30 years ago it was a putting a computer on every desk, today I personally have a corporate desktop, laptop (2 actually), blackberry and iPad. Then you’ve got the applications, the intranet and all the servers to run everything. What it boils down to is 100’s of thousands of moving parts that they’re responsible for and that number is only increasing (oh, and did we mention your budget has been cut back?).

So with that context I do think there’s some areas where technology groups could make their lives easier. Most, if not all, of the following rules really only require a mindset shift to implement (easier said than done, I know)

The Rules

  1. Processes should provide guidance & governance – not power.
    When implemented properly, processes are great – they keep things in order, help ensure standards are adhered to and generally help keep things running smoothly. Where processes go wrong is when the people responsible for managing them begin to believe that they have power because of them. At the end of the day the primary goal of any process is to ensure the real needs  of the end-user is being met in a reliable, proven way.
  2. If there is a process you expect people to follow it must be clear, documented and accessible to them.
    If you’re going to force someone through a process, you better be damn sure you can tell them what it is, what you expect and how you will deliver.  It’s not a process if you kinda-sorta do it ‘this way’ most of the time.
  3. ‘No’ or ‘we can’t’ are not solutions. If you want to own responsibility for an area then you also own the responsibility to provide solutions for it.
    If you can’t do it own up to it & help them find someone who can (You’ll look better for doing it) – people aren’t asking you “if” they can do something, they’re asking how. You either need to find them a solution or have a very good reason, that you can explain to them, for not being able to deliver.
  4. Just become something can do it, it doesn’t mean it should.
    SharePoint anyone? Don’t get caught up in the buzzwords and basic functionality. Find out what the real needs of the user are and ensure the solutions  you present deliver on them. SharePoint is a great example of this. It does EVERYTHING, but does very few things well. If you compare SharePoint’s ‘Blogging’ capability to just about any other current solution it just doesn’t compare – yet many companies get SharePoint and then declare it the standard for anything it can supposedly do.
  5. One size does not fit all
    It’s very easy to look at a device, maybe even test it out with a few users and then say “This isn’t the right device for our organization” ot “this is the standard device we’re all going to use – but the reality is one size rarely fits all.  While I appreciate standards make sense from an administration & management perspective but we also need to step back and consider the use case for a given technology, in fact that’s where we need to start. It’s fine to consider the ‘standard’ device before looking at others but at the end of the day it’s our responsibility to find a solution that truly solves the need.
  6. Security must be practical, not theater
    If it’s new, you can pretty much count on security having an issue or two with it. The challenge for/with security is everything lives in the “What If …?” realm. It’s a really hard to debate the likelihood of a given scenario when it’s entirely hypothetical. Security is hugely important, but the risk it runs is of stifling the advancement of the organization in general out of fear of the unknown. Reflection of how realistic or practical the concern is, is an important step to keeping things moving. This is going to be increasingly important as more and more data & applications move to the ‘Cloud’ – something that gives Security conniptions but is an eventual evolution.
  7. Communicate. Communicate. Communicate.
    It’s very easy to get hidden and siloed off by a process and organizational structure. There’s forms, tracking systems and dedicated points of contact that all serve to get between the technologists and the users. What it creates is this horrible game of ‘telephone’ where messages & intentions become confused. The best thing we can do for any project is get everyone in the same room, early & often and keep the lines of communication open at all times.
  8. Agility, not size or market share, is what will make this era’s businesses successful.
    It’s great to be big, until the market shifts underneath you. Agility is what is going to decide which companies remain competitive in the near future. If I were at the helm of an Enterprise IT group today I’d be pouring a tonne of effort into making my organization as nimble as possible. This is going to be come increasingly important in companies who deal directly with their end customers (ie service organizations) as your customer bases are living in a rapidly available world and don’t care why you don’t have a given service or technology, only that your competitor does.
  9. Don’t be afraid to acknowledge mistakes. If the solution doesn’t work be prepared to dump it and try something else.
    Unfortunately with projects at the scale of some Enterprise IT projects it’s really, really hard to let them go. Once a technology is in place it’s rare that it’s getting dislodged regardless of how loathed it is by the users. Don’t be afraid to re-evalute tools and decide to dump them if they’re not meeting expectations. And whatever you do, don’t get locked into the mindless upgrade path – any major version release is a good time to question whether you’re still on the right tool for the job.
  10. Change your mindset from Monopoly to competition.
    For many years, enterprise has had a lock on the ‘business’ of technology in their organization – it you wanted something you had to go through IT but that’s changing. So many business applications are available on the web today, and all it takes is a corporate credit card to sign up. For each project ask yourself  ‘would the business have decided to use us if someone else was bidding against us’.

All that said, this isn’t an attack on IT or technology groups, what it hopefully serves as is another voice contributing to a call for change in how we work together.

Enterprise technology groups have a massive challenge ahead of them as they try and pivot into agile organizations that can keep up with today’s technology.

What we need is to step back and look at how we can work together better – I hope these ‘rules’ can help provide a foundation for that shift.

Did I miss any? What rules would you add to this list? Let me know i the comments below.