Evolved Technologist -

Back to Education of a CTO Table of Contents

Geek Gourmands

I started coming to San Francisco in 1994 and quickly ate my way through the city. Postrio, Masa, Boulevard, Jardinere, Fleur de Lys, The Slanted Door, Flying Saucer, Rubicon, Aqua, and Bix provided the comfy banquettes from which I sold my company or others sold to me. My vendors loved me for blowing their horn as an enthusiastic reference. I loved them for giving me massive discounts and extra service. We both loved the delicious meals set before us.

My favorite was Farallon, a restaurant on Post Street just off Union Square. The décor consists of amber-colored translucent horns, bulges, and oddly shaped protrusions that provide the feel of a 1950’s era Jules Verne science fiction movie. At the side of cavernous main chamber sits the Wine Hold room, a private dining area with a long table and a mural showing a wine cellar full of barrels.

In the Wine Hold Room in June of 1999, I hosted a dinner for 14 of the most interesting CTOs in Silicon Valley. By then, I had decided to write this book and I wanted to get the received opinion about what CTOs do well, what they do poorly, and how they can do better. A reporter from Salon attended, and wrote the evening up in an article entitled “Geek Gourmands”.

The substance of the discussion, and of this chapter, was an exploration of the role of a CTO. The attendees cut a wide-swath through Silicon Valley. Cary Jardin, CTO of I-Pivot, helped fund the dinner. I-Pivot was a company that sold hardware to balance Internet traffic across servers. Accrue, a company that sold software to analyze web logs, paid the other half of the bill. Bob Page, Accrue’s CTO, sparred with Rick Kreysar, the CEO. Earl Rennison, a refugee of the MIT Media Lab started a company called Perspecta, showed up. Perspecta was a system that help tag content with meta data and then navigate as if you were flying through the content. Phil Nelson, former CTO and founder of Verity, a text search company, was there with the current VP of Engineering at Verity. Alex Cohen, who was in the midst of a stay at Kleiner, Perkins as Entrepreneur in Residence, brought his perspective as an academic and veteran of several firms including Netscape and C-Net. Senior technologists from Yahoo, Interwoven, Reuters, and Netscape filled out the group.

A fly that night, buzzing over the fine wine and exquisite food, would have heard the conversation flit from topic to topic. Here are some snippets:

We spoke about the role of the CTO:

• “CTO’s are about strategy, tactics, and technology”
• “I’m the guy who finds the next boulder and blows it up”
• “’Meta’ness is the responsibility of a CTO”
• “The CTO was created to answer the question: How does a founder maintain his relevance?”
• “Somebody has to be there in the crows nest above everyone looking out farther on the horizon. It may only give you a couple of feet more vision, but in today’s competitive environment that may be enough.
• “The CTO has to be the biggest cheerleader in the company.”

We spoke about how the CTO fits in an the organization:

• “The acid test for a CTO is that he should have nobody reporting to him but he should be able to get anyone to do what he wants.” (Such a structure is more common to Silicon Valley companies focused on products than to the rest of corporate America, where CTOs may have large staffs.)
• “At a big company, everyone can say no but nobody can say yes.”
• “In academia, you get one shot and you turn it in. In commercial software the first release is just the beginning. You get to turn it in again and again.”

We spoke about the common mistakes:

• “The most common mistake is drinking your own Kool-aid, being captivated by the vision not the customer.”
• “The perfect is the enemy of the good.”
• “Lots of people have come up with innovative technology. It’s using technology for useful and pragmatic solutions that counts.”
• “I don’t know how many new ideas have been had since John Von Neumann.”
• “It is your obligation to make side bets. You are not doing right by your investors if you don’t.”
• “How do you downgrade the ambition of the technology and connect it to where the market is at and especially to where the business model is at.”

And, we spoke about the personality of the CTO:

• “CTO’s are obsessed rather than focused. I always find that I am too far ahead. Keeping the obsession allows people to catch up.”
• “A good CTO has the attention span of a crack baby. ADD is rampant in the industry.”
• “A lot of us are good at technology. It is the other things that make you an all star.”
• “People express their humanity in their work. The technology is me.”
• “The CTO must be pissed off that the competition has an innovation that is better than yours.”

We left the Wine Hold room that evening having filled it with the biggest thoughts we could muster. We felt giddy and well fed. As we walked out through the soft light glowing from the orbs on the walls and ceiling, it felt great to be a CTO and a time when technology mattered more than ever.

