Wednesday, June 27, 2007

IT Rule #5: Outsource deep technical expertise

When looking at your IT staff and considering how to deal with the ever growing load of projects that need to get done, the issue of outsourcing comes up. As it should. The first question to consider is: What might we outsource? The answer is not "whatever we can save money on". That way lies madness and the path to failure.

What might we outsource? Looking at the skills necessary in an IT department, I divide them into 3 areas:
  1. Knowledge of the business
  2. Knowledge of technology
  3. The boundary between 1 & 2.
Knowledge of the business should not be outsourced. At all. At best you can bring in hired guns as analysts. In order for them to be effective, they need to locate on site and be there long enough to actually learn enough about the business to make a difference. But they can walk out the door if they tire of being a consultant or of your business. It is far better, especially for SMBs, to have analysts on staff. If you are small enough, training your developers on analyst skills so they understand the business better.

If you shouldn't outsource knowledge of the business, then you really should outsource the boundary between the two either.

That leaves technology as a possible outsource candidate. Clearly, in order to handle the boundary well, your staff needs to have some understanding of technologies that you have installed and that may be useful down the road. But what you don't need to have on staff (or what you can give up if you need to for resource reasons) is deep knowledge of technology.

For example, your admins may need to manage windows servers and a network. That keeps them pretty busy, especially with projects to improve capabilities. But from time to time you have difficult windows problems and network congestion. Outsourcing that expertise makes sense. Bring in a top-notch network geek and have them fix the problem or look at the overall implementation and make recommendations. Teach your staff one or two things to help future issues and walk out the door.

Another example would be a database administrator. We have three developers with long to-do lists. Having any of them take the time to become DBA-capable would take away from their development effort. And since we have put efforts into making them better analysts, we lose that also. However, bringing in a part time DBA resource makes sense. Such a person knows the deep internals of SQL Server and can easily see things that we won't see. They can make recommendations, help us fix things, implement some monitoring tools, check in once and a while. We get a better DB and we don't have a to add staff to do it.

info on my cellphone

(If you are wondering why this is here, look up and read my description of this blog.)

The Motorola E815 Super Page: Review, Motorola Ringtones and more information on the Motorola E815

Tuesday, June 19, 2007

Save a life or follow the company policy manual?

Fortunately, the guy did the right thing. Unfortunately, the company he works for thinks he shouldn't have helped her.



Jacksonville.com: Metro: Story: 'You're fired,' man hears after saving a woman's life

Iraq: Michael Yon: Be not Afraid





Michael Yon : Online Magazine » Blog Archive » Be Not Afraid

For far too long our media and government have failed to fully inform us–even to the point of lying–about Iraq.

Tuesday, June 12, 2007

Symantec's Norton AntiBot

This could be interesting if it worked. There has been little to protect against some of the newer bots and signature-based anti-virus (the majority of the ones on the market) are not sufficient against mutating malicious software.



Norton AntiBot - Symantec Corp.

Wednesday, June 06, 2007

IT Rule #6: Don't put your detailed error messages where the employee can see them

When problems happen in applications, the IT staff need to see as much detail as possible to help find the root cause. The employee, however, doesn't want to see all that crap. Give them an employee friendly message and tell them what to do. Put all the detail error codes, etc. into a log file somewhere or email them to the support staff.

IT Rule #5: Encourage people to tell you about problems

You can't fix/improve something if you don't know it is an issue. Make it very easy for employees to get an issue to you and that you have a mechanism for an IT staff person to grab it and let everyone else know they grabbed it. Respond quickly and *always* thank them for bringing it to your attention, regardless of how many times you have heard the problem. Remind employees constantly to tell you about stuff, even if they think you already know about it.



Repetition is important because of two factors:

  1. Most people tolerate computers doing weird things. Restart the app or reboot are typical attempts to deal with things. Typical because it makes the problem appear to go away (reality is that it justs masks the problem).
  2. Most people don't want to bother IT with problems because the IT group may be unresponsive, they don't  think the problem is important enough, or they just want to get back to work.