The Machine that Builds the Machine

Reflecting on Inovia’s 2016 CTO Summit

Earlier this month, 12 of Inovia’s portfolio company CTOs spanning company stage and industry came together for a day of knowledge sharing and strategic reflection — two priorities that can be challenging to fit into a busy CTO’s jam-packed daily schedule. This year, discussions at Inovia’s annual CTO Summit focused on the machine building the startup machine (with a taste of quantum computing thrown into the mix for fun).

Although the day followed strict Chatham House Rules, I think it’s important to share some of my key takeaways around startup CTOs roles, and how those responsibilities evolve as a company grows. Six core roles emerged — although this list is neither exhaustive nor are the roles necessarily exclusive.

Role #1: On the purely technical side, CTO’s can split responsibilities into four functions

At the highest level, all elements of a startup’s engineering structure fit within four functions — people, process, product, and codebase. Initially, the CTO will own all four areas, and drive progress equally them. However, every CTO has unique strengths and weaknesses. It’s important to build teams and hire senior leaders to address those unique weaknesses. In one startup, the CTO may focus on people and process and delegate product and codebase to a VP Engineering, while another may find their personal strengths warrant a different responsibility split. The division itself is unique to each startup, but the categories and need to divide will remain constant.

Role #2: CTOs must increasingly delegate technological duties to subordinates, and increasingly focus on budgetary and strategic issues as the company grows

At the seed stage, the CTO may be the startup’s sole engineer. However, as startups enter the growth stage, the CTO becomes a manager and must shed their time spent coding in favour of time spent leading. We identified four responsibilities within this larger transition:

1. The CTO must develop and communicate the company’s critical path — effectively setting the engineering team’s vision.
2. The CTO must give subordinates authority, responsibility, and control — enabling reports to take ownership of the vision.
3. Recognizing that with authority, responsibility and control come frequent decision making, the CTO must give subordinates clear goals and context to inform those decisions.
4. Finally, the CTO must coach subordinates to be leaders themselves. Just as the CTO might struggle to transition from “doer” to leader, delegating is a challenge for engineers within the organization who transition into leadership positions. CTOs must invest in coaching engineers who want to become leaders and prime the engineering team to embrace that change.

Role #3: CTOs must write the operating system (the culture) of their machine (the startup)

Around the table, we reached a consensus that it’s important to build a culture where people are accountable and want the responsibility. Specifically, CTOs need to create a culture where it’s acceptable to screw up, but not to make the same mistake twice. Inherent in this philosophy is an understanding that engineering is a system and individual or component failures may be system failures.

An excellent diagnostic tool is Toyota’s Five Why’s technique. When you have a problem, you ask “why” it happened. Then when you have your answer, that is grounded in fact, you ask “why” again. You repeat this until you’ve asked “why” five times. At that point, you will usually have a good idea about what is the root problem.

Role #4: CTOs must maintain the machine

Just as the resources needed to support maintenance can be overlooked in new product decisions, so too can the resources necessary to preserve the health of the organization. 1:1s emerged as a useful tool to gauge cultural and operational performance. The “intimidation factor” may be an inhibitor to getting honest information, especially if CTOs don’t realize their perception within the organization is changing from friend to leader (which it must and will). CTOs can disarm this by talking about personal mistakes and building a culture of talking about risks and failures. Setting a regular cadence of discusses challenges mitigates the stigma and hesitancy to do so when major failures occur.

Throughout the organization, performance reviews are necessary to give both positive and negative feedback. The manager who works closest to the employee should provide these. While the startup is small enough to allow it, the CTO should be present to moderate the conversation. Once the company reaches critical mass, and this is no longer possible, the CTO should remain part of the conversation at the top tier of the organization, delegating that responsibility downward as appropriate.

Role #5: CTOs must hire great people

Young CTOs are often afraid to hire more seasoned leaders. Great advice emerged from one participant in the room —

“Don’t be afraid to hire your dad.”

Bringing on experienced talent contributes to the organization’s health. Strong engineering talent is expensive, especially for those seasoned leaders, but worth investing in. Although engineering teams appreciate flat hierarchical structures, they also need a career ladder, especially as they see one emerging in the sales organization.

Keeping talent is a challenge — it’s difficult to compete with incumbents like Google and Facebook from a salary perspective — and new entrants to the workforce can have unreasonable expectations around promotion timelines. To combat this, move beyond focusing on talent retention to emphasizing talent flow. Help departing engineers in their job search, and make sure they have good things to say about your workplace. Talent migration is bi-directional, and departed employees may return in the future with a new perspective and more experience.

Role #6: CTOs must be a translator between engineering and business units

This role is two-fold. First, the CTO must communicate the business goals of the company to engineers. These help enable Role #2 — delegating technological duties to subordinates. Autonomy, responsibility, and control complement a thorough understanding of the company’s strategic vision, and the role engineering plays in building the critical path to achieving that vision.

Secondly, the CTO must educate business units about engineering trade-offs and risks. Framing discussions around risk trade-offs helps sales and marketing understand the levers driving project completion and estimation reliability. It also facilitates a deeper understanding of the impact of long-term technical decisions, such as technical debt and its impact on future sales. Bridging the gap between these two units enables higher level conversations, as both sides develop an awareness of the impact their decisions have on the other, and thus on the company’s health as a whole.

The six roles outlined above are core to a CTO’s function. These roles are fixed across the lifetime of an organization, although every CTO’s interpretation of them, and specific actionable items, will vary over time. Another role identified is to remain forward thinking and identify strategic priorities in the future. CTOs may choose to build both a roadmap and a “not-yet roadmap,” the latter which will include ideas worth pursuing, but not on the immediate agenda. One such strategic priority we discussed was quantum computing and its impact on cryptology and security. As part of our Summit in Waterloo, we visited the Institute for Quantum Computing housed within the University of Waterloo, which works in close collaboration with the Perimeter Institute. Rather than divulge the secrets shared with us, I direct you to the following video of Michele Mosca’s public lecture on the coming quantum era, and the quantum technologies that both exist now and will arrive shortly, which will dramatically impact our lives.

As you can see, we covered a lot of ground over the CTO summit. As a young, first-time CTO, it was an invaluable experience sitting around the table and listening to veteran and relatively novice CTOs like myself discuss the core challenges of the job and how it evolves over time. Huge thanks go out to Shawn Abbott and Sarah Marion from Inovia for putting on the event, in addition to my fellow CTOs for sharing their experiences. I am looking forward to next year’s summit!