Wed 12 Nov 2008
Posted by Scott Westfall under Dev Management
Comments Off on Our Nation’s First CTO
The press is abuzz with news items about President-Elect Obama’s search for a CTO and the possibility that he could make this a cabinet-level position.
This is a great idea! Technology is so prevalent in our society and in our government that it’s impossible to conceive of a plan for effective government that is not based on a sound technology roadmap. Certainly, if we need a Secretary of Transportation, then we need a Secretary of Technology.
Making this a cabinet-level position will hopefully give the USCTO the authority to bring uncooperative agencies together. In truth, I think that will be the biggest challenge. Bureaucracies are rife with politics. They don’t like to be told what to do or to work with others. They want to do things their way without someone else suggesting a better way.
A Chief Technology Officer can be instrumental in setting goals and directions for our nation’s IT infrastructure. However, I have seen CTOs wreak havoc on organizations that were doing just fine without them. Here are a few common pitfalls I hope the new US CTO will be able to avoid.
Outsourcing Core Expertise
I have worked for years as a contract programmer, and I have worked for companies that provided outsourcing services. There are times when it truly makes sense to outsource. If you are not a software company, but you need to have software built, then you are generally better off hiring a company to do that for you. A company that develops software full-time will be far more successful than one with no experience.
For example, I worked for a company that developed workflow and routing systems that incorporated high-speed scanners. We had significant knowledge and experience with the hardware and issues involved with these systems. Our customers were companies that processed forms for things like book clubs or medical records. Those companies simply could not have built these systems as effectively as we could.
For them, the systems we built were just a tool. Their core knowledge was related to the business of processing the records. They just needed a system that made it faster and easier to process the information.
However, I have seen companies whose main revenue comes from selling software outsource the development of their products. Commonly, this is done by partnering with an offshore development house.
The problem with this approach isn’t that it’s overseas; it’s that the people working on the product do not work for the company. If you make money by building and selling software, then why would you ever want the knowledge necessary to create and maintain your products to be held by someone with no attachment to your company?!?
Cost Centric Management
Improving an organization is hard. It takes thorough analysis and creative thinking to find ways to do things better. Rather than finding ways to do things better, some CTOs try to make their mark by doing things cheaper.
Don’t get me wrong, I do believe that organizations should be run efficiently and that managers should be looking at costs to make sure they are in line. However, cost management is often taken to an extreme.
Examples of this mentality include hiring cheaper programmers rather than focusing on the knowledge and experience needed. Many companies treat programmers like interchangeable cogs with no appreciation for the difference between individuals. So, if they can hire programmers for $10K or $20K less per year, that’s a big win, right?
This mentality drives the offshoring approach. The lower cost is touted as a big win for the company, but little consideration is given to whether the product can be developed as successfully. This is particularly problematic if the development team is split, as is so often the case, with the business team working here and the developers working overseas. Software development has been shown to be far more successful when there is close interaction between the programmers and the subject matter experts, even more so with direct customer interaction.
Companies also attempt to restrict costs by scrimping on the tools they provide. We see that one a lot at SlickEdit. We often hear from programmers who want to buy SlickEdit but are told by their management that $300 is too expensive.
At SlickEdit, every developer has multiple monitors. We believe this is essential to getting your work done efficiently. I have worked at some companies where I bought my own equipment because they would not approve anything more than a single 17” monitor.
The fundamental mistake that drives these decisions is that they assume a fixed level of output. So, they believe they can cut costs and the output will not change. In truth, we know that the level of output in software development is highly variable and subject to many complex factors. The definitive work in this area is “Peopleware” by DeMarco and Lister.
Standardization can be a good thing. When done properly, it ensures efficiencies of scale and the ability to dynamically manage resources within an organization. Standardization can be helpful to assist everyone in producing a similar result. If taken too far, it becomes a force to make sure that no one can achieve excellence.
No single tool or technology is good for all situations. The cost of trying to pound a square peg into a round hole can often exceed the cost of buying a round peg. You do have to guard against capricious choices (see Design Fail Patterns), but you should guard against a policy that is too rigid. Standardization should be a gravitational force that pulls towards a center, but it should not become an inescapable black hole
The larger the company, the more diverse their technology should be. Small companies may not be able to afford to dabble in different technologies, but larger companies can often see greater efficiency by allowing teams to select the right tools even when they are different. Further, by having a broader technology portfolio they reduce the risks associated with selecting a single technology, and they are more likely to discover new, more efficient ways of doing things.
I often see the word “vision” used with CTOs. They have “vision”. When I hear this word, I cringe. While having vision is often essential in succeeding, too often this word is used as license for narrow-minded, megalomaniacal tendencies that will brook no discussion or alternatives. Can you tell I feel strongly about this one?
Often the CTO forms this vision before they know anything about the organization. In my experience, the employees already know what needs to be done to fix most problems at the company. What they need is a management team that’s willing to listen. Instead, most employees fear going to upper management with problems and solutions.
Sometimes this “vision” is based on a success at a previous company. They see the new company as an opportunity to do what they did before. However, these successes are rarely repeatable. Organizations are just too different. Often, the reason a project succeeds is because of complex factors, not the least of which is the team that implemented it. Given the choice, I’d rather have the team from that successful project rather than one guy with the “vision”. Be careful how much credit you give managers (or any leaders) for the accomplishments of their teams.
Vision should provide an overall direction, a set of values that are used to balance competing needs. It should not be a totalitarian model to which an organization must conform.
I wish the new CTO of the United States much luck. It will be needed. Confidence in our government is at an all-time low. It will take much more than vision to change that.