CTO Image

This post is intended for CEOs, COOs, Presidents or CPTOs (Chief Product and Technology Officers) of companies that build software products for revenue and who have as a direct report someone running the engineering, QA and technical operations of that software product.

What is the CTO role and what are their responsibilities?

The role of the CTO often varies by industry and company. Within software product companies, especially Software as a Service (SaaS) companies, the CTO typically focuses on customer-facing technology products including the architecture, technology strategy, infrastructure, technology operations and QA of that solution.

Contrast this with the typical CIO role within software product companies, wherein the CIO is most commonly responsible for internal systems that enable employee productivity and support the business processes of the company.

Commonly within these companies, the CIO is a direct report to the CTO. This reporting relationship is not a necessity and while it has some benefits, there are also some drawbacks.

Benefits of the CIO reporting to the CTO include:

  • One center of excellence for technology related decisions.

  • An opportunity, where valuable, to share best practices and in isolated cases technical solutions (the latter should be limited such that employee and customer systems do not cause conflict with each other).

Drawbacks of having a CIO report to a CTO include:

  • Dilution of CTO mindshare – causing him or her to also focus on internal business process needs (cost savings vs. generating new revenue).

  • Great CTOs don’t always have experience with non-market driven internal technology decisions and as such may not provide value in one of the key components of a CIO job – business process implementation.

Whether having the CIO report to the CTO or not, we strongly advise that the CTO be responsible for absolutely everything necessary to accomplish the mission of delivering and operating a revenue generating technology product or service including:

  • All architectural functions necessary to help design the solution.

  • All engineering functions (hardware and software) necessary to bring the solution to market.

  • All quality assurance activities necessary to validate the solution and its various releases have the appropriate quality prior to launch.

  • All systems administration, network administration and database administration skills to build and run the product appropriately.

  • All process and tooling definition, infrastructure and engineering (e.g. Dev-Ops) necessary to automate builds, release products and monitor the efficacy of the solution.

  • All operational skills and capabilities to maintain and run the solution in a production environment inclusive of operations personnel responsible for monitoring and repairing customer impacting incidents.

  • All program management capabilities necessary to help keep the trains running, ensure adequate tracking and reporting of progress and consistency of ceremonies in all administrative functions.

Put simply, as is the case with any organization, you want to ensure that the CTO has everything necessary to accomplish the mission and be held accountable for KPIs such as:

  • Value creation relative to cost of development (lagging indicator)

  • Throughput/velocity of the engineering team relative to cost of development (leading indicator)

  • Availability of the solution measured in business terms. https://akfpartners.com/growth-blog/measuring-availability

  • Quality of the solution relative to the needs of the customer to produce the customer desired results.

  • Latency of the solution to the end customer (response time) https://akfpartners.com/growth-blog/what-is-latency

  • Technology cost of operations (or cost of goods sold) in delivering services to the customer.

  • Time to market by size of effort.

Saving the best for last, the most important function the CTO fulfills is to be the bridge between business executives and the engineering team. As such, he or she is fully responsible for explaining engineering imperatives, progress, and outcomes completely in business terms. Be mindful of this when evaluating new CTOs as it is the activity at which many CTOs fail.

And if you are in the market for a CTO, here’s a hiring checklist you might find useful.

Why is the CTO Role Important?

Your chief product officer (CPO) and his team are collectively the engine of your company. Your CTO and her team are the transmission linked to that engine. Absent the transmission, your engine may produce great power, but to no avail.

The CTO should be a strategic position, responsible for ensuring you have the technology capabilities to implement your product strategy. The executive must also be tactical and capable of responding to the urgent needs of your revenue producing engine.

