CTO Craft Fireside Chat: Dan Smith interviews David Subar

David's Notes:

I was a guest on the CTO Craft Podcast hosted by Dan Smith. We had a great conversation about CTO coaching and the best practices for rookie and experienced CTOs that want to make a difference in their companies. We also answered the audience's questions regarding a wide variety of topics ranging from learning how to pick the right coach to how to share your vision with your team and communicate effectively with them. Feel free to listen to the podcast above and ask me questions as they occur to you.

Here are the key moments from today's topic on aligning goals and actions:

0:00 - Introductions by Dan Smith

2:40 - Aligning products and Engineering Teams

5:40 - Targeting and knowing your demographic

9:50 - Dealing with Shiny Object Problem - Dealing with changing priorities

12:45 - Proper communication and outcomes

14:30 - How to pick a CTO coach?

19:31 - The value of mentoring over teaching

22:03 - How to help Technology have a seat on the table

29:20 - Should I have more than one coach?

32:30 - How to progress into a CTO role

38:16 - If there isn't a budget for CTO training

40:45 - How a sales focus CEO could cause issues to the business culture

43:10 - How to choose the feature and determine their value

48:48 - How to communicate the road map to your company

54:18 - Tips for working with an inexperienced CEO

Transcript:

Dan Smith:

Hello everyone and welcome to the latest edition of CTO Craft Bytes. Today, we're going to enjoy a fireside chat with David Subar. If this is your first time at a CTO Craft Bytes event let me tell you a little bit about the group. CTO Craft is a mentoring and coaching community for technology leaders around the world, focusing on supporting technologists in their leadership growth. There are over 7,000 members and CTO Craft provides one-to-one coaching, mentoring groups, a curated snap community, and events like this one.

If you're not already a member and are interested in becoming one and enjoying events like these, then I will post some links for you here to join and sign up. Special thanks to our headline partner, AWS for making these events possible. My name's Dan Smith, for those of you who don't know me. I'm an executive coach. I perform technical product due diligence in the M&A space. My guest today's David Subar. He's a former CTO and chief product officer.

David is the managing partner of Interna, a consultancy that enables technology companies to ship better products faster, align products and engineering teams, achieve product-market fit more quickly, and deploy capital more efficiently. He's worked with companies from small startups right up to the Walt Disney Company. Welcome, David.

David Subar:

Thanks. Glad to be here.

Dan:

Excellent. The audience, I'd like to ask you for a favor we're going to be topic covering topics ranging from tech effective team collaboration and alignment, to getting support as a CTO. David's going to share some lessons he's learned as a CTO coach, but what we'd really like you to do is ask the questions that you'd like to have answered. If you look down the bottom there, there's an ask a question button, please get typing and I will endeavor to read all your questions. I think also there's a function to vote.

If you like the question and vote it, then it should shoot up to the top of my screen, which will help me to identify it. Let's kick off, David. It's great to have you here. Maybe you can tell us in your experience, what has and hasn't worked when aligning products and engineering teams.

David: Let me give a little more context on my background so people can understand where I'm coming from. I think you mentioned I've been CTO and chief product officer of a number of different companies. In turn, which is I've been doing, or it's been around for the last nine years. I've been doing it for the last nine years. We do coaching like you we do deep dive into product management and engineering. We see a lot of different teams and a lot of different teams, sizes dynamics that work. We do fractional work, right?

We are able to dig in and we do diligence also like you for PE firms, VC firms, that kind of thing. We see a lot of different kinds of things, company sizes, different stages, but there's some things that remain true no matter any of those criteria. What industry you're in B2B, if you're B2B also, if you're B2C size, which is things tend to work best when people have an aligned mission. If engineers think their job is primarily about writing code, I write good code. I do good architectures or algorithms are all log in. That's important, it's necessary, but it's not sufficient.

Same with product managers. If they think their job is about writing user stories and that's it, and they just throw them over the fence to the engineers, bad things tend to happen. If on the other hand, both groups think, "We are here to serve a customer," and what we're building either does or doesn't serve that customer, then they'll tend to get aligned. That's the key is having the teams or the team-- Actually, I like to think of them as one team, product management and engineering know who they serve and have a joint mission in doing that, which has a bunch of implications about what code do you build?

