Having spend the last 4 years or so working in web agencies, I’ve seen the inner workings of the IT department in many, many companies – from mom and pop operations to Fortune 500 outfits. More often than not, the IT department is really, really broken.

First, let’s have a look at what broken means:

Symptoms

Lack of Prioritization

Faced with conflicting demands from different business units, the IT group is unable to plan where to spend its energy, and so lives constantly in a reactive state, servicing whatever the squeakiest wheel happens to be at any given moment. Essentially it’s locked into a state of putting out fires, and is unable to put energy into actually making things better.

Often this can be a result of lack of “informed power” regarding the IT department: senior management doesn’t really have the understanding to view IT as an allocatable asset, and no one in IT has the power to push back on the immediacy of the next business stakeholder’s fire – regardless of whether it’s important to the business or not.

Lack of Bandwidth

Related to the prioritization issue, but slightly different, is the fact that most IT organizations simply don’t have enough people to do the volume of IT work demanded by the organization. At the same time, however, there is resistance to hiring in IT, because IT is viewed as a pure cost center in most organizations. In other words, it is not viewed as a vehicle through which the organization can make money, but rather just a place where spending occurs. In an environment of cutbacks, it will be trimmed.

Communication Problems

Often business stakeholders and IT just can’t understand what the hell each other is saying. Business users generally have a sense that certain features are vastly more important than others, but don’t always communicate this prioritization if they’re not asked. Additionally they may jump immediately to a specific feature implementation (that may be taken as a requirement by IT) that isn’t really what is best for them. Business stakeholders are not going to have any sense of feasibility, however: they don’t know how hard it’s going to be to do things.

IT comes from the opposite end. They understand feasibility, but not business importance. Unfortunately IT has the habit of taking all “requirements” from business as of equal importance, and just plugging away, looking at things purely from a feasibility perspective. When combined with the business stakeholder’s habit of proscribing features instead of just stating needs, it can lead to a lot of wasted effort.

Fortress Mentality

When things go wrong with technology, who get’s blamed? IT. When things go right, who get’s credit? No one.

In a sane business decision, one weighs the upside against the risk. There are many cases where it’s worth it to take a risk in order to achieve a big payoff. But IT is essentially balancing risk against an upside of zero. Naturally, that means they will seek risk avoidance in every case. This minimizes the chances of things going wrong, but it also minimizes benefits that might be had from technology.

Consequences

These symptoms turn an organization’s interactions with their own IT group into a big, dysfunctional dance. Business stakeholders feel that IT is unresponsive, slow to complete projects, incomprehensible and too restrictive. They start to come to the blanket judgment that IT is not going to be a solution for their problems.

IT for their part, feels under-appreciated, constantly putting out fires, under-staffed and forever dealing with clueless users. They have ideas for how to make things better, but never have time to implement them. On the projects that they do get to work on, they’re shocked to find out that features they’ve worked so hard to implement are being unused by business stakeholders.

This dysfunction has even led to a culture of circumventing IT. Business stakeholders (as much as they might like to) realize that they simply cannot live without having certain technology services performed, but feel that IT will be unable to help them. At this point they may look for outside help – either from product vendors that claim to “do it all”, to agencies that usually make the same claim.

The product vendors or agencies may be just fine, but that doesn’t change the fact that the organization has chosen to outsource a part of its business, not on the basis that it isn’t core to their enterprise, but rather on the basis that they are incompetent to execute. Since IT work is often the automation of a core business process, outsourcing it can lead to a weaker overall organization.

So there’s a picture that’s probably familiar to many. How do we fix it though?

How to Fix IT

Fix the Accounting

If technology has benefit to an organization, then that benefit needs to be reflected in the way the organization accounts for itself. From a financial perspective, a business will look at the profitability of its various components (at various levels of formality, depending on the size of the business) and make decisions about where to invest.

Businesses need to stop looking at IT as pure cost centers. That means that the credit for adding value to business units needs to find it’s way back to IT somehow, and be measured against IT costs. Here’s two possible ways to do that:

