tcwicks.com - Art of the state

Well if you are reading this then the chances are that something is indeed wrong with your IT department. If not then count yourself among the lucky few.

Disclaimer: This article contains many generalizations and it is important to bear in mind that there is always an exception to the rule. The generalizations here are merely used for illustrative purposes.

Disclaimer: The ideas, opinions, views and other content expressed here are nothing more than my personal opinions.

So what exactly is wrong with the I.T. department?

Summed up in one sentence I would say both everything and nothing. Over the years I have witnessed a significant number of otherwise outstanding companies with mediocre or even worse non functional I.T. departments.

Why is this the case?

While there are many reasons for this the primary reason is simply the fact that I.T. is probably the only engineering field to enjoy a department within non engineering companies. Consider other engineering fields such as genetics, electronics and quantum physics.

Would you expect to find a genetic engineering department in a non engineering company? Probably not.

Would you expect to find a electronics or quantum physics department in a logistics company? Probably not.

What kind of an engineering field is I.T. ?

Among the engineering fields I.T. sits with at par with the most complex. I.T. has its sticky finger in every single other field across the board including not only the other engineering fields but most non engineering fields as well. You will probably find an I.T. department in every nature of large company ranging from avionics to logistics to farming.

Why is this important and what is the relevance ?

Engineering fields unlike most others require a bottoms up approach to management.
On the other hand most other fields work quite well with a top down management structure.
Top down management structures simply do not work with I.T. and most other engineering fields.

What is a top down management structure?

A top down management structure is one where the most significant decisions are made by the most significant persons as per the company hierarchy.

In a farming company the management team will naturally have sufficient if not comprehensive knowledge of the field. The same applies to most other non engineering companies such as logistics, printing, manufacturing etc…

Within these companies the management team has sufficient knowledge within the field to make correct management decisions. Therefore a top down management structure works quite well (except within their I.T. departments).

What exactly is a bottoms up management structure?

A bottoms up management structure is one where the most significant decisions are made by persons who in any other company would be the least significant as per the company hierarchy.

Consider as an example radical I.T. companies who have helped define I.T. itself.

Apple Inc. is headed by a systems integration expert known as Steve Jobs. Steve Jobs is probably the most technical engineering expert within the company in terms of broad knowledge across the sub fields of I.T.
Microsoft Corp. Used to be headed by Bill Gates who was not only the CEO but also systems architect for the company. Once again we see perhaps the most technical person in charge.

Bottoms up versus Top down.

As stated earlier most non engineering companies tend to apply a top down management structure to their I.T. divisions. What this implies is that the technical team would report to non technical project managers who in turn would report to an I.T. manager. The I.T manager would most likely report to senior management such as Director of Finance.

On the other hand most engineering companies apply a bottoms up management structure across the board. What this implies is the exact opposite of the above example. To make this point even clearer consider that within most engineering companies the Director of Finance would report to or be at par with the most senior technical person within the technical team. It is often the case that I.T. companies are headed by a Systems Architect / Systems Integrator.

Cause and Effect

The cause is applying a top down management structure to an I.T. department.
The effect is usually catastrophe.

Understanding the Cause and Effect

Decisions made within engineering fields are based on completely different metrics as opposed to non engineering decisions. One does not expect anyone but an avionics expert to make key decisions with respect to an avionics project.

Therefore why is it that an I.T. manager makes key decisions with respect to I.T. projects, when most I.T. managers primary subject of expertise is management instead of the technical aspect of I.T. ?

Why is it that we expect such I.T. projects to produce any measure of success ?

So what exactly is wrong with the I.T. department?

The short and simple answer is the management structure.
Within most non engineering companies the key I.T. decision maker tends to be an I.T. manager or CTO. Yes it is true that the vast majority of I.T. managers / CTO’s tend to have strong management skills. However it is almost never the case that same managers would be technically at par with their own I.T. team let alone a systems architect. Yet they make the key project decisions and at the same time expect results. Quite often the simplest decision within an I.T. project has far reaching consequences.

An industry example

Perhaps the clearest example of this is what happened with Apple Inc, Steve Jobs and Next Corporation.
About Apple Inc.: http://en.wikipedia.org/wiki/Apple_Computer
About Steve Jobs: http://en.wikipedia.org/wiki/Steve_Jobs
About Next Corporation: http://en.wikipedia.org/wiki/NeXT

A common example