What features do you build? How do you build it? How much do you invest in architecture? How do I think about how do I learn about how-- All has implications in all those places? I'm glad to talk about what each of those means specifically, but fundamentally it's about who we serve.

Dan:

Excellent. Maybe we can dig into later to some of those in more detail, and there's obviously a lot in there. What have been the best ways that you've found to help teams to be effective?

David:

The best is we do start with that motivation. Do know who you serve? It doesn't actually start with product management engineering, although it has to be there. It starts with the company, it starts with the CEO, and the CEO in the company having a reason to be. We start by asking that and we see if there's a consensus or not. Then we go and we look at, okay, great. Now that we know who we serve, what's on the roadmap and why? Both. Do what's on the roadmap? Do you know why it's there? Is it specific? Is it measurable?

There's a formula that we use, but there's other formulas you can use and I'm glad to share the formula. As far as how do you consider everything on the roadmap, as far as whether it should or shouldn't be there and whether you know it's there. Then are you measuring not just sprint velocity or whatever developed methodology you use, but are you measuring the efficacy of things after they get released? Does everyone know engineers can do things a number of different ways? You could code things a whole bunch of ways.

The good engineers, in particular, will tend to pick what methods that are good methods. Often it's good engineering methods but if they know the context of the why, they'll tend to pick things that help expand the product appropriately. We ask all those questions, we ask engineers, "Do you know why you're doing this?" Scrum, by the way, does this really well with user stories about how asking a particular user story, why somebody wants this user story, isn't particularly great at pulling up the product level. It's silent on that.

One of the things we do is we ask the engineers why it is, and then we do the standard stuff and ask questions about architecture, right? Architecture still matters algorithms still matter. I want the engineers to be so engaged they're asking product managers not just why we're doing this, but, "Hey, I could do what you're asking me to, and that's going to take three weeks. We could do that, but here's something else we could do that will get you 80% of the way there and just will take a few days."

I think this makes sense because of that, right? I want them to be engaged with not just being a receptacle of things, but being engaged. I want them to be missionaries, not mercenaries. Product managers should feel the same way about engineering. Tell me about the architecture. Could we do this or that? That's helping. We don't see that. We start asking why, and we dig into what prevents it. Could be org design structure could tell you about stuff at some of the companies. It could be just company culture. It could be process, right?

It could be architecture. We have one client where there's architectural issues that create bottlenecks that prevent this kind of conversation, but it could be a lot of things. That's where we start digging in.

Dan:

Great. Thanks, David. I see one question's come in. The rest of you are being a little bit shy, so please do ask questions and if it's something more specific as well, like David's mentioned things he's experienced. Obviously, we are not in a confidential environment, but if you wanted to do something more situation-based, feel free to add the questions. Please do keep them coming. I just wanted to go back there. David, you mentioned about the CEO. Something quite often asked and quite often comes up in the circles, that I run is about CTOs who are not necessarily aligned with themselves. They tend to go in one direction and then maybe U-turn and then turn left. How does a technology and product team deal with that? Is it a lost cause or what can you suggest as to help in that kind of situation?

David:

CEOs that change you're saying or CTOs that change?

Dan:

CEOs.

David:

This is difficult or this can be difficult. There's often CEOs who have shiny object problem. Here's the thing I've thought about today and it's great. We should do this and yesterday there was another idea and the day before there was a different idea and the day before there's a different idea. Actually, when I was CTO for one company, I had this exact situation. It's sadly not uncommon and there's a couple ways of dealing with it. This is actually a place where a third party's really helpful.

Having someone either coach the CEO or looking at product management and engineering and having the CEO. If you don't have that-- the situation I had was much like this. There was two things that that we did. You often find the CEO in this case is doing this not just to product management and engineering, but might be doing it to sales, marketing, and to other departments. Making your colleagues, your friends in solving this and having this joint conversation. Having a joint conversation with the CEO or several independent conversations tends to be helpful.

What I said to this particular CEO was-- Keith was brilliant. I said, ''Keith this is a great idea''. This is actually your fifth great idea this week. Help me understand how to stack this against your other great ideas. I started engaging the conversation with, "This is interesting. What do you think-- Why we--" Oftentimes what you see as answers in these situations from the CEO was, "I heard this thing, the market shifting this way so we should just go do it." The idea I want to get the CEO to is grounding them in some recognized truth.