Here’s a list of some of the many responsibilities of a CTO and why she is one of the most important executives in your company:

  • Nests technology strategy to the product strategy and ensures new products and product enhancements are brought to market in a timely manner with the appropriate quality.

  • Responsible for leading some of the highest cost and highest value people in the company. These folks are incredibly high paid and there exists incredible market demand meaning the CTO must create a culture that supports high morale and retention.

  • Responsible for managing budget of one of the biggest expenses in the company.

  • Exists as a bridge between the business and the engineers who implement product. As such, one of the only people in the company who can speak both “tech” and “business”. Without him or her, you are missing the most important part of your transmission – the torque converter responsible for transmitting the torque from your engine to a rotating load.

  • Responsible for building a learning culture in an incredibly complex and constantly changing environment. Your product likely evolves rapidly, which requires dynamic systems thinking and the ability to pivot quickly.

You need all these things in your business. Unfortunately, few people can do all these things, making the CTO a critical member of your executive team and the right person hard to find and keep.

How do I know if my CTO is doing a great job?

There is no magic here. Just as you would with any other position, you should manage, coach, and hold your CTO accountable to measurable outcomes including both leading and lagging indicators of success. Leading indicators of success include elements that help determine the probability of low cost, high quality, fast time to market releases including:

  • Delivery velocity measured in “story points”. Here you are looking for low standard deviation between iterations and a subtle upward trend in velocity per team.

  • Find/fix defect ratios before deployment. Look for an improving (decreasing) rate of defects found (ideally indicating better development – as long as production defects don’t also increase) and a fast time to close them to help improve time to market.

  • Management Engineering Efficiency – a ratio of engineering time spent developing code to time expected to be developing code. If you expect your engineers to be developing 20 or 30 hours a week (excluding meetings, ceremonies, etc.) then that becomes the denominator. The numerator is the time they spend coding. It’s not unusual to find that engineers spend less than half the time you expect delivering software due to problems in production, too many meetings, too many interruptions, etc.

  • Release frequency – how many times a year do you release? More is always better as it means fewer delays from when software is complete and can create value and when it starts to create value in production.

Lagging indicators of success should be business related and include items such as:

  • Cost per transaction in production - a measurement of how much it costs you (in infrastructure) to produce a unit of value. These are often represented as a ratio such as cost/transaction (e.g. $.001 per each user transaction in production) or cost per user (e.g. $2/user/year in production).

  • Defects found per engineer in production. This is a measurement of defects that inhibit value creation divided by the number of engineers (or opportunities) to create defects. Ideally this should decrease over time.

  • Business value created compared to cost to achieve. While you can’t hang this solely on the heads of engineering (product for instance is intimately involved), it’s a great way to align the engineering and product teams with value creation. The actual metrics vary by business and industry – but choose 2 to 5 key indicators of business success that can easily be described in monetary terms and compare it to the cost of development they enabled.

  • Availability – this should be measured not by “time” but rather by impact to business value creation. 100% means the service never had an issue with customer and business value creation.

You also should evaluate your CTO subjectively, including how well she creates and maintains relationships inside the firm, how she helps with selling your product, and how well she “speaks the language of business” with her executive partners. Here are some other signs of good CTOs:

  • Good mix of verbal, written, and visual communication skills. Many concepts that are technical and/or span departments cannot be easily explained with words. A CTO should have the ability to quickly draw and explain concepts to get technology and business stakeholders on the same page. They should also be able to translate technical approaches and terms into business meaningful language that relate to company outcomes.

  • Strong partnerships with the leadership team. CTOs should have a regular check-ins with peer teams and not rely on CEO led meetings to coordinate. CTOs should be able to understand how the product they build impacts the roles and jobs to be done for other peer functions within the company.

  • Ongoing relationships with 1-2 key board members. This helps the CEO offload some key conversations and helps to build trust between the leadership team and the board. Some board members focus on risk mitigation, others focus on value creation. A good CTO knows how to interact with both types.

How do I tell if my CTO is doing a poor job?