Lets consider a specific example. How often has an I.T. manager or project manager attended a seminar on the Service Oriented Architecture model and then proceeded to impose this on every single I.T. project? As a matter of fact most of the I.T. implementations which I have rescued, needed rescuing in the first place for this very same reason. Service Oriented Architecture also known as S.O.A. was a major hype over the last few years and is only recently losing its hype factor. The S.O.A. model dictates that the application business logic should implemented using a service model. When an I.T. manager or project manager dictates the service model they do so by reading high level seminars. In fact the decision as to which business logic architecture to implement can only be done with a clear understanding of all available models such as the domain entity/component model, or the model view controller model. It is a fact that most unsuccessful I.T. applications implemented during the SOA hype failed simply because an alternative model was more appropriate.

It is a fact that when most I.T. managers / project managers state the words “I have made an executive decision”, what they actually mean is:
“I have made an executive decision even though I have no comprehension of its consequences or its impact, and I have done so simply because I can. Besides I have already lined up 3 people as fall guys to cover up for my mistake.”

At this point ask yourself the following question.

How often is it that the I.T. manager / project manager will bring the key technical people to a steering committee meeting where key decisions are made. Yet these same managers are the first to point fingers when something goes wrong.
“With authority comes total responsibility. However authority without knowledge and awareness bears likeness to a monkey with a chain saw” ~ an unknown wise person.

I do not necessarily agree with Type A/B personality theories. However further compounding this I.T. management problem is the fact that most I.T. management in non engineering companies tend to be Type A personalities. The Type A personality usually does not work well for management in engineering fields. Type AB tends to be the best choice here. Although the type A/B/AB personality theories has been heavily criticized I am using it here only as a broad sweeping generalization of character traits.

So what exactly is wrong with the I.T. department?

My personal opinion is “Insanity” as defined by Albert Einstein
“Insanity: doing the same thing over and over again and expecting different results” ~ Albert Einstein / Rita Mae Brown

So how can we fix the I.T. department?

The answer is of course much easier said than done. The first step is of course a top down decision from the most senior executive to “Fix the problem, no matter the cost”. Until such an authoritative decision has been made any further action is a pointless exercise in insanity as defined by Albert Einstein.

If a top down decision to “Fix the problem, no matter the cost” cannot be made then a few mildly entertaining exercises are listed below.

a) How to produce a comprehensive 500 page worthless document to please the shareholders: http://www.google.com/search?q=IT+Auditor

b) How to produce an extremely expensive 5000 page I.T. strategy plan that leads to nowhere:
http://www.google.com/search?q=IT+Strategy+Consultant

c) How to engage in a pointless fault finding exercise to identify the perfect fall guy:
http://www.google.com/search?q=IT+Forensics

Consequences and benefits of fixing the I.T. department

The decision to “Fix the problem, no matter the cost” is a giant leap for any company. Once this decision has been made there is no turning back. It is essentially a complete restructure of the I.T. department itself and usually means that most of the existing I.T. department will either resign or be made redundant.
In the short term this means significant costs and hardship
In the longer term however the overall business benefits far outweigh the short term negatives.

Fixing the I.T. department.

Disclaimer: First off this is by no means a definitive guide on how to fix a broken I.T. department. It is simply ideas, thoughts and my personal opinion on the topic. Before making such a decision one must always obtain expert advice and reach your own conclusion. As always proceed at your own risk.

If you have understood the disclaimer above then please do read on. If not then perhaps the following url would be a good place to start: http://www.google.com/search?q=never+believe+advice+on+the+internet

In my opinion the first step is to identify and recruit the key person for the I.T. department. This is not only a highly skilled position it is also a multi-skilled one. As a further complication this person needs to posses some of the characteristics of both a Type A personality as well as a Type B personality. Some type A / type b characteristics are extremely undesirable for this position.

The usual character traits would probably be along the lines of

1. Infinite patience and relaxed but NOT easy going (hard I.T. problems require infinite patience)
2. Highly aggressive but NOT competitive and NOT hostile
3. Incapable of relaxation (always go go go, there is no off button)
4. High achieving but not necessarily a workaholic (high achiever with a social life, communication skills and people skills)
5. Ability to multi task across multiple problems simultaneously
6. Assertive person with complete lack of ego problems (contradiction of terms?)
7. An assertive and confident person who believes that there is always a better way (once again a contradiction?)
8. An analytical but both random and creative personality (is this possible?)