In the midst of the retro science fiction surroundings, it was easy to slide into the heroic fantasy that afflicts most technologists. We were adventurers, explorers, superheroes even, using our strange powers to change the world. The glow would last until we fell asleep or thought about how hard it would be to get a raise.

But the next day, when we showed up at our desks, cracked open our first coffee, and set to our email, it was back to the real world. The rest of this chapter aims to explain the real world of the CTO so we can understand the everyday life from which those big thoughts sprang.

What Does a CTO Do?

The first CTOs were technologists who founded companies. They gave the title to themselves. They were not going to be the CEO, but they had to be big shots. Chief Technology Officer, that’s it. The CTO title represents the rising power of the technologist.

The first CTOs appeared in Silicon Valley companies. Then the title spread to almost every industry. Before CTO, there were VPs of Technology, VPs of Management Information Systems and other such titles with diverse meanings. As attracting technology talent became more important, companies handed out the CTO title more liberally. In 1980, General Motors did not have a CTO. It now has 5 CTOs at the corporate level and more than thirty in the operating companies.

There is no common definition of a CTO. At Infoworld’s CTO Forum, the premiere gathering of CTOs, or Java One, Sun’s annual convention of technologists of all kinds, the attendees are all over the map. You will find the CTO of General Motors speaking with the CTO of Joe’s Software company, who has a staff of one, who is named Joe. Obviously, these two people have vastly different jobs. One has a suit, the other a ponytail. But both have justification to be called CTO, and perhaps, both are unified by the following description:

The CTO’s core function is creating business value from investments in technology.

This is a prescription perhaps more than a definition and will fit some folks who call themselves CTO and will horrify others. We think this definition captures the essence of the CTO across all environments. We hope that the CTO described in this book is an effective proxy for all those who struggle with technology.

This definition describes results. To complete it, we need to define the CTO’s specific responsibilities and the resources he controls. What does the CTO do to create that business value? Who does he work with? What is the playbook for the different tasks that make up the job? What are the stages in his career development? This chapter will answer all of those questions.

For the purposes of this book, the CTO has a lot of responsibility across the three pyramids a technologist can climb: Architecture, Engineering, and Product. Our definition of the CTO takes all of the fun stuff away from the CIO – we’ll explain what a CIO does later – absorbs the chief architect and VP of Engineering jobs, and grabs the vision away from product marketing. We are broad with our definition so we can discuss in succeeding chapters all of the issues from the most managerial to the most technical.

In the architect role the CTO is the hands-on technologist. By architecture we mean two things. First, the fundamental decisions that dramatically shape what is possible in the future. When building a system or a software product the some of the choices are: Which kind of a database will be used? Which operating system will be used? Which computer languages will be used? Which commercial products are part of the solution? Which functions will be performed by partners? The second part of architecture is design, which sets forth how the programs will be organized. How will systems and groups of systems work together? This sort of design describes the equivalent of DNA, the basic parts from which a larger system is built.

The VP of Engineering role is a management job that oversees the development process. He is responsible for building the technology, for designing and directing the process of rendering the specifications into a working system. The VP of Engineering leads a team of programmers, project managers, designers, testers and makes something work. The VP of engineering often leads the process of putting that technology it in the hands of the rest of the company.

We define the pure CTO job as understanding the customer, the market, and the technology environment and creating the vision for the features of a product or system. In many ways, the pure CTO role is a product marketing function. The plan for the evolution of the product is usually called the roadmap or vision.

At a product company the vision will explain how the features will evolve and what new features will be added. At a technology consuming company, a company that uses technology but does not sell it as a product, the CTO is concerned with the architecture that is in place to support the value machine that is the core of the business. The CTO helps to define a roadmap of incremental steps that gradually move the current systems closer to the optimal state. The plan will vary based on the type of company. At a large enterprise, the vision may extend over years or decades. At a smaller company, the scope may only contain what will be done this year. The CTO must be the central point, coordinating that vision with the rest of the company.

In addition to these roles, the CTO must also be part analyst and part advocate. As analyst, the CTO must look at trends current technology environment, then forecast and adapt. There is always something new that must be addressed. In 2002, Web Services is currently under widespread consideration. Should a company’s product support web services. If so, when? Should a company only buy products that plan to support web services? Can the trend be ignored for a while? Will it go away of its own accord? What is the risk of being a slow adopter? The CTO needs to call balls and strikes.

