Improving Communication between CEOs and CTOs

---

Transcript:

Peter Bell:

Welcome to the CTO Connection podcast. I'm Peter Bell and every week, I'll be sharing an interview with a top engineering leader. Firstly, I want to thank AWS, who are our exclusive, ultimate partner, and without whom we couldn’t run our summits or the business.

AWS offers a broad set of global cloud-based products to equip technology leaders to build better and more powerful solutions. Reach out to aws-ctl-program@amazon.com if you're interested in learning more about their offerings.

Our friends and sustaining partners at Cold Climate just upgraded their velocity product with team and developer 360s. If you’re worried about engineering speed or your return to market, you need to know what’s happening on the engineering team from the individual engineer up through senior management. The new velocity offers a 360 holistic view into how your engineering org is performing with data and accurate objective metrics. Cold Climate is selling measurable improvements – 20% plus for most customers—in feature-cycled time and deploy frequency. All CTO Connection folks get a free product tour and engineering data consultation. Just mention Peter on your first goal.

Today, I'm speaking with David Subar, the Managing Director of Interna, David, thanks so much for taking the time to talk today.

David Subar 01:23

Thanks, thanks for having me.

Peter Bell 01:25

Now, as with all our guests, we always do a brief trawl through memory lane and I believe that after you got out of college, you started by writing software.

What was your first job out of college?

David Subar 01:37

First job is I worked at a military-owned Think Tank, and I was doing research and development on AI and machine learning for a bunch of military applications, some of which I can talk about and some not.

Peter Bell 01:49

Got it. And how did you find that? was it was it satisfying? Interesting? How did it work?

David Subar 01:55

It sounds interesting, but it was really frustrating. And it was frustrating because I wasn't doing something, like we were writing some software-- we had some research we wanted to do-- writing software behind it. And we're trying to prove something but then we wrote a paper; and then that paper got presented at a conference maybe, and maybe 200 people listened to it. But then it died. Nothing happened.

And so it was frustrating for me because we're doing all this work, it was really interesting work, but there was nothing that came of it for us, for anybody. And so I transitioned there, like that was a big-- that was a big turning point in my career, where I thought I wanted to be a scientist, but what I found out what I really wanted to be was an engineer. I wanted to build stuff that had an effect on people.

Peter Bell 02:44

So, what did you do after that? What was the next gig?

David Subar 02:48

So I went to an AI tools company; and I was a developer there, and then I started leading larger and larger teams. I started managing departments, became the director or departments; eventually, I became CTO of not that company, but other companies. Actually, I also started up my own company, I started a game developer along the way using AI tools in games.

That was super fun, very tangible. But eventually, I got more and more senior positions and became CTO of companies. Then, I started running product and technology, and I got kind of meta about it. So I went from building software, to building teams that build products.

Peter Bell 03:26

Now, how did you first start to make that transition? You're writing some code for this AI tools company… what made you think, “You know, what I should do is, like, stop writing code and manage a team of eight people instead!” Like, how did it?

How did that transition occur?

David Subar 03:40

So that, that's a good question, so I just wanted to do more right, not that running software wasn't more, but I wanted to broaden my impact on things.

How do I move the needle in a significant way? How part of it was like, the conversations that go, “Hey Mom, this is what I built.” Right? And mom-- in a way that mom can understand. And some of these are lower level and the world needs those people. It's really important that people do that-- but as nerds go, I'm a gregarious one.

And I'll tell you one of the critiques I got, from one of my bosses, probably six, seven years into my career… he would ask me to do stuff. I kept saying “Why?” At one point, he got frustrated. He said, “you need to stop asking why. This is what I need to get done.”

This was an executive who clearly had never been a developer. Good guy, smart guy; and so, I realized over the years, what he asked me to do was completely wrong.

There's three or four ways to develop anything. If you don't have the context-- if you don't know who you're trying to impact, the odds of you consistently picking the right choice is very, very small.

Peter Bell 05:05

Well, I think there are two challenges, right?

One challenge around the fact that most people describe their requirement not as the problem they want to solve, but as a badly thought-out solution to that problem, as opposed to the optimal solution to that problem which probably requires technical expertise to identify.

And then the other is that if you don't have that context, as you said, you're making just hundreds of micro decisions: exactly how should the layout be, and how big should this button be? And, you know, how bold should this promotional item be? And unless you have a sense of the intent for the audience, you're not going to get those right.

