Evolved Technologist -

Back to Education of a CTO Table of Contents

Prologue

The story of this book begins in a Wall Street diner. It is December 1998. The dot.com gold rush is in full swing and has spread from Silicon Valley to every metropolis in the country. Every region with technology aspirations is buzzing with newly-funded Internet startups. In New York, we have Silicon Alley.

In the heyday in 1998, if you jump in the sports car you bought with your stock options, and speed south down Broadway through the heart of Silicon Alley, you will pass all of the “new media” businesses that were aiming for world domination. Pseudo.com is a video business seeking to uproot the TV networks. Razorfish is after the ad agencies. DoubleClick created the online ad business. StarMedia wants to be the Spanish-language Yahoo.

Get that car into third gear and race past Canal street, slow down past city hall and nod to the Brooklyn Bridge, the high tech wonder of its day. Step on the gas and you will quickly find yourself at Wall Street. If you stop there you can look to your left down the length of Wall Street, and imagine that the wall to keep the natives at bay is still there. Dominating the coverage of this territory is what we are after at TheStreet.com.

Peel out for effect and turn right on Rector Street just past Trinity Church. You will pass Alexander Hamilton in the graveyard, and a monument to Robert Fulton, the inventor of the steam engine. Cross Trinity Place, and on your left you will arrive at George’s Diner. Park the car and walk in. It is about 2:00pm and you will find me sitting at a Formica table, staring blankly at the sugar canister.

At that time, the last week of 1998, I am CTO of TheStreet.com. We are trying to conquer the Wall Street Journal by using the Internet to publish stories about the investment world and selling subscriptions. Our CEO, Kevin English, has a headline printed up to that effect. Our Editor, Dave Kansas, is a long time WSJ reporter who would love to stick a thumb in the eye of his old employer. Our venture capitalists, Fred Wilson and Jerry Colonna of Flatiron Partners, New York’s premiere Internet fund, would love to make yet another killing. The founders, Jim Cramer and Marty Peretz, are the visionaries who put their own cash for almost two years. They want all of this to happen.

The whole company, the whole world, is in a massive rush. I first met the company on Tuesday. I had an offer by Thursday. I agreed to join in April, 1998, just as the Flatiron guys were about to close their $6 million investment in the company, their share of a $10 million round. They were the first outside investors, and by then were accomplished at executing the Internet startup playbook, which goes like this: First, get in early, and bet on good ideas and good people. Add money, management expertise, and technology to make the garage band into a business. Bring in more VC money at a much higher valuation to help things grow, and then, when the investment bankers say they can pull it off, take the company public.

The capital markets since the Netscape IPO in August, 1995 have been blinking on and off like a stop light. The light goes green, and anything can go public. The light turns yellow, good ideas can make it out. Two or three times the light has gone red and most IPO activity has stopped.

In December 1998, we are at the stage when Flatiron has just managed to bring in another $25 million bucks in a round led by Oak Investments, one of the oldest VC firms in the country. As it turns out, the capital markets are glowing so brightly green that by the end of January, TheStreet.com will be picking investment bankers and preparing for an IPO that will happen in May. The frenzy is such that the New York Times does a deal to create a joint newsroom with TheStreet.com. Fox creates a television show for us.

My part in all of this is to get the technology in order. Cramer’s Harvard classmate, Tom Phillips, founding publisher of Spy Magazine, is now one of the top guys at Starwave, along with Mike Slade, who helped Microsoft’s Excel spreadsheet program crush Lotus 123, and Patrick Naughtin, who left the Sun Microsystems Java development team just before it got very hot. Starwave is a Paul Allen funded startup. Paul Allen and Bill Gates founded Microsoft and Allen is the second largest shareholder behind Gates. He left active participation in Microsoft sometime in the 1980s while battling a health problem. He got better and is rich enough to buy the Seattle Supersonics. His Vulcan Ventures fund puts lots of money into startups that have a sort of academic feel to them. They are chock full of smart people, good ideas, and innovative technology, but they seem carefree about sales, customers, and revenues.