Whether that's data or not, there's a problem I'm going to bring up in a second and I try to get them that this is where the conversations with the other executives help. This is also in particular with the chief product officer and the CTO together is particularly helpful. You can also talk about outcomes, like, "We're three-quarters away of doing this project that we think is going to have this impact. Let's not talk about the sunk cost. That's not interesting, but we're now like three weeks from delivering this thing that we think has this potential outcome.

The thing you just told me about is going to take six weeks or four weeks to get that potential outcome. How do we weigh this? If this is so important that we want to spend the extra time, the six weeks versus three that's remaining, then we should do it. I got no problem with that, but let's have the conversation about what the weight of these things are. With Keith, he heard the message from a lot of the executives and over time, it's not something that gets fixed in a day or a week. Smart guy, he said, ''I'm hearing this a bunch of different places. Maybe I should consider it."

He did reform, but it took a while.

Dan:

I like the way that you said, oh, they're all good ideas, so really encouraging rather than a negative way so that's really an encouraging to find the solutions. Great. We've got a couple of questions, so do keep them coming in. Don't forget, you can also vote on them so I think. I just voted on that one so vote on the ones you like. Megan's asking, "What should people look for when picking a CTO coach? With remote coaching how can you help foster relationship when you're not able to meet face to face, especially with time differences?"

David:

None of the people that we coach are local, so in picking a CTO coach, first of all, I would say, do they have a methodology that rings true to you? I'll tell you what we do in a minute. That's the first thing I would look at. Second is do they have experience in coaching and experience in what you're doing? I think you want a good coach. Someone who has the skills to coach, but also to the extent that they have been a CTO before have done what you've done before, they're going to be able to give you some pointers.

Then the last thing is chemistry, so methodology, experience of coach, experience in your area in chemistry. I would say those are the four most important things. This is how we think about methodology. We go and say, "Where is it that you want to get to? What are your goals?" We list those, then we go and we do a 360. We say, "What do the people around you say are your strengths and your weaknesses and the things you should work on?" That's the second stage. Then we triangulate those. "Here's what you said about yourself.

Here's what the environment said about you.

Let's revisit your goals and see if there's anything you want to change." The answer could be no, but it's frequently yes. Then we set out a road map. Here are the goals, but here are the steps you want to take to succeed in those goals, we put them on a road map. Then every time we talk, we talk about how did those things go? We also talk about what happened. What happened that wasn't directed into the goals that you want to have a conversation about? We take the steps and like all good agile processes, at the end of a certain time period for us, it's typically six months, we'll say, "Let's pop the stack.

Let's look at where are you against your goals and then let's repeat the process. That's the methodology we use. Other people use different methodologies. We've all been CTOs and chief product officers, so it's not surprising we retro everything we do. Over time, we've honed the methodology and this seems to work really well. That's the methodology. Second is tell me about some examples you've been coaching. You obviously can't tell confidential stuff, but how does that work? How you think about, can you give me some examples?

Third is what have you learned in sitting in the seat if you've done this job before, what does that look like? The key, there's a big difference between teaching and coaching. We hold that you want to have someone who's generally more of a coach than a teacher. A teacher will tell you what to do. If you don't know how to do it, you want someone to tell you. Having those skills, if there's an area that you're completely unfamiliar with having someone who can be a teacher as well is helpful, but we hold that.

Maybe that's a quarter of the conversations, and the rest is coaching, which is about asking questions. We tried to ask intelligent questions based on what our experience was and based on what we feel the person that we're coaching will work best for that person. It's better for the person to discover themselves what the answer is than to be told what the answer is. That's why we favor coaching over teaching. With people that we coach, if someone just says, "I have no idea what to do here," we can say, let me show you examples.

The situation I mentioned with Keith, here's some examples of places that we've faced this and how we've handled that. How would that work for you? The last thing is just chemistry. How does it feel with this person? Can I be forthright with this person? Do I think this person is going to be a good partner for me in my journey? Those are what I would look for.

Dan:

I think I agree with you on all of those points, especially, and I guess I call it mentoring instead of teaching. We could probably have a whole separate discussion on the meaning of those, but I guess the way I see it is I want to hear what the client is thinking and him or herself. Then potentially some offering some extra things. Have you thought about this? Would looking at this be appropriate and then see where that goes. I agree that as a coach, we don't know what living life is like as that person.