David Subar 05:38

That's right, exactly right. That is the ultimate measure of this stuff is: Who did I serve? Who am I trying to serve? What does it mean to serve them and is the thing that I released-- did it serve them better or worse?

Peter Bell 05:56

Absolutely, so I can understand why that would drive towards a focus on product. What did you find the experience of managing like? Firstly what kind of management was this? Was this line management? Was it product management, project management? What combination of things were you actually doing?

David Subar 06:14

I think the answer is yes, right?

I mean, I started out as an engineering manager, right? So managing engineers, and just doing that kind of thing; and it was a combination of technical management and people management.

It was a mix of a bunch of stuff, but as I progressed and as I got to larger teams, you have to abstract that away, and you have to have-- how do you have that conversation with your team to empower them, and have them be able to create great stuff?

And as I started doing product, it's a different set of skills that people have, so you have to be attuned to different conversations in different asks. But at the end, it's, you know, it's that same thing about who do we serve, and are we doing better, and if there's a delta between what we're getting and what we thought we would get? That's interesting, what did we learn? What are we going to do? Even if delta is positive or negative, right?

Peter Bell 07:11

Makes perfect sense; talking of the consulting you do, because I think it opens up the area that I'd love to dig into, which is how senior engineers and leaders and CEOs can do a better job of managing expectations and communicating effectively with their business stakeholders, the CEOs and people like that.

I mean, from what I understand quite often, you'll get called in by a CEO. What did they say when they're looking for you to kind of do a review of their technical team?

David Subar 07:41

Yeah, so it also to me is in there's are several cases, this is the case where they're feeling anxious

“I've put money into this team, I increased the headcount, I increased the money I'm putting into engineering and product management, and I don't seem to get more stuff out. Where's my money going? Like something seems wrong.” And usually…

“I’m not an engineer. I’ve never been engineer, I've never been a product manager. But there's something that seems wrong here. Help me understand the nature of the work that we do.”

And in turn, I tell people: “We do three and a half things.”

We'll do a deep dive into engineering and product management; and say, “here's some stuff you're doing well, here's some stuff you might do differently, and here's how a diagnosis and a prescription.” That's thing one.

Thing two is we’ll coach CTOs and Chief Product Officers. If they've got a team, they're doing pretty well, but they need a little help getting to the next level.

Thing three is if there's no one in place, we'll go in and put someone in place and fix product management and engineering. Get it to the next level, hire someone.

The half thing is diligence for investors.

Anyway, so in the place where, where they're anxious, they always start it like, “Just do the diagnosis and prescription and tell me where things are at.” And sometimes there's a problem. You know, there's problem in product management and engineering, and we have some suggestion.

Sometimes, it's a communication pattern. The CEOs not talking or asking about the right thing. He doesn't understand the CTO, the Chief Product Officer and doesn’t know how to engage what to talk about. If you're CTO and you're talking about velocity or code coverage like, you've lost your CEO, right?

Those are tactical things, those are important. But those are important downward-facing to think about the efficiency of your team. You want to talk to the CEO about the effectiveness in your team.

How do we move the business metrics we care about? Right, that requires you to be a translator between business and product, between business and technology?

Peter Bell 09:43

What are some of the most common failures? So let's really dive into communication patterns because I think this is the heart of this right? There's a whole other set of things if you've got the wrong team or the wrong architecture or too much tech… that's great. We can cover those in other interviews; but for today, digging into the communication patterns.

What are some of the common failure patterns that you see? Firstly, on the CEO side, are there some patterns where you have to coach the CEO because they have unreasonable expectations or misunderstandings about fundamentally what technology and product do?

David Subar 10:14

Yes. So well, so starting with the CEO side. The typical ones, and this won't, to the listeners, this won't be news, “I want this done in this amount of time with all these 15 features.” Right?

So that's a problem for a CEO. It indicates a CEO who doesn't trust; maybe for good reason but a lot of times, just because they don’t know a different… maybe it's a junior CEO.

You need to help that CEO understand how you're going to deliver value without getting that dig. That is a hard thing to do, but it's possible to talk about this. Or another failure with the CEO is following shiny objects. This was attractive yesterday, this is attractive today, tomorrow this is attractive.