Starwave is the typical Allen startup. It started as CD-ROM development company, wandered about a bit doing celebrity CD-ROMs, and then get a contract with ABC to do the web site for ESPN. For a fleeting moment, Starwave fancies itself as an infrastructure software company and decides to sell the technology it built to support its sites. During this interlude, before Disney arrives as an investor and makes the company more businesslike, TheStreet.com strikes a sweetheart deal in which Starwave provides web hosting, ecommerce for subscription sales, and content management services in exchange for TheStreet.com’s content, which is delivered to ABC news.

This all sounds great, except that after Disney invests in Starwave, they decide that it’s a bad idea to sell these systems to other companies and the effort is abandoned. TheStreet.com is now left as the only external client of Starwave, and one that isn’t paying any money for its services. Imagine how responsive Starwave is to this relationship. Somehow, they don’t feel as grateful for the daily stream of stories as we at TheStreet.com had hoped.

I arrive to sort this mess out. My mission is to bring the web hosting, content management system, and subscription services in house. On May 8th, my first day, I start with Gregg Bishop, an eager young technology generalist who manages the relationship with Starwave, the desktop computers, the network connections, and pretty much everything else in technology. Gregg is 6 feet 5 inches and is as thin as a rail. He is from Grenada, and is cousin to Maurice Bishop, whose murder spurred Ronald Reagan to invade the island. Gregg has a couple of junior system administrators working for him. This is all there is to the technology staff.

Between May 8th, 1998 and the last week of the year, I run the dot.com CTO playbook. I hire a team of 14. We evaluate and select vendors. We engage consultants. We set up a new data center for web hosting. Most of all, we program, program, program, to all hours of the night. Things are so pressurized that after my mother-in-law dies on Christmas Eve, I work Christmas day.

I am sitting in the diner staring blankly at the sugar because I am at the end of my rope. We had planned to launch on December 27th, but the systems weren’t ready and an obscure DNS error prevented AOL from picking up the location of our new servers. As the week wears on we figure out that the DNS problem will take about three days to fix. I have just realized this. Up to now we had been thinking that we would launch on the 28th, then the 29th, then the 30th. Now it looks like it will be January 3rd.

When I do something well, when I am celebrating, when I have a victory under my belt, I go to the diner and eat the cheeseburger of victory. That cold December day in the afternoon in an empty diner, I am forced to see the world as it is, not as I would wish it to be. I must eat the cheeseburger of defeat.

It is at that moment that this book, the Education of a CTO, began to take shape. As I looked back on my career, I started to see patterns of mistakes. Neither I nor any of my colleagues were able to estimate how long a project would take. We were poor communicators. We worried too much about technology and not enough about business.

After a couple more years of mistakes and growth, I discovered the cause of these problems, a set of personality traits. I also found methods to overcome these traits. I then created and applied a vision of what a technologist should do. This book is the story of my discovery.

Why a Book About the CTO?

CTO stands for Chief Technology Officer, but the acronym represents far more than a title. The power and allure of technology, the struggle to make a better mousetrap, the overwhelming complexity of the modern world, the clash of engineering and business culture are all contained within the concept of the CTO.

The CTO is a vital player in the corporate world. Once the CEO of a company decides on a plan and the Chief Financial Officer arranges the money, the next ingredient is technology. A company can hardly move a step in any direction without bumping into a technology issue.

But what kind of technology does a company need? Will the company buy it or build it? If the product is a technology itself, what should it do? How will it all fit together? How long will it take? How much will it cost? How will it create value? All of these questions, especially the last one, are the CTO’s to answer.

To answer these questions, the CTO creates a vision for putting technology to work and then leads the effort to fulfill it. The struggle for the modern CTO is concocting that vision within the limitations of the current systems, the organization’s ability to change its behavior, and the available resources for development.

Part 1 of this book aims to explain the most common mistakes CTOs make and how to avoid them. The approach is unique. Instead of looking at processes and methods, we analyze the personality and self-image of the CTO.