Charge the Business Users

If business stakeholders use IT services, they have to pay for them. That way the “cost of IT” lands squarely on the business stakeholders that use IT services. Of course, the side effect of this is that the quality of what the business users are paying for will immediately fall under scrutiny, but that’s okay. The point is to make the organization stronger.

Credit IT with Results

Let’s say IT builds a system for a business group, and as a result there is a reduction of cost for that business group (or even better, a measurable increase in revenue). Some of that savings/earnings increase should again be credited back to the IT department, and shown as income (or something equivalent). Again the political side of this action will be determining how much credit to kick back to IT. Too much would additionally have the negative side effect of making the business groups less interested in such activities, as they aren’t being credited with the results.

Hire Technology Leadership

Particularly aimed at the communication / prioritization issues, the solution is to hire a senior person with a technology background who:

Can Translate: Someone who can speak the feasibility-heavy language of developers, and the priority-heavy language of business stakeholders. Someone who knows when to ask context-breaking questions, such as identifying the real business issues instead of just accepting prematurely prescribed solutions dictated by business stakeholders.

Can Design Solutions: Someone who can take the real business requirements and come up with a technology-based solution, then take that solution and articulate it as technical requirements for the IT Staff. This is an individual who understands both technology and business.

Has Authority: This person needs to be able to push back. It is inevitable that forces within the organization will attempt to mis-use IT, either pre-selecting the wrong solution, or by short-circuiting the priorities of the IT group. The Tech Lead has to be able to say no to those forces, and find a real solution that balances the real needs of the business stakeholders within the larger context of the organization.

Decompose IT

The most radical step is to send IT staff out into the wilds of business stakeholders. Instead of a common pool of IT resources, an organization could choose to send, for example, a technical PM, a couple of developers and a sysadmin out to exclusively work on the problems of a particular business group.

This is an approach that probably makes the most sense when the needs of a business group grow beyond a certain point. At that point using centralized IT resources becomes less effective than maintaining their own technical staff. The obvious concern is that efficiencies of scale are lost when technical resources are distributed amongst business groups, but this is a good choice when the effectiveness of those resources within the individual business groups makes up for any loss from decentralization.

The upside to decentralization is that the accounting problems just go away. The efforts and results of these distributed staff are just measured within the individual business group, who will either be able to justify the expense or not, on the same kind of merits that they use for everything else.

It is important in these cases that technology leadership/management is included in the distribution, or the business units can find themselves saddled with a lot of the communication issues mentioned above. Because of this, this is a significant and potentially expensive step for a business group.

Conclusion

IT in most organizations is broken – it’s not providing the kind of support and advantages to business users that it could, and is the source of frustration and feelings of helplessness for many employees, both business and tech. By re-structuring the way IT fits into organizations, it can deliver on it promise at last.

Jerry: Oh… You mean… shrinkage.

George: Yes. Significant shrinkage!

So how do you enter a mature, well understood market?  The naive answer is: “well if we can just get 3% of this multi-billion dollar market then we’ll be doing okay”.  In practice, that doesn’t work – the market will eat you.  The rules of an established market are always stacked against newcomers, and in favor of the incumbents.

Well, how about destroying the market?  Shrinking it until the market leaders die?

Sounds harsh.  But this can be one of the more effective tools for a start-up trying to break in.  Instead of trying to carve out a space by following the existing rules of the marketplace, the start-up just lets all the air out of the balloon.  The incumbent giants asphyxiate from lack of oxygen (meaning money) and the startup is the only one left standing.  (Did I get enough imagery in there?)

Classic example: Craigslist.  Apparently there once was this profitable part of the newspaper business called “classifieds”.  Ostensibly, (and I know this may be hard to believe), people paid actual money to place their posts, er, ads, into the newspaper for other people to see.