We don't know what working in their company is. We only have some insights from what we pick up. They're the experts in it, and we are helping them to become clearer about what challenges they're facing and how to achieve their goals. Absolutely I agree with you there.

David:

I think it's a very excellent point. Sometimes on that, we'll do some role-playing. Let's say you are the person we're coaching, you are the CEO, what would you think the CEO would react to if you said this? Or, you be you and I'll be the CEO. Walking through the situation. Sometimes these situations are very broad and they seem scary, but they're not actually dangerous. Having that conversation and doing some of that role-playing through a process when it's dealing with the CEO or dealing with the board has to be helpful.

If it's going down and looking at architectures and things like tha, well, then those things don't need that kind of practice. We can say, "Here's some things that we're seeing in the market that seem to be appropriate, these may or may not be appropriate." It's very different whether you're helping someone look up, helping someone look at technology things that you don't have to be sensitive to. Thinking about how they deal with their personnel, the people that report to them, which you do need to be sensitive to, but your role is very different.

Someone that reports to you versus someone you report to.

Dan:

Great points there. I definitely also agree about the chemistry, I think that's really important. We have another question in from Peter. How to implement across functional collaborative culture. That's quite hard to say, in the environment where tech is not considered as equal partner to the product being treated more like an implementation partner or assembly line. In your experience, have you learned what methodologies, frameworks work best in environments like that?

David:

I don't know if Peter can respond. Peter, you can respond to this. Is this A, a technology company, B, is technology a cost center or a profit center? Maybe a different way to say it, in the case, it's a technology product company, is technology the cost center or considered a profit center? Then lastly, I'll ask the last question. Is this a B2B company or a B2C company?

Dan:

I think Peter should be-- Here we go. He's writing into the--

David:

Media streaming company? Okay. It's clearly a technology company. Is this streaming to consumers or streaming to corporations? Is it an infrastructure tools company? B2C. Oh, great. Okay. Thank you. The good news about being in a B2C company if you're in technology is that you are directly aligned to revenue generation generally. I need to know more about your company. It's not appropriately perfect to ask in this environment, but the things that you do and you know this, can tweak the revenue, can tweak the profitability.

This is not uncommon, you find yourself in a position where they're asking you to be mercenaries not missionaries. Just do this thing and I will pay you. Don't worry about the why, do this thing. Shut up do this thing. The question I would have is that being driven by the person who runs product or the CEO? Who is creating this environment? To the extent it's the person running the product and not the CEO, then I would-- Peter, I'm glad to have an offline conversation with you about this longer and more in-depth and spend half an hour with you talking about it.

No problem doing that. Dan will give my contact information at the end, if you're interested, just reach out. I'll talk about and do it. I would have a conversation with the CEO and say-- I would have that same thing that I said before is, "My team is multiple ways of doing anything. We're losing our ability to have them engaged and choose the right thing because they don't know the why, and they can't engage in the why. The second problem that I have CEO, is that engineers all have a choice and jobs.

Even in this recession we're in, they have a choice and place to go, and someone else is going to offer them more money. We know that. Maybe some Facebook or Google or Amazon, someone else will offer them more money if they're good. We need something that keeps them here that's intangible. The intangible thing that we have is this product and the why we want them to engaged in that. If we have a cool product and we're in a cool market, that's something they can't get somewhere else. We want to decrease personnel churn.

We want them engaged, but there's some other reason we want them is that they know things a product manager doesn't know because they're closer to product. That's if the chief product officer is creating this issue. There may be org design issues and alignment, and who reports to whom and to think about there. If it's the CEO-- Actually two cases, the CEO and the chief product officer agrees with the CEO, or the CEO and the chief product officer does not. Let's do that latter case first.

Then make the chief product officer your buddy, and start having the conversations just among you in a small scale. You can't do it in a big scale yet. In a small-scale ad as you show success in that, then you'll be more and more empowered. Steven Covey had this thing when working for a micromanager, do everything the micromanager suggests, and then do a little more. Just do a little more that isn't asked and to the extent, you're providing value, it behooves the person that you've done a little more for to give you more and more power over time.