We examine the raw technology persona found in most technologists. What forces pull at a CTO as he grows in experience and skill from rookie to master? What lessons does he learn along the way? What are the most common traps and why do CTOs fall into them over and over again? How can The Education of a CTO, the title of this book, be accelerated?

But this book does not stop with the master CTO, who meets typical expectations for technology executives. We will also present the larger role of the evolved technologist, a vision for making the CTO better at crafting technology solutions. This new role demands that the CTO study the rest of the business. Part 2 provides a view inside other departments from the CTO’s perspective. By looking at the relationship between the CTO and the executive in charge of each function, we tour through marketing, sales, finance, law and other fields to provide the basic information the evolved technologist needs.

Part 3 contains profiles of successful CTOs in different contexts. We show how Tony Scott, CTO of General Motors acts as an evolved technologist in a large corporation. Howard Shao of Documentum illustrates how he applies evolved principles in a software product company. Phil Nelson, founder of Verity and Impresse, tells how he goes about building companies as a startup CTO, including his tale of finding funding after one meeting. Other CTOs show how evolved technologists act in consulting firms and high performance operational environments.

Part 4 examines the implications of improved CTO performance and the effect that evolved technologists could have on the rest of society if evolved technologists played larger roles in corporate governance and government.

If you want to become a CTO or become a better one, if you are an executive of any sort who wants to improve your skills at designing and implementing technology solutions, if you want to work more effectively with the technologists at your company, this book is for you.

Is There a Crisis in Technology Management?

The promise of technology never stops generating excitement. The struggle to fulfill that promise delivers an equal measure of frustration.

The promise is fueled by results. Over and over again, winning companies demonstrate that a clear vision for synchronizing business processes and technology can achieve stunning performance. The challenge for technology executives is making effective use of technology to produce business value. Getting it right can make the difference between life and death for a company.

Creating a coherent technology vision is a difficult task with many complex forces in play. The technology environment is fiendishly complex. Every level of the interconnected stack of application software, databases, and networks is rich in detail. New developments add layers to the technology environment that multiply possibilities. Change occurs at an accelerating pace.

Business conditions shape and reshape the problem. In boom times, the technology environment at a company grows out of control as CTOs try to slap together systems to react to new opportunities. In a bust, a company enters a period of technology digestion, in which the systems are pruned and rationalized.

The bureaucracy at most companies offers more challenges. Misunderstanding of what technology can do, adapting business processes to make new systems work, and political battles all provide barriers to the CTO.

The CTO has been invited into the boardroom because the significance of technology tactics is immense. A winning corporate strategy can hardly be formed anymore without a detailed understanding of the technology landscape. CTOs and senior executives face their current maze of systems, the possibilities present in the rapidly advancing technology environment, their competitive situation, and must construct a plan out of a mind-numbing set of alternatives.

In the ideal world, the CTO and the senior management team work hand in glove, educating each other and producing a solution sensitive to both technology and business issues. But how often does this happen?

This ideal relationship is seldom achieved. Without it developing technology solutions is painful and frustrating. Answers to the following questions can help indicate if problems in technology management exist at a company:

• Are technology projects over budget and behind schedule?
• Do systems fail to achieve their promised value?
• Is implementing technology a bottleneck to progress and growth at your company?
• Are technology systems deployed without proper synchronization with business processes?
• Are unrealistic hopes tied to the arrival of new technology?
• Is development of new technology a significant drain on the operations of the company?
• Are significant sums wasted on technology or consulting that does not produce business value?

At most companies the answer to many or all of these questions is yes.

What is the crisis in technology management? It is that companies do not learn from their mistakes. After failures relations between the business and technology staff get worse. How and why this happens and what to do about it is the main subject of this book. We summarize our solution later in this chapter. But before we proceed lets look at the shape of the crisis.