As advocate, the CTO’s responsibility is leadership for his industry. The CTO should be a salesman for the industry’s products or services, as well as a force for initiatives such as standards or improvements in relevant government policy. The CTO should anticipate how changes in the technology environment affect the industry as a whole and help plan and coordinate the response.

If the company is large enough, it is possible to also influence the evolution of the technology environment itself. If the CTO of GM gets interested in a standards issue or the evolution of a certain product area, vendors are going to take notice. GM wants a better world in which its complex supply chain can operate effectively without integrating with a multiplicity of incompatible system that resulted from unresolved vendor debates. This task of influencing the tech environment is only relevant to the CTOs of the largest companies. When Joe’s software company advocates on such issues, not a lot of calls are returned.

CTO versus CIO

CIO stands for Chief Information Officer. The CIO is more of a senior management mindset than our definition of a CTO. The CIO has the MBA. The CTO has the master’s degree or PHD in technology.

The CIO is a portfolio manager looking at all of the money being spent on technology and trying to optimize the return on that investment. The CIO is operational in focus, concerned with integration, and less worried about development. He is someone who buys rather than builds.

Both the CIO and the CTO are worried about architecture, but in our world the CIO is focused on gradual improvements while the CTO is looking at the broader vision and making large leaps forward. The CIO is about today. The CTO is about tomorrow.

At large companies that are technology consumers, the CTO frequently reports to the CIO. The larger the company, the more likely this is the case. At smaller companies and especially those where technology is the product, the CTO is more the center of the company and the CIO may report to him. This situation is found at startups where the CTO hires a CIO because he is tired of having to take care of the office network, the email servers, the accounting package, and other problems.

Many CIOs would claim much of what we have assigned to the CTO for themselves. I say to them, “Write your own book and define the CTO into small boring box.”

The rest of this chapter is designed to put all readers on the same playing field by providing some basic information about the world in which CTOs live. Technologists will find that the material covers some familiar territory, but will at least find a clear description of what we mean when we refer to jobs like product manager or quality assurance. Those who have not lived through building a system or two will find a new world.

How Does the CTO Role Change at Different Companies?

The size and nature of a company has a profound effect on how a CTO spends his time.

In Part 3 of the book we profile CTOs in different types of companies to show how talented CTOs handle each situation. Here we will survey the contexts in which most CTOs find themselves so we can refer to the different types of situations when we analyze the growth of a CTO.

The day-to-day reality of the CTO job has many dimensions. Is the company focused on a product or a service. Is the product technology itself? How important is the technology environment? How many vendors are in the mix? How many hats is the CTO wearing? To whom does he report? How big is the staff? What is his relation to other executives and the board? How central is the CTO function in the company?

Startup

At a startup, a CTO is an evangelist and a guerilla leader. He concerned with understanding the customer and product vision, and then obtaining financing and building a team that can support rapid growth. The CTO infuses his team with religion – a deep understanding of the customer and product – so they can make the right decisions as they rush to build the product. The CTO is the head sales engineer who tags along on sales calls with the CEO, who is head salesman. The CTO of a startup does many jobs himself at the beginning, and then hives them off as the company grows. The startup CTO wants to pick a spot ahead of the current technology environment to position his product. The startup CTO is frequently the main evangelist for the company’s product area or industry.

Medium-sized Company

The CTO at a small or medium-sized company is a technology everyman, like Barney, the character who did all the technical work on Mission Impossible, or those supply magicians in army movies who arrive smiling, riding on top of the crucial shipment of ammunition. At smaller companies, the CTO wears many hats and may not play as senior of a role as the startup CTO in setting business strategy. He generally merges CIO, CTO, VP Engineering, and Chief Software Architect into one job. He only goes on larger sales calls or many not go on any. He doesn’t have to worry as much about financing. He probably takes care of the office desktops, phones, network, email, and accounting systems. The technology environment is analyzed to reduce risk. The small and medium-sized company that is a technology consumer does not want to be too far ahead of the curve. The CTO at such a company may rely heavily on vendors.

Large Company

