But all too often, we find that our teams or team members are working in silos, not fully understanding what others are doing (or why). With this series, we’ll be digging into the various members of your team to help you understand and work better with them all.
This week, we’re talking to CTOs to see what matters the most to them. To get a feel for what a CTO does, you can think of it in the words of current Clubhouse CEO and former CTO at Intent Media, Kurt Schrader:
“What does a CTO do? Think about what a CEO does — whatever it takes to get it done. Then, scope that to technology and you have a much more realistic idea of a CTO’s workload than ‘just’ leading the engineer team.”
The CTO is concerned with the technical direction of the company as a whole. So, what matters most to them?
Despite being C-level management, all too often CTOs find that their peers fundamentally misunderstand that the CTO’s primary work is strategic and business development work, not software engineering.
Kevin Goldsmith, CTO at Avvo, says, “People don’t understand how little of my time is spent on technology — they’d be shocked at how much of it is spent in Excel going over business numbers, or in meetings. If someone like me is coding, then something has gone wrong.”
Even with how much the CTO role can vary, writing code isn’t usually part of it. “Even when you’ve got an engineering team of ten people, you don’t really write code any more,” notes Kurt.
For Kevin’s part, when he’s not sitting in on meetings or going over business data, he’s doing things like:
CTOs want their engineering team members to understand what they do, so they can have the right kinds of conversations.
While your team may be doing amazing work, people won’t know (or want to join in!) without someone committed to spreading the word.
As Kurt puts it, “a big piece of a CTO’s role is raising the profile of your engineering organization.” The VP of Engineering role is often more inward-facing, but the CTO role is outward facing, with a large focus on building the profile of your organization so you can continue to hire strong talent.
Kevin agrees, noting that a big part of his job is making sure his company is visible in the local tech scene. This can look like:
CTOs need you to know that while they are there for the engineer team, they often can’t actually be , they often can’t actually be there on site, because they’re busy spreading the word about your greatness. Be patient if you can’t get ahold of them, and whenever possible, try to catch up with your VP/Director of Engineering instead.
Ian Lotinsky, CTO at LearnZillion, encourages his engineers to think about not just the software they’re writing, but the product they’re building.
“As software engineers, they’re putting ideas into code, and because of that, they’re faced with the reality of creating the product more than anyone else on the team — even the product manager.”
Engineers are also the ones that are dealing with the constraints and contradictions that show up when you’re putting something into code for the first time — things that you can’t foresee by looking at a wireframe or a feature document.
Because of that, Ian says they’re in the ideal position to have the most context about what the product goals are, letting them make the right decisions when they have to face those constraints.
Because great power comes with great responsibility, good CTOs try to make sure their engineers have useful context — about goals, technical limitations, and organizational constraints.
When the team knows more, they are better equipped to make a good judgment call they come to a crossroads. Says Ian, “I really want engineers to understand the importance of their role and their contribution, outside the material contribution of writing code.”
Peter Kretzman, creator of CTO/CIO Perspectives, agrees, noting that “Technology organizations can’t thrive in a vacuum, and don’t produce optimally when regarded as sheer order-takers. The more actively that technology people can participate in evaluating needs, forging initiatives, and juggling trade-offs, the more effectively the overall business will deliver on its mission to serve customers well.”
The biggest thing that CTOs want from their team is dependability. “Dependability and predictability of the work deliverables is really important,” notes Ian. CTOs want engineers to create systems that:
Ian continues, “You can’t just look at how much an engineer is getting done as far as tasks or stories without context, but looking at things like bugs produced compared to features produced is something that we track internally to get a handle on the quality of work our engineers are producing.”
Much like project managers, CTOs also value having a predictable cadence to the work their teams are producing. Camille Fournier is the former CTO of Rent the Runway and the author of the forthcoming book The Manager’s Path as well as the Ask the CTO blog (both from O’Reilly Media).
In a recent post about protecting teams in times of stress, she says “Sometimes, when combining the role of shield and mentor, (CTOs) end up in a parenting-style relationship.” She cautions CTOs against doing this saying, “(The engineering) team is made up of adults who need to be treated with adult-level respect and held with adult-level accountability.”
Estimates are a hot topic among engineers (as you might remember from our last post), but most CTOs don’t necessarily want or need minute-accurate estimates. They just want them to be in the right ballpark. On the other hand, if you’re overshooting your estimate by weeks or months on a regular basis, there’s an underlying problem that needs to be discovered and addressed.
CTOs want (and need!) self-directed engineers, people who also know how to reach out for help without having to be nudged or micromanaged.
If you’re a CTO, we’d love to hear more about what matters most to you, and if you’d like to manage your software teams more effectively, try a free trial of Clubhouse today!