Ah, for the heady days of 1999, when money from the sand hill Road venture crowd flowed like water, and customers flowed like sand from a California beach. Those days are no more, but the real work of company building continues—at least in that fraction of the dot-coms that saved enough cash or generated enough revenue to make it this far.
The job of a dot-com CTO—my job—has changed dramatically over the last several years. When companies were launching, everything was focused on getting the concept to market. Products went from idea to design to implementation at full tilt, with people working 24-by-7. The faster you could get eyeballs, the higher the valuation placed on each financing round—particularly important when public offerings were expected to happen within a year of launch and sometimes sooner.
The environment is different in 2003. The remaining dot-com CTOs are taking on roles reminiscent of CIOs in more established companies. They must reduce spending, motivate people and extend technology life cycles.
The dot-com boom and bust proved that basic financial and management principles werent really suspended, although it may have appeared that way for a while. You cant build a great system in a day, let alone a series of systems; it takes years to build out the infrastructure that we take for granted in the organizations we deal with every day, such as credit card companies, phone companies, brokerages and, yes, even government agencies. Those dot-coms that didnt recognize this are now dealing with their own “legacy” systems—systems that cant be easily changed to meet current business requirements.
Some dot-coms did spend considerable time thinking about this when money was available. They spent time on system architecture and infrastructure; time building scalability, whether or not initial projections for customer growth were met; time building flexibility so that they could continue to adapt to changing demands for functions and features. Those dot-coms that spent time and money on architecture-based systems development ended up creating tomorrows assets rather than yesterdays legacy.
Any CTO is concerned with marketing products and services. That requires tailoring systems to new markets, functions and operational environments. The company can adapt only if systems adapt; systems can adapt only if they have a strong foundation and architecture. The CTOs key job is ensuring that the companys systems support its mission. It isnt just throwing some new functions together quickly; its establishing the architectural principles that will guide development so that the systems will let the company provide a useful service to a growing customer base.
Jerrold M. Grochow is still CTO of Foliofn Inc., a financial services and technology company in Vienna, Va. He can be reached at grochowj@foliofn.com.