In a large company the CTO role can vary widely in seniority and responsibility. The CTO can be like a judge or a senator, finding the right path in the face of powerful interests. It is hard to generalize, but for discussion’s sake we can make some calls. The large company CTO frequently works for the CIO with a smallish staff. Policy rather than specific development is his concern. He must manage and reconcile the competing needs of the diverse departments in the company, many of which do not like being told what to do. A large company has one of everything so all vendors are competing for more attention and must be managed. The vendors are likely sending messages directly to the senior executives of the company, and the CTO must keep them informed. The large company CTO is more outwardly focused on industry and technology environment issues than CTOs at other companies. The large company CTO is less involved in designing and building systems than in setting standards for those who do.

Product Company

In a software product company the CTO is the star of the show. The software product CTO is at the center of the company’s activities and is frequently a founder. He reports to the CEO most of the time and is a regular feature at board meetings. He is focused primarily on understanding the customer and crafting a vision for how the product is moving forward. The CTO is carving out the space to which the product will move, reconciling the vision with changes in the technology environment and forces affecting the industry of the customers. The vision for the product is generally two or three steps ahead of the current release of the product. The software product CTO is also on the lookout for how competitors will threaten the market and how new approaches may provide the same value as the product in a different way. Software product companies have a product marketing and product management departments that does the hard work of translating the vision into descriptions of features that can be built by the VP of Engineering. The CIO functions at a software product company are hived off as soon as the company grows to any significant size. The CTO at Application Service Providers are similar to those at a product company, except the product is the service offered over the Internet.

Consulting Firm

The product for the consulting firm CTO is the service offering made to customers. A consulting firm sells its expertise and services, which may encompass specific vendor products, industries, or techniques. The consulting firm CTO is primarily focused on how changes in the technology environment and in industries the firm serves will create new opportunities. The consulting firm CTO must decide which skills should be built in the organization and which vendor products must be supported. The consulting firm CTO may also decide to build infrastructure that is made available to jump start client implementations. Perhaps the most important function of the consulting firm CTO is finding and retaining a top-notch staff.

The Cast of Characters

The CTO directs a troupe of technologists with arcane specialties. He orchestrates their expertise with a set of tools and methods to make a machine that creates business value.

The cast of characters on the CTO’s team includes:

Programmers

Programmers are the wizards who create value from technology. They are the mothers of programs, gestating the code first in their brains and then transforming it into software code. They are shock troops, willing to sacrifice themselves, working unending hours to get the job done. Programmers are sometimes called software developers, or developers, or coders. The code that they write is another name for the lines of a computer language that make up a program.

Architects

The most talented programmers become the architects. The architects are the programmers who could write the most code, who had the deepest and widest knowledge of technology, whose brains could organize a problem the quickest. Architects are the high level designers who look at the large-scale structure of the system and decide how to partition a program into major pieces and what each piece will do. Frequently, the CTO is the highest level architect with different architects assigned to major portions of the system.

Project Managers

The programmers and architects are creators, not organizers. They are happiest doing work that is difficult and narrow, rather than taking a wide look at the bigger picture. The project manager is taking that wide look, making sure that each time a programmer declares victory, there is something else for him to do and someone ready to take the completed work to the next stage. Project Managers are the schedule keepers and taskmasters. They keep track of how well everyone is keeping up and they communicate within the department and with other departments.

Designers

The bulk of most technology is usually invisible to the user. It only shows up in the user interface, a small portal that provides a model of what the system does and how to control it. The designers are the ones who boil down the system into understandable chunks and present them to the users so they can interact with the system. Programmers generally create user interface designs that reflect the internal organization of the system. A designer tries to understand how a user thinks about his work and translates that understanding into a user interface that makes sense. User interface designers and graphic designers work together to create the user interface.

Quality Assurance

When a system is declared done by the development team, the quality assurance team sets about trying to destroy it, mercilessly subjecting the system to every kind of testing possible in order to find the weak spots. In a well-run engineering shop, the programmers are testing each part before it is assembled into a whole. The QA team may be helping with some of that. In the ideal world, the QA team creates tests scripts that are linked directly to the specifications of what the system was designed to do. QA Engineers also try to bring the system to its knees through load testing, blasting the system with a huge number of requests to see if how well it behaves.

Operations

Like Scotty in the engine room of the Enterprise on Star Trek, the operations staff is always worried if the systems can take it, and is constantly checking to make sure that servers are running, the network is operating properly, backups are taking place, and that hundreds of other things are happening. Operations staff consists of network experts, system administrators, database administrators, security experts, and many other specialties. The best operations people have a huge complex of programs checking everything and reporting back when errors are found. The operations staff takes care of all of the systems needed to make the company run. Internal operations consists of making sure all of the phones, desktop computers, internal networks, printers, file servers, application servers, databases servers, routers, and telecommunications connections work. External operations consists of managing everything needed to deliver a product or service to the outside world. The operations staff has this message for the development staff, “Don’t you touch my production systems. Don’t you even think about it.”

