It is fair to say that, given you are reading this book, you already have a good idea of what a Chief Technology Officer (CTO) is. Yet, if all readers were to be polled on their definition of a CTO, we would get as many different perspectives as there are readers. Each description, though, is most likely right. This huge variety in interpretation is what makes this role not only challenging but exciting at the same time.
The closest counterparts, Chief Executive Officer (CEO) and Chief Financial Officer (CFO), are well-defined roles, with their areas of responsibility clearly understood: the CEO leads the charge, and the CFO writes the checks! Okay, a little disingenuous, but the point is, these roles are universally accepted, compared to the ambiguity around the CTO role.
For example, the dropdown list of job titles in online forms often lacks “Chief Technology Officer.” Though this is changing—specifically in the field of insurance where CTO has started appearing in job title lists—are CTOs considered a higher insurance risk?
The CTO definition gets morphed and pulled, depending on the organization, with responsibilities ranging dramatically from company to company. At a high level, the CTO is responsible for the technology vision and execution of a company, though some companies don’t even consider the CTO responsible for execution. It’s not unusual for some large organizations to have a CTO with no one reporting to them. For this book, however, the assumption is that the CTO is responsible for both areas: vision and execution.
The different broad types of CTO will be presented so you can see which one you best identify/align with. This will help you position and firm up your goals for a successful career. As part of this, the qualities that define successful CTOs will be highlighted.
The remaining chapters will take a deeper dive into the key areas that the vast majority of CTOs will find themselves navigating at some point. Although not all chapters may be relevant to you, the area in question will be the responsibility of someone and that person will be your peer, so it is never a bad idea to get a feel for what they will be contending with.
At the highest level, the CTO is primarily responsible for the technical direction and execution of the company’s main product, servicing the needs of the business for greater client benefit. The CTO usually reports to the CEO, but it is not uncommon for them to report to the CFO, COO (Chief Operating Officer), or even CIO (Chief Information Officer), depending on the size of the company and number of direct reports the CEO is comfortable managing.
Conversely, an area that does not typically come under the CTO is the IT infrastructure—in other words, the back office. Although the servers and software that make up your product would fall under the office of the CTO, the desktop computers, mail servers, phones, printers, and so on would not. They would likely fall under a separate IT director or manager, who usually reports to the CFO. Think of the CTO as usually focusing on developing, maintaining, and running the core platform, enterprise, or product line that services clients/customers—sometimes referred to as the front office.
That said, in smaller companies, it is not uncommon for this line to be somewhat blurry, and depending on your skills, you may find yourself managing items that are potentially outside of your primary responsibility. It is common in startups and smaller companies for the CTO to be doing everything, from ordering the laptops, to haggling contracts with the ISP, to replacing printer ink, to cutting and releasing code.
On the other end of the scale, it is common for an established (small to medium) company to operate without a formal CTO. It may have a development team, a support team, and a systems team, but no one is looking after and managing the technical strategy as a holistic initiative. This situation is easy to get into as a company evolves over years, not realizing it is more of a data/technology company than it may care to admit.
There is no fault here as most don’t see how they could benefit from this executive role to unlock some hidden treasures within their operations. Again, if this sounds familiar, then this book will help you make the case to your management that this role needs to be filled.
Just as the CFO provides all financial and accountancy services for a company, making it all look rather seamless and effortless, a good CTO frees up the CEO and board to concentrate on the what aspect of a company, whereas the CTO focuses on the how. A good CTO should provide their company with the following:
- A stable, scalable, and manageable platform on which they can grow a company
- Informed leadership to keep the platform relevant and updated
- Opportunities for the business to explore new areas by unleashing the true power of the platform
- Operational confidence to provide customers reliability and predictability
- Creative ways to use technology for the benefit of the company and customers
- Ability to recruit, retain, and manage a highly efficient team
Although it is common and natural for a CFO to migrate to CEO, the CTO role is often one that developers and IT managers are ill prepared for. Most will look at the role, make some assumptions, and presume it to be just an extension to their current daily tasks. This type of attitude, though common, is doomed to failure.
There is a lot more than just running a team and cutting code, particularly as your company begins to grow, and even more so if your company becomes part of a transaction to be acquired by another company or private equity group. As noted earlier, the good ones make it look all so easy, as do most polished professionals, but that masks the years of experience and hard knocks.
The CTO will touch many areas of responsibility, including everything from architecture design and product design to recruitment, implementation, compliance adherence, security, reporting/communication, strategy/vision, and budgetary planning. As the company matures, other areas that a CTO can get involved with include board preparation for the CEO and/or board presentations, vendor management, outside investor preparation, receiving and managing due diligence requests, and even evaluating other teams/technology stacks if they are asked to integrate with a potential partnership or takeover.
What makes a good CTO is being able to adapt to the needs of the company they are servicing, or at least having the good judgment to know when they can no longer provide that role and step aside for someone who can.
How the definition of a CTO is made depends largely on the environment they find themselves operating in, so let us look a little deeper at some of the different common company types in which a CTO may work. At the end of each section is a small litmus test to see which one you most align with:
A typical early startup is maybe just two people—the visionary and the technologist. More likely than not, they are both early in their careers, maybe just graduated, with no real industry experience. Yet, they are chasing the rewards that only a dreamer with a will can achieve.
Here the technologist is banging out code on a daily basis, trying to keep up with the founder’s vision of what they want the company to be. Many product pivots and redesigns are in the future as the reality of the creation starts to get into the hands of users. For gravitas, the founder has labeled the technologist as “Chief Technology Officer” on their business card (mostly to make up for the fact they aren’t paying them an awful lot, if at all).
They are cutting corners to get something out; however, now that customers are starting to pay, their focus has to shift from product development to product growth. This includes worrying about keeping systems up, securing data to comply with regulations, and growing a team, all while still trying to code.
Although these types of CTOs are not in the same league as the world’s best CTO (a contender for such a title would be Werner Vogels of Amazon), their stress and anxiety are no less real. They tend not to wish to give up control and feel threatened when they start to hire people, especially those who may be more qualified than they are. It’s hard for someone who has pulled many a late-nighter, giving up blood and sweat, to admit they may not be the best person for what is next.
When larger investors, such as venture capitalists, get involved—because technology is a key component of success—they may look to bring in someone with more experience to take over. With a little guidance and mentoring, this needn’t be the case because the existing CTO can be the right person. This may be you if you answer yes to one or more of these:
- When making technical decisions, there is no one to challenge or validate.
- You are the only person doing all the development.
- This is your first real job, even though you may not be getting paid fully.
- Very little process or structure exists in the business.
- Only you know how to manage and maintain the system(s).
The next evolution from the raw startup described in the previous section is the one that has convinced one or more investors (family, angel, or venture funding) to invest and build a business. Serious money is on the line, with a budget that makes everyone feel like they have already won. Most don’t realize, however, that they are merely living off credit, which has to be paid back at some point.
The CTO has been charged with rapidly building a team to support an architecture that hasn’t really been fleshed out yet. There is a need to produce something so the business can start to move forward, but the product team hasn’t really solidified what it is they are doing, so it’s hard to know what to build.
There will come a time when a product has been delivered, with paying customers expecting a level of service. The CTO now has to shift focus from pure research and development to support and execution. Keeping customers happy, scaling the growth while managing the next wave of product, is a skill that requires strong discipline.
As time continues, the preciousness of money will start to raise its head. The CTO has to choose the right technology that doesn’t put undue stress on the finances but still has the room to scale its costs with the growth of its customer base. In the old days, much of a startup’s investment was spent on costly servers and hosting. Nowadays, with the right decisions and strategic use of the cloud, these running costs can be a fraction of the total investment. Still, the wrong decision can see costs spiral.
Many CTOs who have found themselves in this position, who don’t want to follow the normal rulebook, flounder (largely because they don’t know the rulebook because this is their first role). There is sometimes a complete lack of structure because they feel it is modern and trendy to be completely freewheeling. However, structure and process are there for a reason: to maintain a consistent and predictable customer experience.
On the other hand, some CTOs so desperately try to make sure they stick to a given philosophy, paranoid of making a wrong decision, they end up stressing themselves into a state where progress is stifled because so much is on the line. This is decision paralysis—where the fear of making the wrong decision prevents any decision from being made.
These types of companies are in a financial race, trying to turn a profit before they run out of money, to flip them from startup to an established, cash-positive business, which is stressful for all those involved at the top. You may be here if you answer yes to one or more of the following:
- The company is less than three years old.
- No one in your department has been there for more than 18 months.
- You are now on your second (or third) platform evolution.
- The company is spending more money than it is bringing in.
- Product features feel like they are changing on a weekly/monthly basis.
A successful established company, usually founder-led, has evolved to a state where they have decided they need to get a firmer handle on the platform. They have a sprinkling of development and support staff, maybe reporting up to the CFO. The systems are key to keeping the business running, but they are starting to show their age, falling behind, making it harder to either fix bugs or extend (the likes of PowerBuilder, Microsoft Access, and Visual Basic are powering more of the world than most probably want to admit to).
The biggest, not-yet-realized problem facing this company is that no one is looking after the health and long-term viability of the technology platform. This situation is like living in a house for many years, forgetting how crucial things like the AC and hot water are, not realizing that as each year goes by, the systems are slowly aging, just waiting to fail spectacularly, leaving the house without an important service.
Sometimes the company gets lucky—management realizes they need to replace crucial systems, but they just don’t know how. Maybe a plucky sales representative has convinced them all their problems will be solved by moving to an expensive off-the-shelf solution, yet the price of such an investment gives them pause for concern. The industry has seen many failed Salesforce/Microsoft/Oracle “solutions” that were made due to an ill-informed decision. It's not the platform’s fault, but most times, people don’t need the full suite, just a small part of it. The end of that spectrum is when the management doesn’t realize just how much borrowed time they are on, being one restart away from going dark, and believe nothing needs to be changed—if it worked today, it will work tomorrow.
After talking around or seeking counsel, or maybe being told by their private equity owners, management have decided to hire their first CTO. The successful candidate has a lot of opportunities ahead of them but also is expected to prove their worth, because the attitude by some will be that they managed fine without this role up to now.
This CTO needs to be more strategic in their execution, acknowledging the nervousness that may come when introducing change or new systems. One of their primary roles will be looking to replace legacy systems, all without disrupting the current business. They will be faced with a lot of “We don’t do that sort of thing here,” and although this could be a tough gig, it will be extremely transformational and rewarding. The role is ideal for a CTO who has a little more experience, or for someone who wants to step up to the next level in their career. This company type features the following characteristics:
- It’s an established company, with paying clients and a mature product line.
- The majority of the platform is over 10 years old.
- Only a handful of people know how to keep things up; they don’t know why they do some things but know if they do, then things work.
- Most of the company don’t realize that they have as much reliance on the technology or data as they do.
- There’s a lack of standard policies or practices, including no real focus on security or compliance.
Finally, the established company knows the value of having a CTO. This CTO might have been with the company from the start, having learned everything they know on the job, with no real guidance on what they should or shouldn’t be doing. Things seem to be working for them, because the company is delivering on clients’ expectations. Or the CTO has been with the company and the time has come for them to seek new challenges, so they are leaving a well-oiled machine.
Change of leadership in this position could mean a breath of fresh air with new challenges, or to simply keep things running as well as they are. Private equity companies tend to rotate out senior management if they feel the current managers don’t have the experience or knowledge to take the company where it needs to be taken. In their world, they don’t have time to wait and see because their hold period is around three to five years. This company is easy to spot:
- The company has had a CTO position for at least three years.
- The engineering department is established, with roles and hierarchy defined.
- Process and standard practices have been instituted and, for the most part, are adhered to.
- Road maps, strategic visions, and project plans exist.
- Technology is stable and understood by most in the company.
Of course, there is a hybrid of all these types, but each has a distinct type of CTO at some point in their career’s evolution.
A common question that comes up among management is whether they need a CTO. Closely related to that—if they already have a CTO—do they replace them with someone who has different skills and drive? This decision can be inspired by noting how other companies within their space or size have a CTO on their management team, but they don’t. Another trigger can be the nagging feeling that technology should be doing more for them than it is—the belief that things should be much easier (and probably cheaper) than they are.
If a company has technology beyond back-office IT systems (email, files, calendars, chat, etc.) that clients interact with or that are crucial to revenue generation, it is vital that someone oversees this delivery and continual improvement and evolution. Another simple test can be this: is there custom software that has been developed in-house without which clients wouldn’t be able to engage what they pay the company for?
The question then becomes this: how do you present a case to management that this role is needed? This can be challenging, especially if you are looking to fill the role personally. As with any case that is presented to the business, the most successful are the ones where it is hard to argue, because they are data led, not emotionally led. Now, that isn’t to say gut instinct doesn’t play into decision making, but it should never be the only reason.
Let’s look at the following questions, if answered in the affirmative, that point to the need for a dedicated CTO:
- Is there custom software being developed for clients or in support of clients?
- Has there been significant customization of a third-party platform (such as Salesforce or Microsoft Dynamics) to support clients?
- Do you lack usage data on how clients are interacting with your systems?
- Are you in an industry that has potential data compliance or laws to be adhered to (e.g., are you storing medical or financial information about or for your clients?)
- Is security treated as a necessary evil inside the company, with much sharing of passwords?
- Are you running and maintaining your own client-facing servers?
- Do you lack a sandbox or safe environment for testing and trying new software or configurations?
- Do you have a small team of junior or inexperienced technical staff with no technical leadership?
- Is the notion of software patching or upgrading foreign and hasn’t been done in years?
- Do you lack documentation or asset/version management for the systems powering client production?
- Do you have no backup or real-time disaster recovery policy?
- Do only a handful of key personnel know how the systems operate, meaning that without them, the company would be in trouble in a catastrophic failure?
- Does support handle problems related to poor or outdated software?
- Are current systems beginning to show their age and not able to service the features clients are demanding?
A restaurant cannot run without a chef to look after and run the kitchen, making sure everyone is doing their role to provide diners with tasty meals. A CTO is the chef in the company, keeping an eye on everything that is needed to serve the food.
The vast majority of CTOs I have had the joy of either working with, mentoring, or knowing have strong technical backgrounds, which makes a lot of sense. Many of them have strong hands-on experience, with a natural curiosity for all things new—great qualities that make for a reliable and strong senior engineer, even an architect. But does it make for a good CTO?
Unfortunately, not always. Although the role of a CTO looks attractive, it comes with a lot of hidden responsibilities that aren’t at first obvious (something you will discover after reading this book) and most engineers struggle with. Not every CTO copes well with the burden of their office, because their engineering-leaning natural instincts have not translated to the new responsibilities. Why is this?
One of the biggest reasons is a lack of preparation for thinking both larger and longer term. Larger isn’t about creating or managing larger platforms but considering how those systems live and operate in the context of the company and the end client. Longer-term thinking is in terms of five-year blocks—a natural cycle of the business. How is your platform going to look in five years? Will it serve the needs of the business while still being relevant?
These are all logical and simple on the surface, but scratch it a little and a whole level of complexity and interwoven problems makes this a problem that is never really solved, but requires a solution that has been built with flexibility and adaptability.
Setting aside all the soft skills that need to be mastered—knowing how to talk to peers who don’t have an engineering background, preparing financial budgets for a project that has not yet been fully defined, hiring and maintaining a team full of talent—all while keeping the customer happy, there is a world of nebulous decisions and unknown outcomes, unlike the binary distinct world they have come from and are happy with.
It can be done. The most successful CTOs are those who know how to use their technical backgrounds to provide value and success for their company. The biggest tool that an engineer in a CTO role can have in their arsenal is the knowledge of expectations: you know what will work and what will not work, and how long it should take or last. These tools are going to make a powerful and consistent-performing CTO.
A common question asked in interviews for executive-level positions is, “What would you do in the first 100 days?” to get a sense of how thoughtful and strategic this person is. It is a great tool for the first-time CTO giving some serious thought to what they need to do and how they are going to tackle this new role. Seasoned CTOs starting a new role will also do the same thing before really getting started.
This following section looks at the things that start adding value before the 100th day comes around while not making any rash/reactionary decisions. As an engineer, you have to resist the urge to judge (at least out loud) and roll up your sleeves to start making changes. Engineers love to get their hands dirty as soon as possible—they see a problem and want to address it. Fight that urge.
The first week should be spent getting to know the company from the perspective of the client. Learn precisely what the company does, the terminology used, the pricing model, the top and most important clients. Not too much detail is required here—the key is to get a good sense of how the company runs, what each department does, and who the key individuals are.
The next few weeks will be spent getting to know the engineering department, as well as getting to know each of the departments that make up the company, in more depth. The engineering department will (or at least should) run in autopilot while you come up to speed. You may be pulled into various meetings, but the key to success here is to simply listen and observe, looking for how people perceive the engineering department and the types of personalities you are going to be interacting with.
Understanding your environment is key. What are the problems facing the company and the department? What pain points do clients have that your new group could potentially look to help with? Getting to know each individual in the group is crucial. Understanding their backgrounds, their contributions, their frustrations, and their goals will give you the best view of what is facing you. Building that trust and connection will take time, but observing how they interact with others will give you a lot of intel.
As part of this, you will be learning how things are done, which technology powers which products, and who is responsible for what. Getting to know the projects that are currently being planned and executed will give you insight into how things are thought through and the appetite for the size of each initiative.
The next wave is to dig a little deeper, get access to some systems, and start poking around for yourself. If custom development is done, then look at some source code to get a feel for quality. If you’re at a data company, review various data stores to see how data is structured and maintained. Reviewing servers, or infrastructure, lets you see the reality of execution. In short, you want to lift the lid on the areas you have been learning about to see for yourself what state they are in.
This discovery phase will give you a lot of insight into the state and capability of the team. For example, it is amazing the number of times this area highlights that a crucial part of the system has no in-house expertise or support contract. As you are going through each area, note down any easy wins or quick fixes that could make a big difference.
At the same time, getting to know some established clients is a great way to get an outside perspective. A simple lunch or quick client visit will yield a lot of information that may not already be known inside the company.
Toward the end of this discovery phase, you will start to formulate a number of short-term plans, as well as get a feel for your vision for what the department needs to do for long-term success. You may look at the current list of projects and make some small adjustments, expanding or reducing their scope, based on what you have learned.
In this phase, some execution will start—simple things, like putting in place various processes that might be lacking, or creating a better structure around areas that are a little fluffy. Your goal here is to have identified the key components of the company that are required to keep the lights on and what is required to shore those up, so any large initiatives you identify as needing further investigation don’t detract from the company being able to function.
For example, you might find an area that has been neglected, and for all intents and purposes is considered legacy, that needs to be modernized because either the software is no longer supported or there is difficulty in finding resources to manage it. Although it is tempting to focus on the “new shiny” objects, it is vital to keep the “old dull” objects still functioning, because they are the ones paying everyone’s salary.
You will have a good idea of what is what, and you will have met with the CEO a number of times, to understand them and to see what their vision of the company is. You will be starting to put more detail into your vision, but you need to get some project wins under your belt first.
By the time the 100th day rolls around, you should have a good feel for the state of the department, made some small incremental improvements/changes, and know where the company is heading. Now you can get to running the department and delivering value.
It’s a common misconception that a CTO has to have a development background—someone who can get into the nuts and bolts of the platform. This is a fallacy. Although it is true that the majority of CTOs have development or computer science backgrounds, many have risen through the business management ranks and have a good grasp on how to manage processes and execute on goals. A good CTO is someone who
- Can lead and inspire through lifting others up
- Looks far down the road before making any decisions
- Communicates in a way that is confident yet nonpatronizing
- Listens to their CEO and board to understand their desires and goals
- Keeps themselves updated with the technologies that are most relevant to their company’s industry
- Is not scared to fail and, should they fail, refuses to point the finger
- Doesn’t try to do everything themselves and instead delegates to their team
- Knows they are not the smartest person in their team just because they are the boss
- Is confident to acknowledge and credit a good idea, irrespective of its source
- Has a vision that can be communicated and actioned
A CTO is no different from any other leader in business in that they need to have the same skills to motivate and inspire to get the best out of their team. It is important that this is not the only book you should be reaching for as you aspire to be better in your role—your shelf should contain at least one or two general leadership books.
The CTO has a lot of responsibility on their shoulders. They need to juggle multiple balls, operating at a level that is way beyond a senior engineer or even project manager. Realizing this difference is what sets the great CTOs apart.
- A Chief Technology Officer is someone who looks after the current and long-term future of the platform.
- For companies early on in their lifecycle, the CTO is more of a hands-on, doing-everything type of role because that is what enables early growth.
- As the company grows, the role evolves into more of a management/architecture role, delegating and looking outward more.
- For an established company, the role continues to evolve, shoring up the technology to permit growth and scalability while fixing some legacy problems.
- We created a checklist for companies that don’t have a full-time CTO to make it easy to determine whether now is the time to take on that role.
- The first 100 days of taking on the role will define the leadership and thoughtfulness of the CTO, as they dig in to discover the challenges ahead and as they perform their own in-depth due diligence.
- Although many qualities make a great CTO, we identified 10 of them that all speak to making best use of the team around them and creating an environment where many hands can make light work.