Once again, this is a slow game. If the chief product officer and the CEO agree that you're meant to be an order taker, and that's it, I would still suggest that you do a little more, but you've got to make one of those people your buddies. If at the end of the day you can't move either of them, you might have a job decision to make. Not everything is fixable, but generally, there's one of those two that you can crack. One of those two that it's a little easier to crack the chief product officer than the CEO generally because they have direct benefit.

They can see how the teams work. They're generally better than the CEO, so one of those two. I will tell you this is even harder when your CEO is just a pure salesperson and just looking at the revenue from right now. That's harder. If you have that case, you might have a cultural problem that's not fixable. Let me say it that way. Hope that was helpful. Once again, Peter, if you want to chat afterwards just reach out.

Dan:

Yes. I will post David's contact details towards the end in case you want to do that. Right. That was an excellent answer, David. Let's have a look. We have a couple more questions coming in. We have one here about keeping up to date, hard to keep up to date with the latest technical updates. Because of this, should a CTO have more than one coach, one for business management support and another for technical support? Can you get too much support as a CTO?

David:

Sure gee, if you have the time and the capital to pay for two, actually I was going to say, sure, go ahead and do it. I suppose if you have enough time and enough capital to pay for two, sure. Then you're going to want the two of them to every so often have conversations between them. When we have multiple coaches in the same company, we typically, one person coaching one person, one person coaching someone else. Those coaches will talk confidentially about what they're hearing to help like, "Oh, I'm hearing that, oh, I'm hearing this."

Those aren't the same thing. That's interesting. There's some communication problem here. If someone had two coaches, I think I would want them to talk so that they could also triangulate. I think I prefer to have one coach per person not two, just because things were not lost in context. If that one person had both set of skills adequately. The thing about coaching is, it takes engagement to have success on it. Obviously for the coach, but for the person who's being coached. Some change is easy, but if it was easy you probably would've done it yourself already without the coach.

You should expect some of this stuff is going to take a little time and some of this stuff is going to be hard. Some will be just, oh, you've been given perspective by the coach and that's sufficient and that's enough to make the change, but you should expect some iterations. Having two coaches will expect more simultaneously. Be thoughtful about it. Depends who the coach is going to be. Sorry, that was not a succinct answer, but I would be thoughtful, but I think I would prefer one coach who can think about here's all of the things that are going on, and here's how they should be ordered.

Dan:

I think I would agree with you as well there. I always say to my clients that most of the work should happen between the coaching sessions, because the sessions are about raising awareness and creating actions. Then it's about going away and doing them and seeing what happens. Sometimes those things are not as easy or not successful. Then the client can bring those back and then we can have another iteration. I imagine it could get confusing with multiple coaches in knowing-- there could even be potential conflicts between the kind of actions created.

All right. I will mark that one is done. Another great question. I don't know how I pronounce that. Manognya I guess. "I'm currently working on my development plan and I'm wondering what should one focus on to move on from director of engineering to CTO? What does one do more of or less off?" Another great question?

David:

I think the answer to this question depends on what does a CTO mean to you? It's not a well-defined job. Some CTOs are the person that translates between the strategy and the execution on technology. It's a perfectly fine definition. Some are the best technologist in the room, maybe the best coder or the best architect or something like that. Some are effectively the way I consider a VP of engineering. That is just about how do I get the team to execute best. I think you first ask yourself, what kind of CTO do I want to be? What does that perfect job look like for me?

Then you can say, here are those skills that I have. Here's the skills that I don't have and how do I achieve them? You might achieve them by modifying your current position to stress yourself in those things you don't know so well. Maybe you find a mentor, maybe you find a coach who will help you through that journey. Maybe you find a different job that helps you get there. I think it fundamentally starts if you want to be a CTO, but let's not be so talmudic about it. Let's dig in with a couple different cases.

Even the first case, if you want to be the CTO is the translation layer, then you need to-- I'm assuming you have good technical skills. Can you describe those? Describe technology to non-technologists? Can you state in two sentences into a way that your father or your mother or your cousin, who's a stockbroker will be able to understand and get. Then can you go, and from the strategy standpoint, do the translation the other way? Say, "Here's where the business is. Here's why it's there. Here's what the business wants to be when it grows up.