Product Managers

The CTO has the vision of what will make the customer happy. The product manager turns that vision from a vague and fuzzy notion into a specific set of features. Once the features have been defined, they have to be reviewed to see of they still satisfy the vision and the target customer. During development, the product manager must negotiate with the VP of Engineering about how the features change based on engineering difficulty. The product manager may or may not work on the CTO’s team but is vital to his success. Product marketing, the function responsible for understanding the customers, and product management may be collected together in one group on the marketing staff or somewhere else.

Sales Engineers

It is the salesman’s job to break down the door, get the attention of potential buyers, and get a meeting to present the product. At that meeting, a good salesman knows how to get out of the way quickly when the discussion turns to the technical details. That’s when the sales engineer takes the stage as the ambassador for the technology. The sales engineer may run a demo or write sample programs to show the technology is relevant to the customer’s problem. After the sale, the sales engineer may be the closest person to the technologists using the product and can be a vital conduit of information. Most often, these people report to the sales staff, but they work closely with the technology team.

Support

The rest of the staff for a CTO is made up of various types of assistants, administrators, technical writers, training specialist, technical support for the product, and desktop support. The bigger the company the more support people exist and if they are to be working at full speed, they need to feel that they are part of the technology team, not some janitorial staff. It is the CTO’s job to value them.

With this organization or something like it, the CTO must then move through the playbook to make things happen at his company.

The Dimensions of the CTO Role

The CTO leads the team just described to create the technology a company needs. The cycle of building a system involves a set of cascading processes and complex relationships in the context of running a business. Each time through the cycle the CTO learns a bit more. We will follow the progress of the CTO through these processes as a rookie, a seasoned, master, and evolved CTO in subsequent chapters. Here we introduce the processes, relationships, and business responsibilities to make clear what the job of our idealized CTO entails.

Managing Processes

It should be noted that we describe the process from the point of view of developing software. Most of what we say applies to developing hardware or other technology. We chose software because of the large number of technologists devoted to developing software systems.

Development

The development process is concerned with creating technology. For a product company, this means defining what the product is and then building it. For technology consuming companies, it means defining the systems needed to support the value machine that is at the core of the business.

The development process has four main stages planning, requirements, implementation, and quality assurance.

In the planning stage, the project is given shape. What target is going to be hit? What results would be ideal? What are the time pressures? What are the competitive pressures? What external factors are going to have an influence on the project? All of these questions must be answered. The CTO is generally involved in the high level planning with the rest of the senior management team. The project managers, architects, and team leaders then get together with their business counterparts from the divisions who will use the system or product management team at a product company.

The requirements stage of the process involves defining what the product or system will do. In this phase, features are defined. The way the system will help people playing different roles are laid out. How the system will integrate with other systems is set forth. How will the business processes change when using the new system.

The implementation phase is the phase in which the programmers take the requirements and start writing the code to make the system. In most cases, the implementation phase starts an ongoing dialogue about what the requirements really mean and how they will be constructed.

The final phase of development is quality assurance, in which the testers and users are unleashed on the system to seek out defects. In this stage the quality assurance teams looks at the requirements to determine what each feature of the system is supposed to do. They then create test plans that guide testers through the system and document what correct results are. Users also bang away at the system and try to do their jobs and see if they understand. Usability analysis can be part of quality assurance and can take place after or during implementation.

In different methodologies these phases are handled dramatically different. The waterfall methodology runs straight through these steps. Other methodologies run through them over and over again in short intervals.

Operations

During the operations process the system or product comes to life. It can also come to an untimely death if this stage is not managed well. The operations process consists of deployment, monitoring, improvement and upgrade, and crisis management.

In the deployment stage the users are trained, the system is tested in the production environment. The data is migrated from the previous system if necessary. The system then is put in the hands of the operations staff that runs it. When everything is ready, the system is launched and put into production. Then the system is and watched carefully to see that everything still works.

Once a system is in production, a monitoring process keep track of how well it is running, an improvement and upgrade process starts to operate in which problems and suggestions are collected and then scheduled for incorporation into the system, and finally crises are managed and resolved.