I had a CEO who's brilliant and I said to him-- I'll change his name. “Gary, that's the fifth brilliant idea you've had this week. Is this more or less important than the previous four? Can you just help me understand that?” I said it slightly more nuanced than that, but not that much more nuanced. He was a smart guy, he understood my message.

But with CTOs’ failure patterns, one I talked about, like, talking about tactical information and not about how you're moving the business. Your CEO should not need to understand Kubernetes or what the value of Kubernetes is. Your CEO needs to understand what you're doing to increase some products or increase uptime. Uptime is a business-facing thing.

If you're Chief of Product-- if you're the Chief Product Officer, you need to talk about the same thing: how you're releasing product, it moves some metrics that are important; which means the CTO and the Chief Product Officer essentially have the same job. They need to be working together; if they're at odds with each other, that's poison!

Peter Bell 12:13

So great question about that, because you often see different organizational structures, right? You got a CTO with VP of Product, you got a CPO with a VP of Engineering; or you have two C-level executives, and then the potential risk is that you end up kind of bringing every disagreement to the executive team rather than dealing within the product and engineering orgs.

How do you think about the relative strengths of Chief Product Officer versus CTO versus having both?

David Subar 12:42

So there, I find patterns where each of them are appropriate in different places.

Now in a particular company-- like I'm working with a company now that doesn't fit one of my standard patterns and I'm doing something a little differently with them… but let me tell you the standard pattern first:

In a B2C company, my strong preference is the same person holds both seats. Because the data comes in through the product, almost 100% of the information about what people want and how they're using it comes through instrumentation about the product, or when they click that button, they didn't click this button. They're using this feature more and not that feature, right? There's one data flow in most B2C companies.

In most B2B companies, there's data from the product, but there's a lot of latency there; and there's data from sales and marketing. There's an abstraction between the usage and how the product is, between the needs and understanding; and in those cases, that CPO’s vision-- the CPO’s remand is broader. And so often, having a separate CPO from a CTO in those kinds of companies, that pattern often makes sense now.

I'm working with a company right now, it's growing quite quickly; but I'm suggesting the combined pattern, even though it's a B2B platform company. That’s because that company-- it was started by two co-founders, and they're being very, very successful; but they've never had these roles before. So they can't provide value to the CTO and Chief Product Officer about how to work together.

One of my management philosophies is: it's very obvious what someone who reports to manager has to provide to that manager-- get this task done, get that task done.

What's less obvious is: What is the responsibility of the manager to the person who reports to them? Among them is setting context; among them is having conversations. In this company that I'm talking about, the COO doesn't have experience. So to have a combined CTO and Chief Product Officer makes sense for this company at this time.

Peter Bell 14:58

Now, some exclusive offers from our partners, Amazon Web Services offers a broad set of global cloud-based products to equip technology leaders to build better and more powerful solutions.

Partnering with CTO Connection, AWS is now offering an exclusive program to our listeners. The partnering lends up to $100,000 of AWS credits; a free consulting session with an AWS Solution Architect to review your environment, your strategies, and optimize your costs; and other resources to help you to get started on migrating to AWS. If you're interested in learning more, please reach out to aws-cto-program@amazon.com

To lend a hand to those ramping up remote engineering processes, Cold Climate is offering the CTO Connection community 45 days of full access to their engineering analytics application, no strings attached! Velocity turns SCM data into actionable insights so leaders can get visibility into the speed, capacity, and output of their newly distributed teams.

Your 45-day package will include access to the full capabilities of the Velocity professional package, a consultation with a Product specialist who will map your key initiatives to data, and a training session for engineering managers and executives about how to interpret and apply these data in a way that engenders trust.

Cold Climate hopes that this will equip Engineering leadership to take on a new set of challenges in the weeks ahead. To request access, head to coldclimate.com/CTOconnection and use the code: CTO Connection.

----------------------------------------

Peter Bell:

When you think about building the communication paths between say a CTO and a CEO or business stakeholders, do you have any advice? How do you start that process, right? You know that first 30, 60, 90 days… “Congratulations, you’re CTO or some hot startup, or some manufacturing?”

What are some of the first things you'd recommend to somebody thinking about building credibility and good communication paths with the CEO and other business stakeholders?

David Subar 16:55