We have to take multiple steps to do that. Here's what we're going to do and here's why because here's what their customers want. Here's what's in the market." Can you do that translation? That's one way. If you are the VP of engineering plus plus, what do about methodologies? Those methodologies are not just about software development methodologies, but they might be about recruiting and retention and any number of things. Can you practically apply them? If you are the smartest technologist in the room, what technologies are coming up in strategic that are changing the way product is developed, software is developed?

Are you up to speed on them so that you can then implement the next thing for the company? What do you want to do changes based on those three archetypes of CTOs and there's others as well?

Dan:

Great points there. I guess I'm thinking if this move is within the same company, then what's likely to happen is the transition's going to involve less technology and more business. Exactly as you say, explaining things in more everyday language. I guess the expectation might be to improve your interpersonal skills, listening what the other people at your C level want to hear. What their challenges are, and helping them solve them rather than learning more about technology.

I often find that migrating to a CTO role is quite hard because of the things that people have to let go or delegate. Delegating them correctly and feeling confident in that can cause some angst. Those might be other things to consider.

David:

I think that's a great point about letting go. People fall back on things they're comfortable with frequently. Not just people that want to be CTO, but what is it I'm no longer going to do that I'm going to delegate? I think that's a great point about letting go. What am I going to give up might be as important of a question, as what is it that I'm going to do that I've never done before?

Dan: Hope that was a helpful answer. We have a couple more questions. Hang on. What's going on here? Oh, dear. No one's voting. All right, David, can you see them both? Which one would you like to answer? [laughs]

David:

Yes I can. Boy, I like both these questions. I'll just do it top down. The first one is, if there isn't a budget for a coach, where can a CTO find support? Dan, would you like to make this an advertisement for CTO Craft mentoring circles? [laughs]

Dan Exactly. Mentoring circles is a great one, but also even as a member of CTO Craft, there's a "get help" channel. I can't remember exactly what it's called, but I see that that has a lot of traffic and there's all sorts of questions being asked there. Ask for help. That's a freeway and you could be part of the community and help other people.

David:

Sometimes you'll see me in those channels answering questions and sometimes you'll see me asking questions there as well. You should definitely partake in that. Look at the circles for-- I'm also on the board of the LA CTO Forum, which is a not-profit where CTOs, we used to meet in person back in the before times. Now it's also online, but there's other groups as well. Someone just wrote the Slack community's amazing. You should definitely partake in that. That's what I would share. Should I be the next one?

Dan:

Go ahead.

David:

Oh, Andrew just posted the URL for the community.

Dan:

There's the Ask for Help channel. The general channel also has quite a few related things and then there's all sorts of specific ones. If you have a question about management, leadership, or hiring process, dig in there's a little button when you get in somewhere about adding channels which you might not see. It's a little bit hidden. I think if you hover over channels you see a little plus where you can add channels and then you can see the full list of channels. There's quite often specific ones that might answer. Get one. Talk about the kind of things you want.

David:

Do you want to pick which question to do next or should [crosstalk]

Dan:

Oh there's another one coming in. As I said, I'll also put my details at the end so if you have a trouble finding the right channel, then drop me a line. Let's have a look. Let's go with Ann's one there about tell us more about how a CEO that's a sales guy might create a cultural problem that can't be easily fixed.

David:

The biggest issue I see here is I just need this feature to close this sale is the answer to everything. What you end up doing is you tend to have a very very responsive organization that's building a product for customers and not the market. That tends to look like a professional services company. The code tends to be unscalable and the conversation about tech debt never happens, and eventually, the craft of one-off architectures and one-off code gets to be quite expensive. Engineering slows down.

People say, "This used to be much faster when we were smaller, why can't this be fast still?" Then the CEO says, "There must be something wrong with you guys, and you have to do things differently." Now, there's other reasons engineering can slow down and some of them are unnecessary. I don't want to put all slow-down engineering on the CEO, but there are cases where the CEO is asking the engineering team to go from A to B to C quite quickly. Looking at I'm just trying to close the sale, that sale, and that sale. Over time it tends not to be sustainable.

As opposed to we believe that the market wants this that's represented by these customers, and so we want to build these features and that tends to be a more strategic view. The cultural problem is you built a culture that is very very responsive to the loudest voice in the room, but not responsive to, "Here's what we want the company to be at two years from now."

Dan:

