« Don't Say I Didn't Warn You| Main | No I don't wanna do that »

Scaling Back: What Do You Need For A Small IT Shop?

| | Comments (0)
Cowboy Hat
Over the last few months, while not working on batBack (my social bookmarking invention), I've been helping a couple friends of mine with their consulting business in Virginia. This is kind of "coming home" for me, as I haven't worked in my home area for over 15 years. Their company has around 30 employees, and have been running a "Virtual CIO" and "Virtual IT" -based business, concentrating on local governments and regional businesses.

It's good to help people, plus I thought I'd give the luggage a break.

One of the things I've found is that there are a LOT of small IT shops out there -- shops with 1 or 2 developers and a manager, or shops with 20 people and a couple of managers. These shops are tasked, mainly, with keeping the lights on and the bailing wire and duct tape all secure. Call integration management. But some folks are seeking to do greenfield development as well. One of the neat things I learned is that some of the local governments in Virginia are actually building new systems and then sharing among themselves. That way localities all over the state can have the benefit of hundreds of IT workers without huge budgets. Very cool.

So what do you need to run a shop like this -- bare bones? Let's say you got enough money for three people. I won't count management or network support. What kinds of hats should you have?

  • Business Process Modeler/User Representative - Somebody has to keep an abstract view of what's the reason for doing anything in quasi-technical terms. More and more, shops are beginning to understand that by modeling and valuing the business processes, they are better able to make build/buy and insource/outsource decisions. Note -- this has to be done well, there is no room here for fuzziness. I like Use Cases because the model and the behavior are linked, plus the methodology allows me multiple ways to cross-check to make sure we aren't forgetting anything. Clear, mutually orthogonal use cases are the lifeline: and it's what you are doing anyway when you make business decisions and charter projects, just at a higher level of formalization.

    Somebody also has to represent the poor user, and no, this isn't always the user. Yes, get the users in there as much as possible and bring them as close to the development as you can. However, reality is reality. While the team should always participate in requirements sessions (especially in small teams), somebody has to have the ball when it comes to making sure the user's interests are coordinated. Everybody should be looking out for the user, but somebody needs the onus to be the point of contact. The BPM is the best person for this.

  • DBA/Enterprise Architect - Now that you understand why you are working, what's it going to look like? The connections, the classes, the physical structures -- this is the guy for all of that. Somebody has to champion EA, especially in a small shop! This person had better be making sure that all of the little applications use the same data store (if appropriate), the same standards, the same deployment pattern, etc. The most critical fractor in any kind of small-shop, do-it-yourself-programming is to make sure you have the money to maintain it once it is built. Development only represents about 10 percent of Total Cost of Ownership. Listen up! What's easy today won't be so easy when it is done 12 different ways on 40 different projects ten years from now.

    It's also important for somebody to be looking forward to new technologies and paradigms of development. the EA/DBA spot seems most suited for this. Somebody should be figuring out what are the common problems in the currently deployed code, which is also an EA/DBA thing.

  • Developer/UI Expert - This is the work most of us think of when we think of software development, which is strange. It would be like thinking building skyscrapers was mostly about carrying boards. Developers put the pieces together and frame up and fill out the structure. The architecture should already be done, the UI guidelines should already be in place, the data tier may have already been written. If your developers think of themselves like Picasso, then you may want to think about whether you are building an art gallery or a software portfolio for your organization.

    The UI expert should also be concentrating on how things are supposed to consistently look and feel. A good User Interface experience means savings in training dollars (and the ability to temp out work if necessary), less strain on the users, and happy feedback. Everybody likes happy feedback! The UI guy usually gets stuck with reports too, since the UI and the printed result are so close conceptually. I like to think that the UI guy is the "face" of the organization -- their work makes the difference in perception of what's going on. Remember: perception is everything. You may have a top-notch tool configuration, standards, and environment, but if you don't have a good PR shop, you ain't got bupkis.


Having put down these ideas, everybody has to do everything! The worst thing possible is to get into a mindset of "that's not my job". The reason why I was able to skip over things like testing, CM setup, A&D, etc. is that I'm assuming that _everybody_ will be doing those things. Everybody is valuing business processes, everybody is building the architecture, and everybody is programming. It's mission-critical in small shops that you do not compartmentalize software development - -there is simply too much complexity in modern programming for the pizza-under-the-door approach.

These are some ideas to think about. You can work this a million different ways: I think it's fun to wonder what the fewest number of important hats you need, that's all. Got a better idea? I'd like to hear about it.

Leave a comment

About this Entry

This page contains a single entry by DanielBMarkham published on October 19, 2006 1:44 PM.

Don't Say I Didn't Warn You was the previous entry in this blog.

No I don't wanna do that is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Social Widgets





Share Bookmark this on Delicious

Information you might find handy
(other sites I have worked on)





Recently I created a list of books that hackers recommend to each other -- what are the books super hackers use to help guide them form their own startups and make millions? hn-books might be a site you'd like to check out.
On the low-end of the spectrum, I realized that a lot of people have problems logging into Facebook, of all things. So I created a micro-site to help folks learn how to log-in correctly, and to share various funny pictures and such that folks might like to share with their friends. It's called (appropriately enough) facebook login help