Well-managed companies get major projects done without strife. There is no crisis if at a project’s end the performance of the business and technology development team improves and relationships are strengthened. This is not the case most of the time. The more questions above are answered yes at a company, the more likely the following scenario will ring true.

At the beginning of a new project, or after the arrival of a new management team, everyone starts with good intentions. The business side has important problems to solve. The technology department really wants to help.

The typical project begins in a rush of optimism. The business side explains what it needs to solve the problem, the ideal system is described, and then the technology department sets about to build it. Along the way, the system changes shape and takes longer than expected to build. Costs rise. Less is delivered than promised. Frequently the systems created are useless to the business side. Everyone worked hard but nobody got what they wanted.

What happens after a failure? The business side throws up its hands and says “You technology guys don’t understand what we want!” The technology guys yell back, “But you don’t understand what we can do!” The CEO looks at all of this and gets depressed. Everyone wants to do better, but the way forward is very difficult to find.

Generally, the next step is that walls of mistrust go up and the technology and business sides face each other as two armed camps. When projects start from the armed camp perspective, success is rare.

When the business side sees technology as a fixed appliance, as refrigerator or microwave oven, a dangerous barrier has formed. This means that the technology department has become an opaque service that is not involved in framing the way that technology is applied and the chances for success drop dramatically.

The armed camp mentality on the technology side can reduce the CTO to a negative role, vetoing every project that has even the smallest amount of risk. The essence of this behavior is that expectations are reduced to zero, so that any forward progress, however slight, is seen as a blessing.

The Dilbert Problem

Perhaps the most profound evidence of a technology management crisis is the popularity of Dilbert™, a cartoon world in which the armed camp mentality rules. Engineers see themselves as drones commanded by idiot managers.

Dilbert amuses us with his despair and wallows in his powerless stature. Dilbert may know how to improve his company’s performance, but he would never propose a solution. He has given up the will to fight. Whether you look on Dilbert as ironic commentary or as representative of the state of affairs, the popularity of such a defeated character is not a good sign.

The Dilbert cartoons that plaster cubicle walls across the United States are badges of failure. Like Dilbert, too many technologists have given up the struggle to fully contribute to the success of their companies. This is a crisis that calls for action.

It is a crime to accept an armed camp mentality. In the current post-gold-rush environment, companies are retooling their hastily built web architectures and streamlining systems that have been in use for years. Business and technology cooperation is more vital than ever. The CTO has a crucial role as the person who can envision an integrated architecture to support a business and then lead the company to achieve it.

With all of the opportunity present in today’s business environment, the CTO should be a hero. Instead the modern CTO is too often a hero who failed.

Methodology as a Solution

Bad news about the difficulty of managing technology development is not new. It has been this way for decades and a massive amount of research and effort has gone into finding ways to increase the return on technology investment. In order to understand the solution we propose, it is important to show why it is different from previous attempts, most of which take the form of methodology, which we argue only addresses part of the problem.

Technologists are methodology crazed. Part of this stems from the nature of programming, in which algorithms are designed to handle every possible situation. Methodologies try to organize a problem and create a universal playbook that will help avoid problems.

Historically, the most popular methodology, which has been taught in engineering schools for years, is called the waterfall methodology. The waterfall is a natural organization of a project into a planning phase, a requirements phase, design, and implementation. The waterfall methodology does not work very well for a variety of reasons that are widely documented. The largest problem is that the waterfall methodology does not have a feedback loop in the system is improved based on experience. It frequently turns out that until a system is in the hands of the users the requirements are not fully understood.

Much of the work on methodology over the past 20 years, starts by discrediting the waterfall technique. But although methodologists agree on the failure of the waterfall, they suggest a wide variety of solutions. There are methodologies aimed at all levels of the technology management process.

Extreme Programming and Scrum, are two agile development methods designed to improve team performance. In Extreme Programming, the focus is engineering quality. A set of practices such as writing tests before writing code, “test first programming,” and working in pairs, “pair programming,” and working in close quarters in a common room increases quality and productivity. Other practices are aimed at clearly stating requirements, avoiding unnecessary work, and putting and end to the heroic all-nighters that are too common. Kent Beck, the creator of Extreme Programming, says that the key result of the methodology is a sense that everyone has enough time to do his job.