So perhaps a slightly different pattern if the company has been around for a while than if it's new-- the company probably doesn't have any structure.

So to say, here are the meetings we're going to have and here's what we're going to communicate and be the person who initiates those processes. You know, let's say we're running Scrum and we have two-week sprints. Here's the way we're initiating epics. Here's the way we're thinking about product roadmaps. Here's the way we're doing inceptions. Here are the points that you're going to see stuff. Here's where we're going to do demos. Right? Have that communication, have things that are obvious, but set up that pattern.

If you're coming into a company that's had a CTO, and maybe that person left under not so exciting circumstances… one of the best things you can do to create credibility is go to the CEO and say to that person, what were the three biggest concerns you had, with the last person in my seat? Figure out a way to knock those off, to solve those problems upfront because that's going to change the tone of what the CEO thinks about the chair you sit in. The CEO has a choice to make: Are all CTO is bad, or was it my last one? Right?

That choice they're making may not have been fair to the last one, but you have a chance to reset the table. So knock off a few things that are really top of concern at the same time. Like you have to have credibility with your team, you have to provide value to your team, you need to be doing that too. But the show pieces are: “I'm going to hit, knock those three out in the first 60 days, first 90 days quickly.”

Peter Bell 18:41

And then if you do have the CEO with like shiny object syndrome, right? It's like, “but we should build this.” And I worked for one at a startup a few years ago. What are some general patterns or things that you've seen really work well for helping maybe even less self-aware CEOs than the one you were talking to, where you just like dropped a hint, and they got it?

How do you help your CEO to focus better on what actually matters?

David Subar 19:05

First question is what is fundamentally important to the CEO. And there's always a set of things, right?

Even CEOs have bosses, right? They might be reporting to a board of directors and not likely to be the majority shareholder. And so, what are the metrics we're trying to grow here? usage, decreased churn, revenue?

And I would use that as a foil to say, “Here are the things we're working on. Here's my opinion about which of these are going to affect the metrics that you most care about.”

And I would just keep going back to that.

You will hear either, “You don't understand why this one I just mentioned affects the metrics differently.” They might be right. You might not understand, it'd be important to understand, right?

You might hear “Those aren't actually the metrics that matter.” That's interesting too, right?

But you might hear that, “That's interesting. Let me think about that.”

Now, every personality is different, right? So how you approach them and-- how directly you approach them about that, you have to sense from the situation you're in.

But people just tend to be not-that-complicated. And if you really don't understand why they're doing something, there's some data point you don't have. And it behooves you to discover that.

Sometimes you might have a CEO who's just ignorant. First time at bat, that person might be scared. How do you make them comfortable? They're running after something. Your job is not just to write code, or to have a team write code-- your job is to help the company be successful.

Peter Bell 21:00

So another thing I've seen a number of times, especially with, like, CEOs with a sales background-- it's not uncommon, and sometimes with a finance background-- who's like, “Yeah, but I just want the team to go faster.”

How would you recommend a CTO engage with that kind of “Yeah but, but more. You know, can we just like whip them harder until morale improves?”

David Subar 21:21

Right, right. That's very-- there, there's two patterns.

That's one of the patterns with sales CEOs. Let's talk about that one first: “They should be doing more. Like, I just know, they should go faster.” And the answer is, “Yes, you're right. I, of course, want them to go faster. We all want them to go faster; they also want to go faster. Let me tell you about how we measure that, it’s not lines of code, right? It's either those metrics I talked about before-- I'm not gonna belabor them again here—or, let me tell you how we constantly ask ourselves that question, what can we be doing faster?”

This is a conversation where you might have a conversation about tech debt; but I advise you to be very careful about that. The definition of tech debt is: that which impedes us, not that which is inelegant. Inelegant in a part of code that I never see, I don't care.

So I might say to the CEO, “You're right, we've been looking at that. It's something we talk about every week.” Or every two weeks, whatever your-- if you're running Scrum, whatever your sprint length is; or if you're running Kanban, however your process flow is.

“And let me tell you some things that we discovered in places we're investing to address that; and since we do this every whatever—" if your frequency is every two weeks, “I'm glad to engage in a conversation every two weeks. Do you want to talk about that?”

No, they don't. But they want to know that you're thinking about it. So you'll do it once, and you'll do it the second two weeks, and you'll do it on the third iteration.

