Does Engineering Take a Back Seat to Market Forces?

I was thinking about the effect of stock analysts and capitalization on software development in publicly traded corporations. My former company in particular.

In a nutshell, capital expenditure is why IT professionals are required to report their time against capitalizable projects. I'm not an accountant, I don't really understand much about it.

What I do understand is that companies pay money for their IT labor and it can get categorized in one of two ways, capitalized or not capitalized. Capitalized expenses are considered better because some of that expense can be used to add value to the company as an asset. In traditional companies, it's like a bakery buying a mixer. The expense they spend turns into something that adds value to the company.

For publicly traded corporations this is very attractive. An increase in corporate assets is believed to help increase the corporation's stock price, i.e., maximize the short term value of the corporation.

My own theory is that most of the money that gets invested is through institutional investors that look at companies through their 10Q statements and other demographic information. When analysts look at IT departments, they are typically more interested in seeing that the expenses fit a certain profile, lots of capitalized expenses and lots of offshore labor seem to fit the profile of a well run IT department from a stock analyst's point of view, but I'm getting ahead of myself.

Companies try to manage capitalized and non-capitalized expenses. I think of it like good debt and bad debt. They say good debt is stuff like house payments and education. You're borrowing for things that add value to your net worth.

Bad debt is like credit cards, auto title loans, tax refund anticipation loans, and pay check advancement loans. Actually, in that company the credit card debt doesn't seem so bad. They are bad though because they, in and of themselves, don't add value and the terms for them are unbelievably bad.

My former employer tried to manage the balance between the good capitalized expenses and the bad non-capitalized expenses by educating all of the IT workers and holding them responsible for their time reporting. Any time spent working on non-capitalized expenses, e.g., fixing systems when they broke, was scrutinized and one could be expected to be asked to provide an explanation for time spent working on non-capitalized projects.

The company discouraged fixing broken systems through some organizational changes and implementing a resourcing process.

This particular company is trying to sustain a tremendous sustained period of growth, it's something like fifteen years of continous double digit growth. In my own humble opinion, the business will not be able to sustain the growth much longer, and the people who are in charge are afraid that they will not be in charge much longer if they fail to continue to grow the company.

I believe that every area of that company is under tremendous pressure to minimize non-capitalized expenses and maximize the amount of their fixed budgets into capitalizable projects. It is my opinion that the C level managers are now primarily concerned with how stock analysts evaluate the company. One way to do this is to focus expendatures so they can be capitalized.

IT is an especially ripe fruit for this treatment because IT labor costs are comparatively expensive to other areas of the business. In that company, IT engineers are third only to health care professionals with doctorates and higher management.

To the higher ups in a company capitalizing as much of their budget as possible is their number one goal, second is minimizing their non-capitalizable expenses, third--well what is it that IT does? That, in a nutshell is what is wrong with IT departments in corporations.

When the role of the department comes third on the priority list, it becomes clear that aspects of doing your job aren't important.

What suffers? Service and Quality.

Service is what an IT organization should be about. IT is supposed to help the rest of the business do whatever it does. The computers that people use and the software that runs on it doesn't hold any value unless other people in the business are able to use it to do their thing.

Quality is how good the service is. Quality is reliable. Quality is efficient. Quality does not frustrate people. Quality facilitates service.

Sacrificing either of service or quality for the sake of reducing costs is a loser's game. The term that the IT industry uses for this is technical debt. Jared Richardson takes technical debt a step further and calls it Credit Card Software Development. I think Jared has it right.

Technical debt accumulates through making unsound technical decisions. For example, a company that decides to postpone upgrading their computers is taking on technical debt. A company that allows its software engineers to practice undisciplined software development is accumulating technical debt.

The decisions they make today will cost them in opportunity costs down the road. In the case of the computers, maybe it's fine that they keep using the same hardware. In the case of the software, well that's where the debt can really snowball.

To continue the credit card analogy, IT pays its monthly statements through service and quality. Think of the services as the check and the quality is the likelihood that the check will not bounce. If the service and quality isn't provided, the credibility of the department, FICO score, suffers.
Once a department accumulates too much debt the figuratvie double-cycle-billing interest, fees, and universal defaults all begin to take a growing portion of the department's budget and become a very real problem.

In the real world I'm talking about systems failing. Not just outages, but other nasties like data corruption, lost information, and worse. It's the stuff that disasters are made of.

So how does this concept of trying to fit a stock analyst's profile of a successful company's IT department contribute to technical debt? I believe it does in a number of ways, but most importantly it causes external market forces to play an active and prominent role in technical decisions to the point where bad engineering decisions are being made because a stock analyst's opinion takes precidence over engineering principals.

What's the solution to the problem? I think it's two part. One, I believe that many stock analysts have no idea what makes a good IT department. I think they look at companies that perform well and see how they allocate their IT budgets and duck type that as good. Secondly, corporate decision makers need to stop cowtowing to the stock price when it comes to making sound technical decisions. You're the expert on what is right, don't let a profile determine how you do your job.