The Blog

Schedule a Consultation

Have you read our blog and still have questions? We offer no-cost consultations to portfolio firms and organizations seeking further advice or assistance in strengthening and growing their Product and Tech teams. 

Sign up now to schedule your session with one of our expert principals. 

Recent Posts
What's next?

Interna principals present at events worldwide. We send out a monthly newsletter with information on where to find us next and how to stream our talks to wherever you are. Our newsletter is filled with additional tips and tricks for executive leadership and the latest stories in global tech news.

 

Stay up-to-date by subscribing to our newsletter using the button below.  

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.