And then you ask the question again-- first time, they'll say “Yes, I'm interested.” But the third one, they’ll go, like, “Oh, I don't have time for that. I sense that you have the ball here.”

And periodically you need to go-- because this will come back-- and periodically, you need to go back and say, “Remember this thing we're talking about? We haven't talked about it for two months, let me just give you a 10-minute refresher about what we're doing about this.”

Right? You're selling to your CEO, you're educating your CEO on something they're not familiar with. So that's one pattern with sales CEOs. Some are like, “I just need to close today’s sale. I'll do whatever! This is a big sale, whatever I need to do to close this sale.”

Peter Bell:

And that's especially with like the enterprise deals or the partnership deals where you have one client that's potentially going to affect your roadmap, and they think it's important to focus on.

David Subar 23:51

Exactly. And if it's a giant company and it happens occasionally, that's probably the right thing to do. If it is something that happens every week, that's probably really distracting.

I have a client who's like this; and this is an advantage, this is a place where I'm advantaged to the CTO because I can go to the CEO and say, “Let me tell you what you're doing. I understand that you're trying to get this metric but you can't, you know, you can't change-- I can have that conversation as an independent entity, to say, “You're making a mistake here that’s harder for the CTO.”

But let's say I'm not in the room, because some of my job is they hire me to coach the CTO, but part of the job is coaching the CEO… I kind of hinted at that before. I get to do that but if I'm not in the room, the CTO needs to say when they switch, “let me tell you the effort I am going to throw away to do this. We spent three weeks. No problem, glad to do it.”

And then you have that conversation again… spent two weeks just throwing that away.

But you know, “you're sure you want this? Great, you're sure? That’s great. I'm gonna throw away these two weeks of work. Cool, great.” Right? Be sensitive about that pattern but present that pattern-- not just “you're pissing me off about the thing you're asking me to do. But we're throwing away some effort.”

And then you can engage in the conversation of, “Can we be more thoughtful about what effort we go to so we don't have to throw these away. We've done this like three or four times. I want to-- I want our team to produce faster. Can we talk about how we can be more thoughtful about what we need? So we don’t have to to throw away the two weeks and the three weeks, time and time again?”

Peter Bell 25:50

That makes sense. So we've spent quite a bit of time talking about different types-- different patterns for CEOs. What are some of the patterns you see, especially in failing, for CTOs? Like, what are some of the patterns you see? And some of the ways that somebody maybe who sees that in themselves could address and improve?

David Subar 26:13

Well, here's one. Here's generally the first pattern: “Tell me what you want. I'll tell you when I’m going to give it to you. Don't bother me till then.” That works great if you get every one, right. I don't know anybody who does.

The next pattern: “Tell me what you want, I'll tell you what you're gonna get it, and you can go on JIRA and see where I am at any point. It's all right there, just one URL away.” Or pick your tool-- Trello or whatever. That fails because no one looks there; and if they do, they don't understand.

So that leaves the only thing that works is: “Let's talk about—" I'm skipping a few—“Let's talk about what we're going to build and why? And let me demonstrate to you progress.”

Now, here's what's often missed by CTOs. People get freaked out by, we’re given the specific set of features we need to build and specific timeline… and how can we possibly do that? And that's very common.

And by the way, I favor time boxes. I favor being given a timeline. But the feature set is ambiguous. It's always ambiguous, ambiguity is your friend as a CTO-- you get to declare success around a time box, as long as you're reasonable.

I want to—I’m making something up—I’m Uber, and I want to have Uber Eats except that I want it for only hot pizza that's delivered on a-- I don't know, making something up. You got two months to do it? Great. I'm only doing deep dish. I'm calling that success. You only get pepperoni. Right?

You can win as a CTO with a time box and a set of features because you can define on the fly what success means. And by the way, your Chief Product Officer is also incented to do the same thing.

Don't pick something stupid like anchovies! There's people that like anchovies. My father liked anchovies, but like, he was at best 10% of the population. Everyone seems to like pepperoni, unless you're vegetarian.

Peter Bell 28:35

So we've gone through some of the types of CEOs, some of the types of CTOs, do you also notice that there are like, some clustering patterns around people who were maybe a little earlier in their career? Like some things that you see on a more regular basis with less experienced CTOs, maybe people are first time at bat, or they've only been doing this for a couple years?