Scrum is a management practice designed to improve productivity by establishing a set of rules governing the interaction between management and developers that encourage focus and remove distractions and barriers. In a Scrum project, work happens in 30-day sprints. The work done in a sprint is selected from a backlog that is put in priority order by management. The backlog is list of all the tasks, bugs, or proposed changes for a program. The goal of each sprint is to deliver software ready for production. A scrum master removes barriers to progress but the team itself decides how to get the job done. In a daily 15-minute meeting, each participant on the team tells what he did in the last 24 hours, what he will do in the next 24, and what is getting in his way. The sprint cannot be interrupted with new tasks or changes from the outside. At the end of the sprint, the results are assessed, the product backlog is adjusted, and a new sprint begins.

The Rational Unified Process is an elaborate methodology that is focused more on managing complexity than on productivity. RUP presents a multitude of “artifacts” to choose from, including many of the features of XP and Scrum such as iterative development. The unified process has four phases, inception, elaboration, construction, and transition. Within each is a set of step to bring a project to completion. RUP is a rich in detail about every stage of a project. It provides a framework for knowing where you are in each stage of the processes in a complex project. It provides built in controls for managing consecutive steps. It is best thought of as a universal playbook that provides recommendations and techniques to apply to the various stages of project. While RUP represents a substantial body of knowledge about project management, its leading practitioners insist that it can be as lightweight and agile. It is a very tunable methodology that can be adjusted to focus on the strengths and weaknesses of your organization. But even its proponents recommend that the effort of using RUP pays off much more heavily in large projects measured that take over a year or more from beginning to end.

All of the methodologies mentioned so far are designed to help make projects work better. Computer scientists are so methodology-crazed that they have created standards for methodologies.

Capability Maturity Model is system for evaluating the processes at a software development organization created at the Software Engineering Institute at Carnegie Mellon University. Five levels exist in the hierarchy, each of which set forth key process areas (KPAs) that must be successfully implemented for an organization to be certified by CMM auditors as having achieved that level. Level 1 is ad hoc uses of processes sometimes called heroics. Level 2 represents repeatable processes for project management at the team level. Level 3 means defined processes for the organization. Level 4 consists of managing processes so that quantitative measures can be tracked. Level 5 is about using the quantitative information to optimize the processes.

ISO 9001 is a general standard for providing service that has been interpreted for software development through some further ISO specifications. ISO 9001 for software development has 20 “clauses” that set forth standards for how an entire organization operates and has specific requirements for various processes such as development planning, requirements specification, configuration management, and document control. If a company wants ISO 9001 certification, they must first develop their own quality management processes and then they can obtain certification by a third party that their processes meet the ISO 9001 standards.

This is just a sample of some of the most celebrated methodologies. There are hundreds of others. Many companies have developed their own.

William Penn, the founder of Pennsylvania, said that “there is hardly one frame of government in the world so ill designed by its first founders that in good hands would not do well enough…. Governments, like clocks, go from the motion men give them, and as governments are made and moved by men, so by them they are ruined too. … Let men be good, and the government cannot be bad; if it be ill, they will cure it. But if men be bad, let the government be never so good, they will endeavor to warp and spoil to their turn.”

Methodology is no substitute for good people. Methodology does not provide vision and leadership. Methodology does not pick the right targets. Methodology is a way to reduce risk of executing a strategy, not a recipe for finding a better one. The problem with methodology as a solution to improving executive performance is that it does not help the technologist in important arenas outside the scope of the methodology.

Methodology is focused on the work of the development process. Many of the practices of a good methodology serve to improve relations between the technology department and other parts of the company because the work and interactions are better organized. But there is a huge amount of interaction between the CTO, the rest of the company, vendors, and investors that is not affected by methodology. In these areas, the personality of the typical technologist, their own view of their role, and the training they receive in their career can be a severe liability. Methodology will help if diligently applied, but it doesn’t save the technologist from his own nature.