This is by no means an exhaustive list, however as you can see most of the key points listed above are contradictory personality traits. People with these personality traits contradict the very definition of Type A/B personality theories and Psychometric tests. However these people do exist and I am lucky to have personally known a few myself.

As you can see identifying the key person is by no means an easy task. Fortunately there actually is an easy way out. A few I.T. professions are based on this exact personality definition. Although there is always an exception to the rule, the majority of professionals who excel in the following fields tend to be a good fit for this key position.
1) Systems & Software Architects. The Systems & Software architect is a jack of all trades, and unlike the proverb, is also a master of all trades. A good systems and software architect is by definition required to be all of the following contradictions:

• 1.a) Ability to simultaneously visualize a problem/goal/project both at a high level as well as at its lowest level.
• 1.b) Ability to muti task while maintaining overall high level coherence.
• 1.c) Comprehensive understanding of a broad spectrum of technologies both at a high level as well as at their low level implementation details.
• 1.d) Possesses authoritative domain knowledge while at the same time acknowledging that there is always room for improvement.
• 1.e) Highly aggressive with respect to problems/goals and projects while at the same time not competitive or hostile within their team. The reason here is that they have nothing to prove and job security is never an issue.

2) Systems Integrators. The systems integrator is a unique variant of the Systems & Software architect who possesses the same skills and capabilities. However unlike the architect this person does not focus on creating any one overall solution. Rather they believe that solutions are best achieved by combining multiple distinct solutions together. Good systems integrators are a very rare species on the verge of extinction. I would not necessarily state that a systems integrator would make a better key person as opposed to a systems & software architect or vice versa. These are simply two different but equally valid approaches and points of view.

3) Infrastructure architect. Do not confuse this profession with the above two. Good infrastructure architects are the best key person for I.T. infrastructure companies. However they lack the broad spectrum knowledge required for being the key person within non engineering companies.

4) The other architects. There are many variants of the architect profession some of which have been created simply for the purpose of C.V. decoration. As always there is an exception to the rule but in general these positions do not have the broad spectrum knowledge required for holding the key management position within the I.T. department of a non engineering company. Some of these variants include

• 4.1) The database architect – This persons specialty is visualization of data and data processing/manipulation. There is no broad spectrum knowledge here.
• 4.2) The network architect – This persons specialty is the ability to understand / visualize highly abstract data communications structures along with intrinsic knowledge of extremely specialized hardware devices. There is no broad spectrum knowledge here.
• 4.3) The web architect – This persons specialty is all things related to the web, but generally lacks knowledge outside this spectrum.
• 4.4) Game systems architect – This is a highly specialized field dealing with high performance code, complex mathematical abstractions and artificial intelligence. There is no broad spectrum knowledge here.
• 4.4) The architect – Many of these XYZ architect professions have been created for the purpose of C.V. decoration or self esteem. I once stumbled across an employment advertisement for a windows file systems architect. This bears likeness to an architectural firm recruiting a “red cottages made of wood with doors and windows architect” for the position of chief architect.

etc…

By now it should be clear that a functioning I.T. department within most non engineering companies needs to have a completely different organizational structure / policies as opposed to the rest of the company. If this is not clear and you are still reading this document then you could either:

1. Read from the beginning and do some research on the ideas expressed upto this point
2. Decide that this article is complete rubbish and optionally proceed to rant and rave about this article.

If you are an I.T. manager / project manager who totally disagrees with my personal point of view, you could:

1. Shake your fists, scream, rant and rave.
2. Understand the ideas expressed here and better yourself.

On the other hand if your an I.T. manager / project manager and agree with some of the ideas expressed here. What are you doing still reading this article? You probably have one of the very few functioning I.T. departments.

Once we have found the right key person what next?

The next items on the agenda include the IT business liason, department structure, human resources, management practices, budgets, bureaucracy and management politics, Risk Management.

The I.T. department structure.

Recruitment and retention of a good technical team is entirely another can of worms. The traditional approach would probably be to first recruit an I.T. manager along with one or more project managers. Wrong Answer.

By now it must be clear that the positions of I.T. manager / project manager are redundant within I.T. departments. These positions are replaced by their I.T. counterparts. Your key person (systems & software architect / systems integrator) is effectively your I.T. manager / CTO. Your technical team leaders are your project managers. The reasons are as discussed before the fact that management of an I.T. project requires intrinsic knowledge of both the high level as well as the low level technical details. Your key person possesses the broad spectrum cross domain knowledge which is supplemented by the subject area expertise of your technical team leaders.