David Subar 28:56

Yeah, oftentimes, the folks that are first time at but are the best coders in the room, and that is a great feature to have and often not helpful in that seat. That person tends to have empathy with other engineers, and there's some really good skill like understanding elegance and architecture and algorithms. Really, really good; really, really important.

Understanding team dynamics and how to manage a team? Those aren't things that are given to you if you've been the best engineer. This is what I tell those people who think about managing this way, and this goes to a theme that I've hit on twice already:

Your job as a manager is to set a goal state you want your team to get to. Be very clear. “Here's where we need to get to.” Then your team gets to ask you a lot of hard questions. They get to ask you questions because maybe you didn't communicate well. Maybe they didn't understand. Maybe they knew something you didn't know. They get to challenge the goal set.

After you're done with that, and you set the goal set, you've agreed-- you get to tell the team, “go away and figure out how you're going to solve it.” You no longer, as a first time CTO, get to tell the team how to solve it. You get to ask them to go away to determine how to solve it, then you get to ask them hard questions.

You are going to have broader purview than they do; you're going to know things and have broader interactions that they won't know. They're closer to the code, closer to the data-- they're going to know some stuff you don't know. You need to ask and not tell. If you tell them, they'll tend to do what you want, what you say. It may not be what you want, but what you say. People tend to listen to their boss a lot. If you ask them, they'll tend to be thoughtful about the answers and, the next meeting they come to, they'll tend to have prepared a lot more.

You might not have communicated well, you might know something they don't know. They might not—so, you know, ask them a bunch of hard questions. They should be hard. Now you settled on the goal set and the solution.

Now your job is to get impediments out of their way. What do you need? Garbage can needs to be emptied? I'll do that. I'm good. You guys need, you know, new credits in AWS? I'll figure out how to get that done for you, right? And your job is to check in with them, a regular pattern of check-in, so that they hold themselves accountable. The teams hold themselves accountable, not so you hold them accountable. That's what you need to know.

Peter Bell 31:45

And do you notice like, as engineering team size grows, the one thing I've heard a number of times is, you get to a certain level of authority in size of organization where, you just-- you know, you make an offhand comment in the elevator, back when people were still taking elevators into buildings. And before you know it, there's a task force, and there's like, 15 engineers working on it, and there’s prototypes. We developed a huge like-- I thought it might be cool to find out if x was possible. And suddenly somebody comes to us like, “You realize we're spending half a million dollars prototyping this thing? Why did you do that?”

Have you come across those kinds of patterns where you have to be much more constrained in how you communicate in front of your team?

David Subar 32:28

Yes, 100 times. And that's, you know, I was just talking in the case of small teams, and you’re talking in the case of larger teams. And what you're saying absolutely happens on larger teams.

Just a little background, I've worked with a bunch of small startups, but I've also advised the Disney ABC Television Group at The Walt Disney Company. Their tech team was pretty large, right?

And so that exists-- the power of the office is a significant thing; the offhanded comment, as you say, tends to move people; and so, there's different conversations to have and some conversations not to have. So in that seat, I would often ask, you know, not—this was ABC television-- I was consulting to the CTO, I wasn't the CTO-- but I would often ask, “What are you guys working on, on a frequent basis?” To address that problem but to also like-- you need to be able to ask that question of “Where are you compared to where you thought you would be?” Some of that is on product, some of that's on personnel.

“How are we doing with recruiting? Are we recruiting the right people? What are people being assigned to? Help me understand how you made these decisions.” You uncover things that way. But the other thing is, you need to absent yourself from some rooms. There are some meetings that you need to choose to not be in, because your voice is loud, even when it's soft.

Peter Bell 33:56

David, thank you so much for taking the time to share the advice and information. I really appreciate having you here.

David Subar 34:03

No problem, thank you very much for having me.

Peter Bell 34:08

This episode was produced by the amazing team over at Dante 32, a podcast production agency focusing on content strategy, audio production and distribution.

Check them out at Dante32.com. and if you'd like to receive new episodes as they're published, please subscribe in Apple podcasts, Google podcasts, Spotify, or wherever you get your podcasts and if you enjoyed this episode, please consider leaving a review on Apple podcasts. It really helps others to find the show. Thank you.