The CTO Role
Defining the role of CTO can be tricky. Each company has a different
experience with their CTO, and so the role can be murky at times.
The CTO is often viewed as at least the spiritual leader for the technology
organization. That person defines technical strategy and direction, and
delivers the the tools and products the organization needs to be successful.
But how?
Some industry CTOs are the most technical person in the organization. Some are
the ones who can connect business opportunity to technical execution. Some are
leaders of people, shapers of process, and technical recruiters in chief.
I spent a fair amount of time reading about the role of the CTO, especially in
consideration with the role of VP of Engineering. Most writers’ experience has
been that CTOs they’ve worked with have been technical masterminds, hacking
new, interesting ways of solving problems. Those CTOs are also described as
visionaries, sharing the direction of the product with Board members,
customers, and the broader external audience.
Those same writers believe that a VP of Engineering is the lead internal-facing
role. Recruiting, training, advancing, and transitioning staff. Structuring
process and execution. Defining and shaping the team that delivers on the CTO’s
vision.
Only one writer even suggested that a combination of the two was possible, and
thought that that person must be a unicorn.
Well, I suppose I’m a unicorn.
Over my 17 years in technical leadership roles, I’ve found that I naturally
manage all those roles above. Not only am I consistently one of the most
technical people on staff, but I also focus on personnel and process strategy
that delivers results. I am passionate about the products I build, and my
organizations have never stumbled for a lack of technology. I naturally connect
business strategy to technology vision, and create systems and structures based
on people that drive value and success.
In short, I believe these writers’ view of a separated CTO and VP of
Engineering is a dichotomy that doesn’t work for me.
So, this is how I see my role:
Mission: Enable us to succeed by delivering the best possible technology.
I do this by delivering on 3 key areas of focus: Company and product strategy,
people strategy, and technical strategy.
Company and Product Strategy:
- Business strategy, vision
- Connecting mission to time-bound visions
- Organization structure to deliver on vision
- Operating structure to support the organization
- Product strategy to deliver on mission
- Market adoption
- Revenue strategy
- Roadmap
- Success definition and measurement
- Financial management
- Budgeting & managing to budget
- Fundraising & due diligence
- M&A – strategy, technical review and integration
People Strategy:
- Tech, Product, Design Organization structures
- Team plans
- Staffing levels
- Roles & responsibilities
- Operational processes
- Talent management
- Sourcing, recruiting, and hiring
- Growth & development
- Performance management
- Transitioning people out
Technical Strategy:
- Systems architecture
- Services definition & communication patterns
- Data flows
- Technology capabilities
- Foundational technologies and frameworks
- Libraries and third-party software strategy
- “What should we use, why, and how?”
- New capabilities research & development
- Stability & Performance
- Infrastructure reliability
- Maintenance
- Ongoing operations
- Risk management
- Risk identification and mitigation
- Quality engineering
Certainly this scope is large, and managing it requires an excellent team! I
thrive by building teams and enabling them to support our shared mission. I
rely heavily on capable professionals who own elements of these items above
deeply.
I tend to operate best when I have these direct reports:
Functional Area leaders:
- These are usually Director-level roles, but sometimes are VPs.
- These individuals own and define what is great in a functional area, such as
python or quality engineering, or infrastructure operations. - It is these individuals’ jobs to define what is good and to hire and develop their staffs.
- Because my organizations are cross-functional, these people must communicate
regularly with each other to help our collective team grow a thrive.
Continued alignment activities to ensure we are moving together with one
vision are crucial.
Specialised Individual Contributors:
- I often also promote non-managing leaders who own a key element of process or
strategy. - Examples:
- Leaders when a department is small (Agile Coaching for example – I tend
to only have a handful of strong ICs who rotate through teams and coach
on process evolution) - Advanced technical individual contributors who can own architecture
across large areas of the system
- Leaders when a department is small (Agile Coaching for example – I tend
I believe management starts to lose effectiveness when one person has more than
7 direct reports, so I try to restructure my organization when that starts to
happen.
Given all of the above, I don’t tend to operate with a general VP of
Engineering. I find the confusion in general expectations of how the roles
play together to be detrimental to outcomes. At least, I haven’t yet
encountered scale sufficient to support it, and I didn’t foresee that need when
I’ve considered planning organizations of up to 150 individuals.
What do you think? What structures have worked well for you?