I wanted to ask you related to that David, being more strategic and adding features sounds great but firstly how do you choose the ones that are going to be most valuable? Secondly, how do you even know if they were the most valuable because quite often features get added but you don't really know which ones move the dial on sales or income?

David:

The answer here is different for a B2B company and a B2C company. In a B2C company, it's generally easier to track. Here's what the usage is. Frankly to be fair, that might talk about the reduction in churn more than new sales because the thing that brings you here and keeps you here might be different. You could even measure that to say here are the features that people use in the beginning and here are features that people use over time. You can talk about switching cost and stickiness and things like that.

In B2B it's harder because you don't have as direct time to usage and to people deciding to use it and the consumer. Here is where a place where product really really needs to team well with marketing and sales. They need to survey what's the market, what customers the market say they want, and how that compares to what makes them close a sale. The relationship-- Before I talk about the relationship between product management and engineering being really important and that needing to be tight, you want to have a tight relationship with all your colleagues.

It becomes more profound and more important in a B2B company where there's an intermediary between the product and the user which is the sales channel. I had a VP of sales that I worked with who used to come to me and say, "We really need this feature. We really need this feature."

Dan: They all they say that. [laughs]

David:

They all say that, right? This guy's name was Andrew. I would say to him, "Why?" and he would invariably say, "We've got to close this sale, it's a big sale." We actually set a bar that if the potential revenue for the sale was over X, we would drop things. This goes back to the sales-driven CEO. We would drop things to do it, and if it wasn't, we wouldn't. Then after each quarter, we would evaluate how many of these things that we were asked actually achieved a sale. Did that sale yield the kind of revenue that was expected?

That's interesting to avoid the-- It's free to me I'm the salesperson and if I sell it I make money and if I don't, the cost was on engineering. It also allows perspective on how should we think about this from a product management standpoint. Now all of this requires a level of trust between the person who runs sales, the person who runs product, and the person who runs engineering and common goal. It is sometimes hard in a B2B company to know which features will cause the sale especially if there's five features.

I suggest the following thing. I hinted this before. Everything on the roadmap should be there for a reason. The reason should be explicit. The reason should look something like we believe by doing this feature for this type of user, that user will achieve this outcome. We will know it when we see this metric move. The idea is that our job is to create customers. Peter Drucker said this. Our job is to create customers. Revenue and profitability is a side effect of that. The conversation that you want to have is are we creating more customers over time of the type of customers we want?

Everything on the roadmap should have that. Back to the other part of the question is how do we know whether we've achieved that? Let's look at the things that we've released, a week, two weeks, three weeks, your latency may vary. See, did we actually get the goals for the customer we wanted? Did we see the metrics move? If we didn't, what did we learn? Let's retro it. If we did, what did we learn? Let's retro it. Both are interesting. We're not going to get them all right. That's okay but we want to get better at that over time.

Dan:

Excellent. Thanks, David. All right, we have one more question. Really insightful discussion, so we're doing a good job. Here we go. There's already some feedback for us. When you're building and sharing a roadmap with the product team, do you have any advice on how to help the wider company understand it's different to a project plan? E.g., in relation to your earlier point about efficacy of features built might not mean ready for the customer. [unintelligible 00:49:09].

David:

First I suggest that epic statement that I just mentioned. We believe by doing this feature for this customer will add this value for them, we said. That's the first thing, that to be very thoughtful about what's on the roadmap. Second is there's a Jedi mind trick which I think is very important. Don't show them the roadmap when it's done. Things you're going to build. You need to engage with them and you're going to engage with them for two reasons. One is they know some things you don't know. All the departments know things you don't know.

The CFO might know what the cash position of the company is, and therefore how much you can invest in long term versus midterm versus shorter term. They might know things about market conditions and broad marketing conditions. "Hey, we're about to enter a recession. I just read this morning, US GDP went down 0.2% last quarter," for instance. That has implications. Your CFO might know that better. Your salesperson knows things. Your marketing person knows things. You want to ask them because they know things.

The Jedi mind trick is by engaging them in this conversation, they're going to become supporters of the roadmap as well. When I do roadmaps, I walk it around each of the executives and say, "Here's stuff I'm thinking about. What do you think? What do you know?" They've already signed off on it before it's presented to all the executives. That's one thing. Second is, what is to be the CTO. At some point, you need to stand up in front of the company and say-- you'll probably do this with the chief product officer jointly.

