Email Me Daynotes Gang

The World of Corporate Information Technology

We in the Daynotes Gang all have our own style when it comes to our home computers. Some of us have very careful, well-planned schemes for handling any sort of problem; witness JHR's work-and-backup hard drive plan. Others have more conventional tape backup systems, where data is carefully preserved, but the prospect of a quick YANTI is not worth the effort of the total-backup scheme. Then there are those like me, who make sure the really important data is in more than one spot - but otherwise more or less just shrug and say "maybe next year". <G>

While many of us have jobs in IT, most of us work for the small companies, where the style and attitude are more or less the same as they are at home; low-end tape backup systems, "plans" that more often than not are contained entirely in the minds of the people implementing it, or at best, in a few emails that most likely has been completely forgotten by all recipients. Interestingly, this is usually good enough; systems stay online through serious problems, all-night sessions by the systems administrators make these cobbled-together systems do their intended tasks. Companies (usually) don't come crashing down around the ears of the owners. These are the best sysadmins in the business; the ones who can think on their feet, who know that life doesn't follow a playbook, and that when you can't afford to cover every potential problem, something's going to bite you.

Large companies usually don't have these problems. Established procedures, drawn up with care by professionals who manage the backup systems and nothing else, relatively large budgets for equipment in software resulting in top-of-the-line equipment - for the most part, their IT professionals work nine-to-five and don't have to worry about the unexpected. No matter what the problem is, it's probably been thought of and planned for by the central IT people of the organization.

It goes beyond the backup systems, too. Procurement, maintenance, allocation... every aspect of IT management is completely different for the large organization. Solemn-looking documents labelled "Disaster Recovery" replace red binders with "Beer Truck Book" scribbled on the cover.

One interesting aspect of this is that the quality of the people becomes almost irrelevant. I've met some big-company admins with amazingly low levels of ability and competence, but it doesn't really show - so long as they follow those solemn documents, they'll be fine. By the same token, if the organization has enough of those solemn documents, the company will be OK. The quality of the personnel managing the systems in the organization - the "front line" people - becomes irrelevant.

The procedural method has simplicity and stability on it's side; create your procedures (you need good people to do this, and more importantly, you need good writers to do this), distribute those procedures to your people, and that's about it. Procedures need to be updated regularly, of course, and upgrades can get interesting, but otherwise, that's it. The chief disadvantages are lack of flexibility - when something comes up that doesn't fit the procedures, you can have major problems - and slow upgrade cycles. For example, many major organizations are still using Windows NT rather than 2000 - not because of the cost, and not because there's any question about Windows 2000 being the superior OS for networked business environments, but simply because they don't have or they haven't distributed a foolproof upgrade procedure yet. Organizations using the procedural system can't be early adopters because the front-line people have to have that procedure before they can do the upgrade - and even then, they have to have the ability to rely on those procedures, they have to put the testing and the time into those procedures to be certain there will be no surprises when it's turned over to the front-line people.

The more informal method has cost and flexibility; you don't need that team of people creating, writing, and testing procedures, because you don't really have those procedures. Upgrades can occur as soon as the decision is made to make it; Zanova started using Windows 2000 as soon as it was released, and we were able to do that because we sat down together, drafted a plan, and implemented it - the procedure was less than a typed page (it was, as I recall, about 1/3 of a whiteboard - and in my handwriting, which means less than a dozen lines, most likely, typed), included the phrase "eat pizza paid for by [our boss]" and didn't have any of that polished, tested, thought-through stability of a large organization. But it worked, because we knew what we were doing, we had the skill and the flexibility to simply work through problems as they came up, and the comfort with each other and the teamwork ability to make sure the others knew about problems when they happened. The downside is doesn't have the stability of the other method; problems do happen more frequently, and every problem has to be attacked with all your resources. Admins have to work in "interrupt mode", where the instant there's a problem, the admin devotes all their energy to the task at hand - and if another problem pops up, they have to prioritize and make sure the more important problem gets fixed first, then the next, and on down the line until that magic day (which never comes <G>) when there are no more problems. It's almost impossible to say that the situation one week is the same as what it will be in the week following.

Personally, I prefer a structured-informal method. <G> I like to keep things structured from the strategic standpoint, but keep things informal on the detail level. For example, I've occaisionally been called upon to manage multiple, independent networks and systems simultaniously. I can't do that informally, or "bad things" start happening; projects get lost in the mix, or one network gets confused for another. What I prefer to do, then, is keep things structured on that level, using Microsoft Project (or something similar) to keep an eye on things; each network is handled as a separate "main thread". That lets me see at a glance which networks have upcoming deadlines, without creating the sort of paperwork backlog that so often happens in larger organizations.

Inside each network, though, I prefer to keep things a little looser. I might have someone working on those networks, I may not, or maybe some of both - either way, I don't like to schedule or proceduralize the whole thing. These are small networks, they need the flexibility, and they get the most benefit from that sort of organization.

Now, you might be asking what happens when these small organizations, in the nature of successful businesses, grow to larger organizations. The answer is, break it down. Put another level in there, so that my overview page still shows only one main thread, but there's someone in that organization I trust who has a similar page; their page shows the individual threads for that organization, without being concerned with the other organizations. In the extreme, there's another level below that, where each person at that level handles another set of projects. Beyond that point, you have to start proceduralizing the upper levels, but as much as possible, keep the lower levels flexible. We said that large organizations can benefit from the procedure model, and that's true - but the new economy does not suit the large organizations. Smaller is better, more flexible, more able to keep up with changes in the market. So capitalize on that. Break the organization down. Using Siebel as an example, there are 9,000+ employees on six continents. Siebel uses the procedural plan; every workstation is the same, every server is the same, and all the offices use the same playbook. But it doesn't have to be that way, and I think it would be a big improvement if it weren't. At the upper levels, you break things down; say, one team per continent. Each team handles things differently based on the market realities of their region; for example, the European office has different communications standards. They have easier telephone communication (particularly the mobile telephone service) but they have a tougher distribution problem. So they have different procedures to capitalize that. Below them, you might have Sales IT people, vs Development IT people. Sales people need stability, they don't like their computers to change; generally speaking (there are of course exceptions) sales people do not know or care what they're using or how it does what it does, they just want to know how to use it to sell things, they want it work when they hit the switch, and they don't want things to change - ever. So those IT people need to reflect that, keeping as much as possible "behind the scenes" and away from the sales people, so that they don't have to worry about the changes - they simply keep working as they always have. Developers, on the other hand, know what's going on, want more details, and want to see changes. They want to see new technology being used, and they actually don't mind if things don't always work - change is good, and that's an unavoidable byproduct of change. So those IT people need to be more knowledgable, they need to be more flexible, and they need to be more actively involved in how the developers do their jobs.

Below that level, we have offices - and these need to have good people in them, flexible people, who can work independently. Each office has its own rules, its own environment, and if the IT people in that office don't reflect that, then that office is not going to be as effective. Siebel is a very effective company; they make an excellent product, and they compete very well. But if a competitor came along who used the more flexible office environments, Siebel would be blown out of the water. It's not about procedure anymore; it's about flexibility, adaptability, and speed. In the old days, business was "the law of the jungle"; then it became more like "the laws of the petting zoo". Well, guys, welcome to back to the jungle.

Now if only we could feed the lawyers to the lions...