The I.T. human resources problem.

Once again as usual most standard human resources practices simply do not apply here.
For example Psychometrical tests will only serve to exclude the best I.T. professionals. It is a fact that extremely technical I.T. professionals are almost guaranteed to fail Psychometric tests. The reasons for this are due to the fact that high technical skill is usually achievable only by those who posses contradictory personality characteristics.
Recap:

1. Infinite patience and relaxed but NOT easy going
2. Highly aggressive but NOT competitive and NOT hostile
3. Assertive person and confident person with complete lack of ego problems
4. An assertive and confident person who believes that there is always a better way

These are contradictory personality characteristics which completely disrupt psychometric tests. In other words these people simply cannot be analyzed by means of psychometric tests

The work horses of the department.

Standard human resources expectations do not work. You have to understand the geek.
While some might classify the I.T. genius as a geek, I have the greatest respect for them. Some of the best technical brains I have ever met are perhaps best described as follows:

1. Multiple piercings sometimes including nose rings
2. Long unkept hair sometimes completely frizzed out
3. Chewing bubble gum during an interview4) Utterly incoherent during a non technical conversation.
4. A dress code which does not fit any known era.
5. Wake up at 10 and work till midnight.

People with these characteristics simply do not fit the standard human resources expectations. It takes a geek to understand another geek. This is why the key person described earlier is of utmost importance. This is probably the only person within the entire I.T. department who can understand the geek. Simply because this person most likely was once a geek or at the very least has had significant exposure to the same.
I myself was once a geek and have since graduated to being a domesticated geek.

A good speech on this topic by Guy Kawasaki can be found at the following URL:

http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1178

Industry Standard Management Best Practices

Unfortunately the sad truth is that there are no Industry Standard Management Best Practices here. This is due to the inherent overwhelming complexity of all but the most trivial I.T. systems. However the good news is that effective alternatives do exist.

Terms such as P.M.O and P.M.I. do not belong here and are only counter productive. Consider that comprehensive project documentation for even the most trivial of I.T. projects would consist of many thousand pages and require an army of technical writers. It is an impossible task to apply standard project management methodologies to an I.T. department. It is for this reason the chosen key management person is a multi skilled broad spectrum technical expert.

Prescribed management practices might work within non engineering fields. However within I.T. these are instead replaced by abstract conceptual methodologies. For example for software development projects methodologies such as agile, extreme programming, waterfall, etc… can be applied with great effect. While many such methodologies exist no single one is consistently superior to another. Depending on the nature of the project one will produce superior results to the others. In some instances the combination of multiple methodologies can be the best course of action.

The I.T. Budgets nightmare

Within all but the most trivial of I.T. projects the concept of a project budget simply does not exist. Consider as proof of this the fact that 90% of I.T. projects go considerably over budget and are usually de-scoped near the end simply because of the budget.

No sane person would expect a complex project such as the NASA space shuttle to be completed within a given project budget. The reasons for this is is simply because the number of unknown factors and their permutations are of such a scale that they cannot even be quantified. This is equaly true for space research as it is for I.T. projects.

I.T. projects like all engineering projects consist of all the attributes of a complex research projects. Regardless of the volume of initial groundwork there is always a larger component of unknown factors.

An example of a typical I.T. project is along the lines of the following statement.
“Please deliver this package to our office 4000 miles away. You have a car with no headlights, no brakes, and it’s engine is in an unknown state. In addition there are no road maps, you have no license and the car has no registration”. Would it be realistic to expect project budgets and timelines?

In the case of I.T. projects the concept of a project budget simply does not exist. In place of this we have a department budget. In simple terms this is the figure which your company can afford to spend on I.T. on an ongoing basis.

The way it works is simple. First define the goals, and the department budget. Next let the I.T. department do its job. Understand that more often than not they are working blind and will run into more obstacles than you can count.

Beauraucracy and management politics