Holding hands, hugging, whatever it is you do and say, "Here are the things that we are planning to do for the next couple quarters, pick your timeframe, and here's why." Some of them are going to be product features. Some of those are going to be enabling features you're doing in engineering. You need to explain to the rest of the company because it's not just that you don't want battles with the other executives. You want to win not just the minds of the company, but their hearts too. Here's why we're important as a company.

Here's how we're delivering value. Here's what you can tell your mom when you go home. Right? You need to present them. That thing about the CTO being a translation layer, this is where it's really important.

Dan:

All right. Thank you, David. We've answered all the questions from the audience and we have a few minutes left. Based on what you came to talk us about, anything else you'd like to share with us in the last few minutes?

David:

It occurs to me we've talked a lot about how a CTO walks about the world and how they engage with what they do. How they engage with our colleagues. There's an important thing about how they engage with themselves. Do you love technology? Does this stuff get you up at night? I still think about Armstrong walking on the moon. I'm older than I'm assuming most of this audience is. It was actually one of my-- maybe it was my first memory. I was a little teeny kid and I was in my stepmother's parents' house.

I remember Armstrong walking on the moon. First step. I was in Scarsdale, New York. I can tell you exactly what the room looked like. Fundamentally I said, "I want to do something with science." Right? I found out later what I really wanted to do is something with engineering. There's a difference. How is it you feel about your job? Are you motivated to learn this stuff every day? What are you learning? What's cool? Right? Are you talking with your peers? What does GCP have that looks like the updates on the cold start problem on AWS?

How are they thinking about that? Is that interesting to you? It should be. Find yourself an outlet to do that, as well as understand the business. By the way, spend some time outdoors or something else. Right? Go have a life. All those things are important.

Dan:

All right. Great. Well, let's see, we have one last question. All right. We just have time in case we are running out of questions. Any tips for an experienced CTO how to work successfully with a much less experienced CEO, founder? Yes. That's a good one.

David:

Yes, its a good question. It depends how much humility that much less CEO founder has. Is this person who thinks that they're the next Steve Jobs or is this a person who wants to be your partner? I know the current number of Steve Jobs in the universe. There used to be one. Some of them think they're the next Steve Jobs and can't be dissuaded. Often those people are also sometimes scared. How can you help them from what your experience is on things that might be outside your purview?

Oh, I've been in board meetings before, here's something that the board might be asking about. I've been thinking about that. Could I be helpful here? Try to be helpful. Try to be a coach to your CEO in ways that that CEO finds helpful. Where someone has more humility, then you can probably face the problem directly. "Look, I see we're having this business problem. Is there a way that I could help the VP? What do you think about me helping the VP of sales in this? How do you think me best approaching them?"

To the extent that you can be helpful to the CEO and things outside your purview, then sometimes age can be a benefit. By the way, sometimes a younger person might see an older person as they don't understand it. The world is different now but it's finding that area. It's finding the same thing where the personal micromanages. Finding that small area that you can do a little more than they actually thought, you can do a little more than ask for and providing value there. Then that relationship tends to open up.

I want to spend a minute before you go. Dan, I know you feel this way too. I mentioned before the four things we do, if anybody just wants to chat, just ring me up. Right? It's the deep dive looking at product management and engineering. It's the coaching we've talked about. It's the fractional CTO chief product officer worker due diligence. If anybody wants to know about how any of that stuff works and to just have a conversation about-- we are here to be helpful. You can hit me up on the Slack group, but also e-mail is generally easiest.

Dan:

All right. I've just shared the details there-

David:

Oh, lovely.

Dan:

-in the chat. Everyone's got those. Yes. Thank you very much, David, for joining us today. It's been a great discussion and certainly, I've learned a lot, and I hope others have too. Certainly, we had some feedback that the conversations have been useful. Looking forward to speaking with you again. I see there's another couple of questions come in but maybe they can be posted on the Slack channel and we can pick them up there. You can always tag David or me. If not see you again, next time.

Please sign up using the CTO Craft to join the community, and then you will enjoy further events. Thanks very much for coming, everyone and see you next time.

David:

Lovely. Thank you, Dan.

Dan:

Thanks, David.