When you see the objective and subjective metrics above going south, you have an early warning sign that help is needed. Below we’ve also included some common ultimatums issued by CTOs who are either incredibly overworked or potentially in over their heads. These statements may also serve as early warning signs that your CTO needs help to get out of a hole, or that you may need to replace your CTO should you not be able to manage her into a higher level of performance.

  • “We have no choice but to rebuild this”

    This statement often comes from a CTO who is not evaluating the need to also maintain a viable and growing business. While it is sometimes true that solutions need to be updated and refactored, it is rarely (but admittedly sometimes) the case that something needs to be completely rebuilt. Ask your CTO if she really means that the business needs to be put at risk to pause all value creation to fix something. Sometimes this alone will get a CTO who is simply over worked to pause and reconsider the situation. Consider leveraging your board of directors to find outside help to evaluate the situation and validate the statement if you no longer trust your CTO.

  • “We can’t lose this smart person.”

    This statement is typically in a response to a query about someone on the team who, in Reed Hastings’ terms, is a “brilliant jerk”. Great leaders, and make no mistake about it your CTO must be a great leader, understand that jerks, regardless of how brilliant, cause more harm than the value that they bring. If your CTO is tolerating a brilliant engineer who causes organizational damage, then she is as big a problem as the engineer in question.

  • “Everything has to stop while we fix this.” or "“We have too much technical debt to do anything right now.”

    These are really two different sides of the same coin. Again, there’s a high probability that your CTO is struggling with the workload or just under too much stress. If you can’t get them to reconsider their answer, consider seeking outside help to validate their perspective.

Key Points for the Executive Managing the CTO

  1. Identify leading and lagging indicators of success measured in business terms and review them frequently during one-on-ones (1:1s).

    See the section above on metrics to help guide and manage your CTO.

  2. Make your CTO explain things in business terms.

    Remember that it is your CTO’s job to be able to translate technical terms and initiatives into terms the remainder of the business can understand. Put simply, every initiative should be evaluated from the lens of the Statement of Cash Flow, Income Statement and Balance Sheet. If your CTO struggles with this, consider sending her to an executive MBA program or finance bootcamp to help bolster their understanding of business.

Common Executive questions about Managing a CTO

  1. I don’t trust that my CTO is telling me the truth – what do I do now?

    It’s possible, but unlikely, that your CTO is lying to you. It’s more likely the case that your CTO is not explaining things to you in a way that you can easily understand – which of course foments distrust. Remember – it’s the CTO’s job as an executive to understand and speak the language of business – not your job to understand technology and the language of engineers.

    As earlier indicated, your CTO may just need a combination of coaching and education to help ensure she understands how to focus conversation on business outcomes rather than technical paths. Education (e.g. executive MBAs or business bootcamp classes) can help ensure she understands the fundamentals of business communication and coaching may help practice those skills to make her more effective.

  2. Why do we seem to go slower and get less done even while adding people to the engineering team?

    Absent a relentless focus on aligning your product architecture (the componentry of your product/solution) to your product organization structure (how your people are organized) you will absolutely slow down on a relative basis (output per engineer) and at the extreme potentially even an absolute basis (overall throughput).

    The primary contributor to “slowing down as you grow” is the overhead necessary to coordinate the activities of a growing engineering team over a code base that increases in complexity over time. The more people we have working, and the larger the code base upon which they work, the slower each engineer will be and the more difficult the coordination of their activities.

    The fix to the problem above is to separate monolithic codebases and databases (insert links to monolith and services CEO guides here), and to align empowered cross functional teams to “own” these product components. Doing so reduces coordination overhead and complexity (cognitive load) of the componentry thereby increasing velocity and development throughput.

    For more on this topic, read up on Conway’s law here

  3. How do I get my CTO to explain things to me in a fashion that I can understand?

    As we indicated in the “trust” question above, consider both education and coaching. Consider sending your CTO to an abbreviated or fully accredited MBA course and add coaching to help build muscle around effective business communications. All verbal communication should focus on business outcomes in business terms. If a deeper technical discussion is needed outside of the outcomes that approach engenders, focus on pictures and diagrams rather than words as it will often help the non-technical CEO understand the approach better.

AKF offers services to help coach and improve your CTO, as well as services to evaluate your product and engineering organizations and solutions. If you find yourself in a bind, we can also offer you an interim CTO while you seek a qualified executive to join your team. Call us, we can help!