The CTO Is a Communicator First

When you think of a CTO, what do you see?

Someone gray-haired, steering the ship like the last 20 years? A young, hot-shot that solves every single technical problem and then plays video games to relax?

It really doesn’t matter. I don’t actually picture or “see” anyone.

I can tell if a real CTO is in the room by just opening up my ears.

The Job

What’s the job of the CTO role? A few years ago, I wrote about exactly this. And I had it right. What a CTO is and does detailed the split between technical chops and communication.

In that entry, I listed the high level skills they need - but I don’t think I was as forceful as I should have been with my suggestions. I used “In a lot of cases” and “usually” to hedge.

The job is more than just those high level skills and general direction. It’s about prioritizing the time of the role for what’s needed. And surprise - it’s not “usually” or “maybe” - it’s very clear.

A real CTO knows the line they walk - between technical and communicator - and how much effort they put towards both. Let’s investigate that.

Technically Hands On: 20% of the time

A CTO should still write code, review pull requests and attend technical discussions. That’s the 20% of the job that may seem pretty obvious - especially for CTOs who came from a programming career and were promoted upward.

Before I go further, though, let me be absolutely clear: if there are enough resources that this is a CTO role, and not just a fancy title to compensate for a lower salary, then a CTO is not doing work to hit a production code timeline.
They are not saving the world. They are not the final call for solving a technical problem. They find the people to be that instead - so they don’t have to be that anymore.

But more importantly, the reason for them to still be involved (just not in critical pieces) is for the familiarity of how the technical landscape is changing.

And it does. There are different languages, different toolsets, different costs and risks involved. When developers start complaining about an inefficient process, it’s much more enlightening to have experienced it yourself. If you are only doing communication, only working with the business, you start to lose track of all the work that is happening on the ground.

The CTO who is responsible for the overall technical direction of the company can’t become disconnected: but they aren’t your production linchpin either. 20% of their time is dedicated to staying involved, hands on, and being current.

The Other 80%: Communication

The rest of the job is simple. And really complex. And difficult. And not that hard (if you just do it).

It’s talking, listening, and translating. That’s it.

It sounds simple, and that’s why we tend to let it drift away from the 80%, the high priority, that it deserves. But this is anything but simple.

It’s guidance: helping the team choose a direction without dictating. Your hands-on time gives you context, but the developers are the ones who are going to be actually accomplishing these tasks.

It’s removing road blocks and handling ego: that other team, while they’re the only ones who can help the devs, they have their own needs and priorities too.

It’s prioritization beyond one team: the senior developers and team leads already know what needs to be done. The CTO takes those, at face value, and combines them with the entire company’s roadmap.

Then they make - and communicate - the tough choices and direction.

Over and over again.

And it’s translating the technical “noise” up to the stakeholders, listening to their concerns, and honestly applying that priority and feedback to the decisions. And communicating that again.

See? It sounds like prioritization, but in reality, it’s communication.

The Result

I strongly believe in consequence. There are reasons for our action. Do the job wrong and someone, somewhere, doesn’t know about the consequence. They didn’t know the risks their decision introduced.

How about this for an example. You go to the restaurant, and are given two choices: hamburger or chicken. You might not really think about it. You want food, so you order the chicken. Food is food, right? And it solves the problem. You’d be fine with hamburger, but you’re feeling chicken.

What you don’t know is that the hamburger is already prepared. It just hits the grill. The chicken? You just sent Aaron on a wild-chicken-chase - literally - and he has to catch that chicken. Then after he prepares it, plucks the feathers and cooks it, he brings it to you. It took way too long. It was way harder to do - and you’re upset because the food was delayed.

Everyone seems unhappy. Whose fault is that?

Team Cohesion

Before I get to that - let’s take a quick walk through the kitchen. Turns out, there’s another chef who has a prepared chicken already. He had extra from his dishes. But the original cook didn’t know about it. So he had to go catch that chicken and prepare it himself. Duplicate, and hard, work!

Sure, teams communicate with each other. But, that’s not their main job. That, again, is the job of the CTO.

First, the CTO attends to their own ‘flock’ - by making sure everyone knows what everyone else is working on. This team cohesion gives a sense of belonging and connection to the goal for everyone; more importantly, it gives the CTO more options and levers in their toolbox.

Perhaps, in this one case, the first cook would have asked the other chef for his spare chicken. Because the kitchen lead, or CTO, would have informed everyone earlier in the shift what resources were in use and what were extra.

Consequences with Choice

Everything the CTO chooses to do with their time has consequence. Our example is silly, sure, but it illustrates the issue in a way that we can all recognize.

Sometimes the decision makers, the stakeholders, don’t understand the consequence of their decision.

The CTO’s job is communication - tell them what each choice entails and what the consequence is.

Let me follow this through in a more technical way: The stakeholders ask for a feature, it’s really hard, the CTO never warns of the consequence of this action, and the project is late. Not only is it late, but other things are missed, too. And this is because our programmers were running after that metaphorical chicken - instead of just giving us the meat we wanted, already prepared for the grill.

Whose fault was it? The CTO. The CTO needed to communicate the consequence for each decision.

The Risk of the Solution

But why does consequence even matter? I already alluded to one risk: late projects.

But there’s so much more.

This late project, other late projects, internal teams getting upset, developers wanting to quit. All because the CTO didn’t do the job they were meant to do.

And that’s the point of all of this. The CTO needs to stay a little hands-on - so they can honestly assess the risk and consequences (and separate programmer emotion and just desire - from legit business considerations) accurately. But then, they must also take that information, disseminate it, translate it, and apply it effectively to other decisions far beyond the scope of their direct team.

A CTO is a Communicator First

Their realm is technical, but their actions are instructional.

That’s it. They must stay technically current, but they spend their time communicating: unblocking the workers, communicating the risk and consequence, and informing the team about how things relate.