Small Company Blues

At dinner with a friend yesterday, he lamented about problems rolling out technology in a firm he is managing. Apparently his team misses their delivery dates; by a large amount. As he described his situation I felt like I was experiencing deja-vu.

His story in brief; he has four people maintaining his technology. These people are responsible for bringing clients online, handling technical problems, and building new capabilities. Projects are frequently months late. A core component of the system is constructed on an antiquated platform (Paradox) and only one individual has working knowledge of the code. And on and on.

This is a very common situation in technology firms managed by "non-technical" people. It is caused by the number one oversight of CEOs who have never worked with sourcecode. I even see it here, at my current firm. The problem is that there is little accounting for maintaining the product. The assumption being, when the product is delivered to the customer, its' developers are free to work on the next thing.This is a dangerous trap and I have seen many very intelligent executives fall in it. Inevitably, the development team becomes forced into choosing between support of the current product and construction of the next. That decision is a no-brainer, and construction of the next thing gets continually put on hold.The solution is fairly simple, but it is a bitter pill for developers. The team must be split, with one group providing support and the other working on the next thing. Of course no one want to be trapped providing full-time support. In my role, I have tempered this morale issue through job rotation. In the end it is necessary to prevent the continuous interruption of new development.