Change and Program Management

Starting with the planning stage, the rest of the company is watching the CTO build and launch systems or direct other transformations. The CTO must make sure that the promised business value is created and that each constituency has reasonable expectations and is informed of progress. The change and program management process involved the long-term evolution of a company’s systems and processes. The CTO is at the nexus of most large-scale change in an organization and must be aware of his central role.

A key aspect of change and program management is providing each executive with the information required to manage their constituencies. The CEO wants to know how soon the results of the system will be showing up. The CFO wants to know how much it will cost. The CTO will spend a significant amount of time make sure that the operating VPs in charge of the departments that will use the systems. These executives are at just as much risk as the CTO and they have to be kept aware of the progress of development, changes in features, and anything that will put success in danger. Once the system is completed the operating VPs will live with it for years and the CTO must keep their minds at ease.

In a product company, the CTO must make sure that the technology department is an effective participant in the pipeline that prepares the company to bring the product to market. Far in advance of the completion of a product, a vast army of marketing, sales, technical support, documentation, and release management staff are preparing for getting the product to market, selling it, and supporting it.

Marketing and Sales

As the CTO grows in his responsibilities he starts to follow the money. The marketing and sales process looms larger in his job, not as a core responsibility, but as a first priority. The CTO starts to study the marketing and sales process to get a better understanding of how the company makes money and how his support of these activities can be improved.

Managing Relationships

The CTO learns to manage all the various relationships, with his team, with his peers, with the CEO, and with customers and suppliers.

Team

The first set of relationships the CTO learns to manage concern the team that works for him. The first challenge is to make the transition from individual contributor to leader and manager. In learning about team dynamics, the CTO finds his legs as a manager and discovers how to organize and direct a group of people.
Peers

Once the CTO gains basic competence his job, he becomes an important resource or barrier to his peers. The CTO then learns how to manage these relationships and how his ability to communicate, collaboration, and manage perceptions is vital to his success.

CEO

At the peak of his game, the CTO is an important part of the senior management team. The CEO relies on the CTO for advice and strategic insight. The CTO learns more about the challenges the CEO faces in running the company in managing the board, the investment community, the press, and relationships with other companies. The CTO must find a way to be a valuable partner with the CEO in helping her succeed.

Customers and Suppliers

As the CTO starts to understand the business as a whole, he starts to suggest ways to use technology to improve relations with the customers and suppliers who support and nurture the business. The CTO looks outside of his business into the infrastructure used by external parties and tries to improve service and gain a competitive advantage by supporting these relationships with technology.

Managing the Business

Business Cycle

Managing the business cycle is the process of anticipating how business conditions are most likely to change and making contingency plans. Like the Federal Reserve announces a bias toward raising or lowering interest rates, the CTO should have a bias in a variety of areas and be making side bets.

Is the company poised for growth or about to contract? Is the CTO likely to be asked to do more development because the demand for technology will increase? Is he likely to be asked to cut his budget because the demand for technology will decrease? What happens if a product really takes off? What happens if a large customer is lost?

Once the CTO has formed an opinion, he should prepare his department for the change. This may involve creating new relationships with consultants to prepare for expanding development capacity or selecting which projects will be cancelled.

He must also look at the effect of the business cycle on his staff. In boom times, staff retention is a big issue. How can the staff be convinced that the company has got a bright future and is a cool place to work? How are stock options positioned as part of compensation? In bad times, how will the department contract and still do its job?

The general stages of a business are as follows:

• Startup, in which resources are available, speed is at a premium, and the race is to demonstrate the functions of the product and get initial customers.
• Initial Expansion, in which the first customers arrive, the rate at which the product improves starts to slow. Operations, product management, and change control are more important, and the pressure on expenses begins.
• Mature Expansion, in which the company now must become a machine for delivering the value that sold the first few customers. Product management is the key discipline because a larger group of customers means that the product must evolve in a disciplined manner. Processes of all sorts must be locked down and staffed so that the business has a chance to grow rapidly without chaos. At this point, experienced managers join the company from the outside. As growth slows, tight controls on expenses will be introduced.
• Maintenance, in which the growth is steady and predictable, the product changes slowly, and expenses on every front must be reduced.
• Contraction, in which the company falls significantly short of its expectations and must shrink its ambitions and its expense base. Staff reductions and a sharp narrowing of focus generally occur.
• Transition, in which a company is being sold and handed to new management or is about to collapse and must fold operations.

