Make those bold moves

LAST WEEK, I wrote about making unpopular decisions and taking risks to drive a technology vision. In difficult times, leadership is on the minds of many CTOs.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

I recently attended a company-sponsored leadership program where discussion centered on the fact that the strongest leaders typically see things that others don't, and a leader's obligation is to guide people through sometimes treacherous waters to an unseen but promising place.

Unfortunately, much of what conventional IT leaders have traditionally done does not fall into that leadership rubric. Conventional IT wisdom dictates that the process of implementing new technologies in an organization is usually reactive -- your CEO keeps seeing CRM in The Wall Street Journal, so he says to the CTO, "We need a CRM system. Go implement one." Steering committees are formed, end-users are interviewed, requirements are gathered, project plans are drawn up, and hopefully, with hard work and some degree of luck, a new and effective CRM system pops out at the other end of the process. In organizations where other executives constantly feed the CTO with projects that he ultimately implements to their specs, the CTO becomes known as the chief implementor. The CTO becomes the last person spoken to, after others in the organization have decided to do something.

In my opinion, this approach doesn't show true leadership on the part of the CTO, and although these reactive situations occur even within the most visionary technology organizations, CTOs should strive to always be ahead of the curve and proactive in leveraging technology within their companies. Ultimately, the CTO role is equal parts strategy and tactics, so the successful CTO should be careful not to get stuck in the rut of just implementing what others tell him or her to implement. In the CRM example, the effective CTO would have been the person to bring the whole concept of CRM to the table, selling the CEO on the business merits of implementing CRM to help the company drive revenue more efficiently. By the time the CEO decides that CRM would be good for the company, the CTO would have already pitched a few approaches, would have vendors waiting in the wings, and would have gotten word-of-mouth recommendations from fellow CTOs on the best implementation practices.

Although it runs counter to typical notions of IT project management and implementation, I also think that the best CTOs sometimes force-feed technology into their organizations. This might sound overly aggressive or even imprudent, but the visionary aspect of the CTO role sometimes demands this approach. If you see your role as simply reacting to well-defined user requirements for systems, how will your organization ever stretch and find new ways of doing things that others have not considered? Sometimes the CTO needs to step out on a limb and say, "The old way is gone; we are going to do it this way now" (in an educated and informed way, after selling the change to your management, of course). According to Webster's Dictionary, innovation means "the introduction of something new," and if the CTO doesn't boldly take the lead, who will?

Finally, I should note I made an embarrassing mistake in my Feb. 18 column . The man who created Perl is indeed Larry Wall, not Randal Schwartz, not to diminish Randal Schwartz's critical contributions to Perl. I should know better as an enthusiastic Perl programmer and advocate who remains convinced that behind every great system there is a little (and quite often a lot) of Perl code.