Unfortunately this is an unavoidable evil within almost every company. People will always have their own agenda. The statement “I.T. does not communicate with business” has become common place these days. Regardless of the skills and capabilities of the key person chosen to head your I.T. department, this issue will almost always show its ugly head.
As a non engineering company unfortunately it is probably not practical to implement corporate cultures such as those employed by small engineering firms, or large I.T. companies such as Apple Inc. or Next Corporation
The alternative is to find and recruit your I.T. business liaison. This position is one that is as important as your key person chosen to head the I.T. department. This person serves the purpose of interfacing between the head of I.T. and management of other business divisions.
Perhaps an example would suit here. The following are a few common opening statements from I.T. in response to business:

1. When you have grown a brain then come and speak to us.
2. Get your act sorted and stop wasting our time.

These are statements are usually made out of frustration, and the ensuing explanations never reach their intended ears as the audience has already been offended.
The purpose of your business liaison is to first listen to the opening statement. Next find out the reasons behind the statement, and finally explain the reasons to the business while leaving out the opening statement.
It is a fact. I.T. does not speak business and business does not speak I.T. This is where the translation skill of your business I.T. liaison comes in.

Finding the right person for this position is by no means an easy task. The person needs to be able to speak both languages and live in both worlds. In general I’ve found that people who excel at this function generally have the following characteristics.

1. Extreme but delicate negotiation skills while keeping an open mind.
2. Ability to understand both sides of a story an reach a compromise
3. Ability to manipulate any situation such that both parties willingly agree to the desired outcome.

A few people who I personally know that excel at this task are perhaps best described as “Should have been a lawyer but went into I.T. instead”. No one in their right mind messes with this person. Therefore it is of utmost importance to chose someone who would keep the best interests of the organization in mind.

Risk Management

How often have you heard the statement “There is a risk in the project”. How often have you not subsequently heard a solution from the same person. This is usually nothing more than a cry for attention from a project manager with severe insecurity problems.

“There is a risk in the project” ~ The Project Manager
“Any fool can know. The point is to understand.” ~ Albert Einstein

By now it should be clear that any non trivial I.T. project is a risk in itself. It is understood that the number of risks in an I.T. project are beyond measure. All but the most trivial I.T. projects do not have any guarantee of success. Rather it is a measure of relative success with respect to the overall goals taking into consideration the available resources. Complicating this issue even further is the fact that technology is a rapidly evolving environment. In other industries changes of significance may take years. In I.T. these changes take place within a matter of months. Consider that a state of the art application will remain so for at most 6 to 8 months after which it is outdated in terms of technology.

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.” ~ Albert Einstein

It is important to understand that I.T. in itself is a risk, while at the same time I.T. cannot be avoided. You simple need an I.T. team with the capability to deal with each risk as they surface.

What is your existing I.T. department worth

So what is the net worth of your I.T. department as an asset to the company. Unfortunately most I.T. departments are a liability to the company rather than an asset.

The venture capital version

How to value your I.T. department is perhaps best described by Guy Kawasaki. An MBA who is an entrepreneur and venture capitalist at Garage Ventures http://www.garage.com/

Guy Kawasaki once described the venture capital valuation of an I.T. company as follows.

1. For each technical person within the company add $500,000
2. For each mba / manager in the company subtract $250,000

You can view the full speech at the following URL:

http://ecorner.stanford.edu/authorMaterialInfo.html?mid=268

This is an interesting point of view as it further highlights the bottoms up management structures required.

“Education is what remains after one has forgotten everything he learned in school.” ~ Albert Einstein

The panic reaction method

The next time there is a major I.T. crisis within the company carefully observe how the I.T. team behaves. You will notice 4 distinct behavior patterns

1. Some of the team although highly alert will be working to fix the problem or assisting those who are working to fix the problem. For each of these add $250,000
2. Some of the team will have a don’t care attitude and their only response will be “It’s broken”. For each of these subtract their annual salary.
3. Some of the team will ascend into panic mode running around the floor winging their hands and distracting those who are trying to fix the problem. For each of these subtract $250,000
4. Some of the team will walk around the floor authoritatively disturbing those who are trying to fix the problem by asking them for timelines and demanding explanations. For each of these subtract $500,000. If your I.T. manager is in this group then you have a writeoff.

As a final exercise list the positions of those who fall into each category. You might be surprised by what you find.

Who the hell am I

Simply put I am nobody. I am also

1. The CTO of a web development company.
2. The CTO of a software technology research and development company.
3. The CTO of a large interactive social networking portal.

My Blog: http://www.tcwicks.com

My Email:

“Some see the world through the limits of their own vision. Some do not. Join them.”