Craig Newmark made short work of that.  Craigslist monetizes only a tiny portion of their posting traffic – recruitment ads primarily – posted by companies, not individuals.  Everything else is free.  It’s hard to compete with free (as the music industry found out), so most of the air has gone out of the classified balloon.  Craigslist snatched up the tiny amount of air that was left.  By shrinking the market, Craigslist successfully competed against the big guys.

If you think about it, it’s a brilliant application of lateral thinking to the business problem.  Problem: the market is too big for me to compete.  Solution: shrink the market down until it’s a size I can handle.

The Web 1.0 shrinkage story was Ebay, who let the wind out of every auction house in the world.  More recently there’s stubhub, who’s wiping out the lucrative event ticket aftermarket (also known as scalpers).

The ingredients of effective market shrinkage seem to be:

1. Identify a cash-rich market built on inefficiencies – artificial scarcity, a massive imbalance of power etc.
2. Enter the market, replacing the basic business transaction.
3. Give 90%+ of the service away for free.
4. Watch the big guys asphyxiate.
5. Build your business on the remaining 10%- left over.

Presto – a market where you’re now the leader, at a managable size for you.  Mind the pile of bodies.

The idea of maintaining a single technology stack in a development shop is quite appealing.  If everyone knows the same programming language (the thinking goes), the same web framework, the same RDBMS and so forth, then life would be better.  Business really likes this kind of thinking.  It promises efficiencies of scale, reduced training costs, and easily replaceable employees.  This kind of “one true technology” approach is the foundational philosophy of corporate darlings Java and .NET.    Once you have the organization standardized on the tech, it is promised, then every part will play nicely with every other part, critical dependencies (such as employees) will be reduced, and the whole “what are we doing about technology” question just goes away.

Now, of course I support operational efficiencies, reducing training costs (well, to an extent: I view training as an investment), and so forth, but I think that the idea of “one true stack”, especially in service-oriented tech shops like web agencies, is a pipe dream.  The advantages of standardizing an entire company on a single tech stack are outweighed by the disadvantages.

Before I get into that, however, I want to introduce the idea of a “jealous” technology.  A jealous technology tries to take over as many aspects of the stack as possible; mandating a specific component at each level.  Some technologies are more “jealous” than others.  Microsoft is notoriously jealous:  the Microsoft web framework, ASP.NET, really wants to be deployed on the Microsoft web server: IIS, on the Microsoft operating system: Windows, backed by the Microsoft RDBMS: SQL Server.  Other combinations (yes, I know about Mono) simply don’t work as well.  And, on the other hand, Windows is something of a second-class deployment platform for most other web technologies (ever try to deploy Rails on Windows…with IIS?  Yuck…)

Speaking of Ruby on Rails, they’ve become a bit of a jealous technology themselves.  Rails projects now prefer a particular JavaScript framework (Prototype), version control system (Git), editor (TextMate), build system (Capistrano) and development operating system (OS X).  (As well as, obviously, programming language: Ruby). While it’s certainly not as bad as the Microsoft scenario,  I do have to ask the question as to why the web framework has any influence over what version control system I use.  Do you have to use all the technologies that I’ve listed above with Rails?  No, of course not.  But they are preferred.  Things go better with Coke Capistrano.

The point is that some technologies are better suited towards certain problems than others, and a blanket organizational standardization on a single tech stack leads to a tremendous amount of wasted energy spent on driving square pegs into round holes.  Ruby is not a great foundation for an enterprise-class messaging framework.  Java is not a good choice for a lightweight CMS.  And anything other than .NET is a bad choice for an app destined to be maintained by a bunch of MSDN types.

In fact, I’d argue that the cost of operation efficiencies lost by maintaining multiple tech stacks is exceeded by the cost of jamming technologies into inappropriate use cases.  So, as messy as it sounds, any technical organization that is project or service based (as opposed to being exclusively product based) should maintain a strategic “quiver” of different technologies, so it can deploy the best choice when faced with a business problem.  Otherwise a fragile [[Monoculture_(computer_science) | monoculture]] is created, wasting a tremendous amount of developer effort, and adding artificial risk and expense to projects.