What does methodology say about how to manage politics in an organization? What does it say about how to craft a budget? What does is say about how to deal with a request for a raise? This book is about advice and methods of thinking that apply across all methodologies. This book is an attempt to explain what people learn from experience.

The argument of this book is not that methodology is not important or should be ignored. But just like William Penn, we argue that the technology management crisis will not be solved by better methodology but by better people. It is time for CTOs to focus on becoming better executives by increasing their understanding of their weaknesses, adopting a new view for their role in the enterprise and preparing to play it.

The Program for Improving CTO Performance

From that moment in the diner, as I ate the cheeseburger of defeat, a process of discovery began.

My career has many nooks and crannies, diversions and byways. When I took the CTO job at TheStreet.com it was the first time I hadn’t changed careers or cities or both as I moved from job to job. I looked back on what happened at each job along the way.

After graduating in 1982 with a BA in Computer Science from The University of Michigan, my career started in the stifling halls of a utility company, where I learned to be a software mechanic for IBM mainframes. I moved rapid fire through jobs at a manufacturing firm, a firm that created pension plan software, and a firm that sold financial analysis software to Wall Street. Looking back, I can see in all of these jobs and environments the same disconnect between technology and business. In 1988, I was overcome with the obsession to keep learning and took a hiatus into Journalism.

In 1989, I graduated with a MS in Journalism from Columbia University. While in J-School I joined Elliot Jaspin, a Pulitzer Prize-winning reporter, to help him create a program to help investigative journalists. I kept my hand in technology through three years covering banking during the Savings & Loan crisis at The Bergen Record and then worked searching for stories in electronic records at The Raleigh News and Observer. In my three years there, I started building systems, first for the newsroom and then for Nando.net in 1994, one of the first newspaper web sites. It is clear now how the traits that affected me as a technologist, also caused turmoil as a journalist.

I returned to New York in 1995 as a technologist to work on Pathfinder, Time Inc.’s grand experiment with new media, a massive umbrella web site for all of its magazines. I built a team to create applications to let users interact with content and saw how the excitement about technology obscured any rational business purpose. All of the companies in the Internet race, Netscape and Microsoft especially, wanted to use Time Inc. content and brands to showcase their technology. Bill Gates promoted his book, The Road Ahead, in a presentation in our conference room. We sold a personalized newspaper to CompuServe for $10 million. We created the first web sites for RoadRunner, the cable modem company. We learned to handle the crush of traffic when our site published the Sports Illustrated swimsuit cover a day before print distribution.

In 1998, I joined TheStreet.com, built the team and new systems, and found myself eating the cheeseburger of defeat at yearend. We supported the company going public in May 1999, launched a new e-commerce system for subscriptions, and then by September I jumped ship to help Charles Ferguson and Heather Shively start CapitalThinking. In 1994, Charles had started a company that created the FrontPage web-authoring tool and sold it to Microsoft in 1996. Heather was an investment banker and fund manager who was managing a $3 billion portfolio of real estate stocks and had a vision for a technology-based revolution in the commercial real estate industry. As founding CTO, I ran the CTO playbook once again and created the technology that allowed the company to be one of the very few to find its way from a dot.com startup to a successful business. It was during this period, that I matured most rapidly as a CTO.

Through this experience, the predicament of the CTO became clear. I saw the problems that CTOs cause themselves, the problems that they face in their companies, and how their jobs are ill-defined. At most companies, no mentors are at hand to train the CTO.

So, faced with daunting management challenges and methodologies insufficient to solve the problem, what is the way out? If CTO performance has been sub par, what must be done to restore the CTO to hero status?

The program we present in this book is three fold.

• First, the CTO must more fully understand his own personality – the raw technology persona
• Next, the CTO must shift his focus from technology to business value.
• Finally, the CTO must learn about more about each business specialty in order to effectively construct technology solutions.

