The end of the IT Department?

I came across this post predicting the end of the IT department:

http://37signals.com/svn/posts/2785-the-end-of-the-it-department

While I think this blogger (David) is somewhat correct in that the traditional IT department is in danger, I think he has over-simplified the problems in communication between business and IT.  (Despite the fact that this is my second blog post recently rebutting a point made on a 37signals blog, I swear I don't have anything against the company itself or its bloggers.)

To start, David's characterization of IT personnel as creating roadblocks in order to keep jobs for themselves only perpetuates false stereotypes of IT workers.  One does not need to look hard before finding out that the "rigid and inflexible policies" put in place by the IT workers are often there to protect the company's data, either from accidental or malicious acts.  Bad information makes Information Technology useless, so it is vital that IT workers strive to protect and maintain good information.  Secondly, I have never encountered a situation where a good worker, IT or otherwise, deliberately making things hard for users in order to save jobs.  IT workers tend to want to make things more efficient in order to move on to more exciting projects using new technologies.  Finally, it will be a LONG time before medium-sized (much less large) companies can get most or all of the services it needs from "a web site somewhere".  It is extremely tough to integrate technologies, customize workflows, increase security, etc. without some sort of IT department.

I don't doubt that there are a few companies will choose to go the route that David outlines.  However, those that do may find themselves at a competitive disadvantage.  As I wrote about in an earlier post, companies that treat their IT implementation team as a true business partner will find themselves better able to build system that provides business value.  Companies ought to strive to have their IT operations in Stage 4, otherwise they cannot get the most out of their business.

I would agree, however, that the days of the traditional IT department are numbered.  I have not done sufficient research to say what the trends are, but I think it would make sense to reorganize the IT functions to break up its current functions into different areas.  In many companies, it may make sense for each department to have personnel that have IT skills appropriate for that department.  For example, public-facing web development and design may be done by marketing personnel or financial rules may be programmed by accounting personnel.  Rather than eliminating the IT department, IT personnel would instead be responsible for ensuring consistency in approach, ensuring safe data (both in terms of security and in reliability), and evaluating future trends for company applications.

For such a scenario to occur, we must all be more knowledgeable.  At least David and I agree that the future of IT involves having more technically-savvy business people, but I would take it further than he seems to.  Business people will need to learn the basics of programming, source control, and other similar items.  IT personnel will need expand their knowledge and experience beyond simply maintaining computers and computer systems to learn more about enterprise-level concerns and functions.  It would not be an easy transition, but I think it is a necessary one, both to get the most out of our technology efforts but also to prevent us from being outsourced.

Interview questions

Here is a list of interview questions that Scott Hanselman suggests for senior software engineers:

http://www.hanselman.com/blog/NewInterviewQuestionsForSeniorSoftwareEngineers.aspx

I usually like reading what Scott writes because he is often interesting and insightful, but I was quite disappointed with this one.  Interview questions must first be designed with an end goal in mind.  Is he looking for someone to implement the business analysts' designs, or gather business requirements themselves?  He's clearly looking for the former, but a significant number of openings I've seen for senior software engineers are looking for the latter.  Is he looking for someone to lead teams of developers, or do most of the programming from base architecture work to finishing touches?  He's not really asking questions about either, so I'm not sure what his assumptions are here.  Is he open to engineers who don't believe that object-oriented programming is the one and only true way of programming?  (That question isn't entirely fair, since it's perfectly valid for a company to say that OOP may not be the only way to program, but it is the standardized way in their company.)  And the list goes on.

In the end, interviewers should be aware of lists like these because they can give an interviewer food for thought in trying to determine which interview questions to ask.  But always keep in mind that the writer has their own biases, and they may be trying to solve problems that may have nothing to do with yours.

Marketing for IT

Before I started my MBA, I thought "marketing" was comprised of sales and advertising.  I knew little of focus groups, but I assumed that they had something to do with sales.  While this wasn't spelled out explicitly in any of my classes, I've begun to think of marketing as this process, in this order:

1. Understand what it is your customer needs
2. Understand how you can meet those needs
3. Teach the customer about your product (Advertising)
4. Persuade that your solution is worth money (Sales)

After looking at marketing in this way, I started thinking that the most important aspects are numbers 1 and 2, not sales and advertising.  Yet a very large number of companies focus on the last two.  It's not hard to imagine why.  These two activities have a direct, measurable impact on the company's bottom line.  Skipping steps 1 and 2 can lead to problems, but they can appear to be other problems if you don't know what you're looking for.

A great example of how this can be an issue can be found in a blog about native applications for mobile devices vs. mobile web for a particular company.  It's an interesting blog, but I was struck by this comment:

Eventually we came to the conclusion that we should stick with what we’re good at: web apps. We know the technologies well, we have a great development environment and workflow, we can control the release cycle, and everyone at 37signals can do the work. It’s what we already do, just on a smaller screen. We all loved our smaller screens so we were eager to dive in. Plus, since WebKit-based browsers were making their way to the webOS and Blackberry platforms too, our single web-app would eventually run on just about every popular smartphone platform.

They may be right in that web apps targeted for mobile browsers might be a better solution for their customers than programs built for specific devices.  But I would argue that their approach needs to be changed.  Their reasoning to move to mobile web is all about themselves, such as their knowledge of technologies, better control, etc.

While these points are important, it is much more important to consider what their customers need.  If their customers need the greater flexibility that can be found by creating device-specific apps, they will be short-changing their current customers and limiting their markets in the future.  They could also be alienating their current customers who don't want to be forced into a certain solution merely for the convenience of the developer.  Instead, they should determine what it is that their customers need.  Do they need cross-platform solutions?  Do they need top performance and ease-of-use?  Are there going to be a lot of updates to these apps?  Without answers to these (and other) questions, you can't reasonably limit yourself to one solution or another.