Most smaller companies waffle between initial expansion, mature expansion, and contraction. Most large ones cycle between mature expansion, maintenance, and contraction. Everyone hopes to avoid collapse.

Strategy

The CTO can delegate many tasks previously mentioned, but he cannot delegate responsibility for the technology strategy and still call himself a CTO.

Technology strategy is like a specific plan for the next few moves of a chess game. It is a clear definition of the position in which you want to end up. The strategy can be expressed in a set of principles that guide the direction of the company’s technology. The strategy is important to help make choices among alternative tactics.

The strategy must be specific. It is a roadmap to an ideal system, a crystal clear construct that can be shown to achieve the business goal. It must be guided by an understanding for how a company currently operates and how its processes will changes as the technology evolves.

Part of the strategy concerns the plat for the architecture of the technology. The architecture is the structure for how all the systems work together. As time passes, the architecture should allow more flexibility and make changes less costly. The roadmap for the architecture should show how the current systems will gradually morph into the ideal systems. The roadmap should have the stages prioritized so that low risk, high return steps are done first and that any risky steps are taken safely.

The roadmap for the architecture must be informed by the CTO’s forecast for the technology environment. How will the long-term architecture take advantage of new trends? Is it wiser to stick with proven technology and avoid the risk of incorporating new systems? When is the right time to adopt new techniques?

Finally, the strategy must incorporate the pressures on a company’s industry. Is a new era of price competition about to begin? What innovations will mean that new markets will open or that new competition will arrive? How is technology changing the supply chain? The strategy for technology must support the company’s vision for dealing with industry trends.

The Career of the CTO

Now that we have seen the CTO’s team and the playbook he must run, we will examine the stages of the CTO’s career. Our analysis separates the growth of the CTO into four stages, Rookie, Seasoned, Master, and Evolved.

The journey our prototypical CTO starts with naiveté and child-like immaturity. This blissful innocence comes to an end when the faults of the raw persona wreak havoc on a large project. The CTO then begins to discover his faults and then gradually master the raw persona. Finally, the CTO grows in his vision of himself to a more expansive role, which combines all of his strengths as a technologist with a new consciousness as a businessman.

The rookie stage we describe in this book is someone who is very green, perhaps too green to be a CTO. Our rookie is struggling with the transition from running a small team to a large project that is being observed by the rest of the enterprise. Most technologists suffer through this learning before they become a CTO. The rookie is dominated by the raw persona, is new to large-scale project management, and is headed for a fall.

The seasoned stage is transitional. In some ways the seasoned CTO has grown up beyond rookie mistakes. That is certainly true with respect to managing development and keeping check on the worst excesses of the raw persona. But the seasoned CTO is half-baked. His satisfaction with his progress prevents a comprehensive scrutiny of the raw persona’s effect. It’s impossible to learn everything at once, and the seasoned CTO’s learning is focused on the deployment process and managing the enterprise.

The master CTO is a complete CTO the way most people imagine a CTO to be. He is an accomplished manager of development and deployment and glides easily through managing the enterprise. The master CTO has a vision for where he wants to go and communicates that to the rest of the company. The master is learning that his vision is too focused on technology. He is becoming aware that he must expand his mind in order to be more effective.

The evolved CTO has sprouted up from the soil of pure technology. His roots are in technology, but he tilts toward the sunshine of business value. He is a student of other business disciplines and the technology environment. He is an architect not only of technology, but of how the business must change to get the benefit of technology.

This is the shape the rest of our journey in part 1 will take. In the next chapter, we will leap within the crevices of the brain of the technologist to find what is lurking there.

Three Years Later

As this chapter is being written, three years have passed since the expansive dinner at Farallon. The triumphant mood of technologists have given way to despair, as many companies were crushed by the weight of commercial reality.

Most of the dinner guests landed firmly on their feet. Ipivot, Cary Jardin’s firm, was sold to Intel. Earl Rennison’s firm, Perspecta, was purchased by Excite@Home and Earl is now engaged in running another startup. Bob Page and Rick Kreyser took Accrue public. Phil Nelson started another company, Impresse, that rose and fell like a fireworks rocket. Alex Cohen has had three CTO jobs since and is about to take another.

Almost everyone is still at it, struggling to make technology work for his business. Once a CTO always a CTO.

Back to Education of a CTO Table of Contents