The raw technology persona is my name for the personality traits found most commonly in technologists. The raw technology persona describes someone who is accommodating, optimistic, mathematical, innocent, creative, and focused. The raw persona is found in people who deeply believe in the power of technology, who love building solutions, who feel that they can do anything they set their mind to, and approach their work with imagination and drive.

These characteristics are present in such abundance that they harm the CTO’s efforts to solve business problems with technology. An accommodating attitude leads to unchecked feature creep. Optimism leads to over promising. The other traits lead to similar problems.

The initial stages of growth of a CTO involve mastering the raw persona. The first part of this book shows how to understand the raw persona and discusses tools and modes of thinking to avoid turning these character strengths into weaknesses. We examine the way that the raw persona affects the rookie CTO, who is ruled by it, the seasoned CTO, who is struggling with it, and the master CTO, who has the raw persona firmly under control.

The second step for growth is adopting new vision for the CTO, the evolved technologist, someone who has stepped beyond a self-image as “the technology guy”. Most technologists rise in their career by saying yes, and then delivering the goods. CTO’s are not encouraged to ask why about a project or task. This leads to inappropriate and ineffective application of technology. Systems are built to solve the wrong problems or without input from those who will use them.

The evolved technologist sees his job as understanding the value machine of a business and all the supporting functions. He then crafts technology solutions that solve problems and create opportunities. The evolved technologist is not the technology guy, but the business value guy who is an expert in technology.

The evolved technologist must know much more than technology. He must know how to reach out and understand the needs of all of the other executives around him, to teach them and learn from them about the specific challenges facing the company in each of their realms. Then, if technology can help, the evolved technologist frames its application.

The evolved technologist must to learn the details of other departments’ operations. Let’s take marketing as an example. How can technology be applied to improve marketing if the CTO does not understand marketing and the marketing executives do not understand what technology can do? The ideal, of course, is that both the CTO and the marketing executive learn more about each other’s domains.

While that should be done from both sides, our argument is that the fastest path to solving the problem is for the CTO to take responsibility for bridging the gap. The world of technology is too arcane and complex to be quickly understood by the marketing executive. While it would be arrogant to assume that a CTO could learn marketing in a snap, it is not absurd to think that a CTO could actually improve his ability to help marketing by learning more about the subject. Once the CTO understands the nature of the discipline, he may be able to understand how to better apply technology. He will be a better teacher and communicator as well.

The goal of Part 2 of the book provides is to take the CTO on a tour through each discipline to provide a primer to accelerate learning. We take a tour of each business domain by examining the relationship between the CTO and executives in charge strategy, finance, marketing, sales, personnel, and law. The goal of Part 3 is to show how the understanding of the raw persona, the vision of the evolved technologist, and business knowledge are combined by evolved CTOs in different sorts of companies.

While this program will not solve every problem in every organization, it will make for a CTO who has a better chance at increasing the ROI on business investment in technology. It also encourages the CTO to take responsibility for his growth instead of stewing in a Dilbertian state of depression, moping about, expecting the worst, and doing nothing about it.

In the next chapter, we examine the role of the CTO in detail to lay the groundwork for a detailed discussion of how a CTO grows from rookie to master to the evolved technologist.

CTO: He or She?

One note on language from the author: In writing this book, I had to make a choice about how to refer to a CTO. Is a CTO a “he” or a “she”? I chose the pronoun “he” when talking about the actions of a CTO or technologist. I personally find it a bit confusing to switch back and forth throughout the text, as some authors do, or to always use a plural form.

Many CTOs are women, and my use of “he” for convenience is not meant to suggest otherwise. Neither is the male figure used in some of the illustrations. What I have found in my experience is that the problems that technologists suffer from seem to transcend sex and afflict men and women alike.

When referring to executives, I had to make a choice as well, and I chose “she.” In honor of all of the women I have worked for, I have made all of the senior management characters in this book female. CEOs are she. CFOs are she. VPs are she.

Back to Education of a CTO Table of Contents