‘Leading the way as a CTO’ with Eric Bowman, CTO at TomTom

Kovid Batra: Hi everyone! This is Kovid, back with another episode of ‘Beyond the Code’ by Typo. And today, we have an amazing guest. He has 25 years of experience in engineering. He started as a software engineer, moved to a CTO. Right now, he’s serving as a CTO for TomTom, which is providing geolocation services to big companies like Google, Uber, everyone. The journey has been long and exciting, and today, we are honored to have you here. Welcome to the show, Eric.

Eric Bowman: Thank you, Kovid! It’s great to be here. Thanks for having me.

Kovid Batra: Great, great. So, Eric, on the show, whosoever comes, there is a quick fireside chat that we have here to know you more personally, okay? Nothing related to work, but to know you more personally. So, there will be 3-4 questions. Are you ready for that?

Eric Bowman: Yeah!

Kovid Batra: Great, Eric. So I’ll start with my first question. So, that’s related to book reading. Which one is the last book you read and how do you like it?

Eric Bowman: Yeah, that’s a great question! I do, uh, I read a lot actually. The last book I read is called ‘Right Kind of Wrong’ by Amy Edmondson who teaches Leadership at Harvard. She’s quite famous for pushing the ideas around psychological safety. And, ‘Right Kind of Wrong’ is really about how to fail in a productive way. And so, you know, obviously there are certain kinds of failures that are not good, but also, it’s well understood that you have to try things and see them fail and learn from the failure in order to keep making progress. And, it’s actually a superb book. She’s an amazing  thinker and writer, and I very much enjoyed that. I don’t read a lot of fiction. I kind of go in and out of reading fiction, but I recently read a book called ‘Afterlives’, by a guy named Gurnah. He won the Nobel Prize in literature in 2021. And, it’s a wonderful book and actually, you know, it reminded me that it’s important to also read enough fiction. Fiction really helps you build empathy for people. And, those are the kind of the two most recent things I’ve read.

Kovid Batra: I think that’s perfect. And from both the books, what I feel, your motivation seems to be more being empathetic and compassionate towards people. Like, that’s what you’re learning from the psychological safety that you need to build an organization. And from fiction also, you highlighted, like, to build more empathy. I think that’s really great. Thanks for both of the suggestions.

Let’s move on to the next question. So, talking about failures and then rising from there, doing good failures, where do you get this motivation? Like, it’s been 25 years into this career and I see that energy, you’re still reading books like those. So, like, from where do you get the motivation to go off to work every day?

Eric Bowman: Yeah. yeah, so motivation is an interesting topic and motivation is often compared to discipline. And some people will say that, you know, “Motivation comes and goes, and so you really need the discipline.” And other people will say, “Discipline is hard to maintain, and so you really need the motivation.” And I find myself going back and forth a little bit between the two. I think, you know, having a certain amount of discipline is absolutely essential, both personally and also professionally, but discipline is not enough. Finding the motivation is where the real drive comes from. And, you know, I think for me… and also for the people that I try to look for to work with, an underlying curiosity is one of the key things that really drives the motivation side. So, curious to understand, you know, “What are like, what are our customers problems really?” And you know, sometimes they tell you one thing and you have to dig through and find out that it’s something else. But being like naturally curious about technology problems, about people problems and organizational challenges. For me, I think that’s a big part of where that motivation comes from. And then ultimately, as I transitioned from being a software engineer into an engineering manager, really, and also getting more involved in the product side, you know, I’m seeing both myself and the team confront challenge, and the struggle of that, and then overcoming that. And, you know, especially as a group, like the idea of having shared goals and supporting each other. I get a lot of, I get more motivation from that than when I was younger, I thought that I would. Like it is, you know, it’s not necessarily about having it’s not fun every day. But, it can be meaningful every day. And that “finding the meaningful” part really comes from having innate curiosity, and then the discipline to really execute and just consistently make progress, constant progress.

Kovid Batra: Totally makes sense. You’ve already started inspiring me already.

Great! Moving to the next question. So, this is related to, like unwinding.

Eric Bowman: Yeah.

Kovid Batra: I hope you like music? I think everyone…

Eric Bowman: Love music!

Kovid Batra: So, which one’s your favorite band? What type of music you like? Something around that.

Eric Bowman: Yeah, that’s a tough one. I listen to a lot of different music. And when I was younger, I was kind of a superfan of certain bands. I listen to a range. I actually love jazz. I love kind of 50s and 60s bebop and I actually like some 70s kind of fusion jazz. I actually listen to quite a bit of classical as well. My wife is Irish and I’ve really gained an appreciation for 80s and 90s kind of Irish and British pop. I go in and out with a band called the ‘Grateful Dead’, which started in the 1960s. Actually, I love reggae. I love dubstep as well. You know, some music is useful for unwinding and some music is useful for focus. And I have a, yeah, quite a deep relationship with music.

Kovid Batra: Perfect. Perfect. That was really nice. And it was good to know you!

Moving on to the main section now. I think the audience is really, really looking forward to this. And, ‘how to lead as a CTO’ is something we are here to learn from you. So, I’ll ask a few questions. And to start with, like I want to start with something that is really, really interesting, which would be closer to you.

Any of the experience where you faced a real challenge in your engineering career? And, how did that challenge come up? How you tackled it? How did you overcome it? Just an open thought, open discussion around that. So, yeah, I think we’ll start with that first.

Eric Bowman: Sure! Yeah, there’ve been a few. If I reflect on kind of recent experience, I think one of the big challenges that I faced over the last couple of years is really around, in an environment where there are significant customer commitments and momentum against kind of a legacy technology solution, and a clear commercial desire to kind of shift into a more product-led approach in an environment where the customers are not necessarily open to that has been quite a remarkable challenge that I’ve faced recently. And it really was kind of a holistic change problem that also very much depended on external forces. What that kind of looks like is, you know, in an environment where you end up making multiple parallel customer commitments, there is a need for quite intense planning and execution. And, there’s not appetite on the customer side for much uncertainty.

But on the other hand, you know, and kind of going back to the work of Amy Edmondson and modern product management, you need a way to be able to perform experiments, to have hypotheses, to try things, to ship value and then understand at least your, what you think is value and then understand you. Your customers really like that. And, for me, it was, it’s been a remarkably satisfying and challenging exercise to figure out how to navigate that with a fairly large team, several 100 engineers, a large legacy code base and quite a modern view of what we would like the software to be and what it has to be for, in some cases for commitments that were made some years before. And, you know, one of the nice things is that a lot of the basic ideas of, say modern product management really work, you know, but it does require both the discipline and the motivation to make them happen. And, I think one of the things that’s been most satisfying for me is seeing how very high-functioning, high-performing team when they kind of understand the goal and there’s a shared North Star, and a kind of a clear vision that we’re working toward, how much that can bring out the creativity of that team to find real solutions to some of the very pragmatic problems that we faced.

And, you know, I have one moment in particular where an engineer kind of found a way to thread a certain needle where we could satisfy a customer, and make a significant pivot to a much more modern product that would be much more appropriate for multiple markets. When I was a software engineer, I loved having those moments. I liked to be that person. But, actually creating the environment where others could do that, and seeing them do that, very, very satisfying. And I’m really looking forward to this product coming out later this year.

Kovid Batra: I think I would want to know more on this. Like, broadly you told us, like there are multiple challenges and you have to do it, and then you get satisfied. Getting the team onboarded on the shared goals and getting them to deliver, being creative, everything. But, can you share one incident, one particular piece, so that our audience actually relates to what they are also doing in their organizations, maybe?

Eric Bowman: Yeah, let’s see. Well, yeah, maybe we can look at some more approachable examples. It’s a bit of a large-scale example. I think one of the challenges that I also faced not too long ago was coming into a situation where a bunch of online services were really not set up for high availability.

Kovid Batra: Okay.

Eric Bowman: And again, there was a fair amount of legacy involved, but there was a missing mindset around, I think you would call it ‘learning through failure’. And you know, the change that I introduced there was to say, “Hey, you know, there’s it has to be absolutely clear that the highest priority for everyone, if there is a some kind of customer incident, has to be not only obviously restoring service as quickly as possible, but also going through the work after that to really understand, “How did this happen?”, “What do we need to change to avoid this happening again?”, and then, doing that work. And, you know, with a fairly large team, that’s kind of a big change effort. But, what I found is that there were certain people throughout the organization who were really open to that, and they could immediately understand the importance of it. Not everyone at the same moment, but enough that we were able to get kind of a critical mass of people supporting and carrying this idea forward, and the change in mindset, because you know, like people are pretty rational in certain ways at the end of the day, but they also have a lot of constraints in their whole life, not just at work. You know, people have things happening at home and personal life, and they’re balancing their energy between these and, and it is a balancing act. And very often, especially if things are if there’s pressure at work, you know, people just want to go faster, get through it. But that’s not how people do their best work. So, really helping people understand the importance of ‘it’s not just about what we are doing today, we have to always be working toward the future’, and that means constantly working to understand, “How will this system behave?” “What don’t we know?” And, “What do we need to know?” And then really creating the incentives and the framework to say, “Hey, when something goes wrong, we really do need to know. And, sometimes you don’t know how long that’s going to take. And it may take a while, but we’re kind of in this for the long haul, and we have to make this investment now.” For me, kind of seeing the difference between that really were sort of two kinds of engineers in that case – some people who totally got it, welcomed it, loved the critical thinking and the clear exposition, and others who really felt that like, “Ah, you know, It’s all okay. It’ll be fine.” You know? And finding that first group and then really kind of empowering them and helping them.

Kovid Batra: Yeah.

Eric Bowman: And you know, I think…

Kovid Batra: Putting them as a benchmark maybe…

Eric Bowman: Yeah, exactly!

Kovid Batra: ..for the other people to look at, yeah?

Eric Bowman: And, sort of changing the mindset of people to understand that actually, you know, making the system more resilient, making sure that governance is covered and making sure that, you know, our ways of working, that how the software is built and deployed and monitored, and how’s the feedback, all of that. That’s actually very often what the most senior people should be working on.

Kovid Batra: Yeah.

Eric Bowman: Particularly, if that’s not under control in the sense that, you know, there’s always some variation, but it needs to be kind of bounded. If it’s not understood what those bounds are, and it’s not well-automated, well-understood, that has to be the priority. Otherwise, you cannot create value on top of it. And so, I think my advice, you know, for more junior software engineers is, always make sure that you understand that that is a huge part of the job. It’s not only about, ‘Oh, I’m working on kind of business logic or just trying to work through features or always trying to build things.’ The deeper problem of understanding the system and improving the system for the benefit of everyone is one of the most high-value things that a software engineer can do, and not all performance models, say, recognize that sufficiently.

Kovid Batra: Makes sense. Makes sense. I think putting the right incentives and the framework, and of course, hiring also helps. But yeah, that’s a great piece of advice, and thanks for sharing your thoughts, Eric.

Eric Bowman: My pleasure.

Kovid Batra: I think while we’re touching the topic of solving these problems at scale, I think ‘Team Topology’ is another topic which I’m really interested to hear from you.

Eric Bowman: Yeah!

Kovid Batra: Like, how do they play an important role in achieving your goals, right?

Eric Bowman: Yeah.

Kovid Batra: So, please share some examples.

Eric Bowman: Yeah, so, you know, ‘Team Topologies’ is a book that came out a couple of years ago and it’s really an excellent piece of work. And, very applicable, and you know, there’s a thing called ‘Conway’s Law’, which has been around for probably around 50 years, which is sort of the observation that organizations that build software, very often the architecture of that software models the communication networks within companies. And you know, when people say, “You end up building the org structure”, that’s kind of what they mean. And it is a real consequence of the system dynamics of development. And it reminds me a little bit, like there’s a thing in physics where if you go into a clock shop and there’s a bunch of clocks on the wall, it turns out all the pendula are perfectly synchronized, and you know, it’s a surprising thing to witness, and that happens through very subtle interactions in the way energy moves through the wall. Like, it is achieving a low energy state and you can mess them all up, and over the course of a couple of days, they will return to perfect synchronization.

Kovid Batra: Synchronization, yes.

Eric Bowman: And Conway’s law is a little bit the same, that even though, I mean, you can fight it for a while, but ultimately those system dynamics will win. And ‘Team Topologies’ is kind of a set of heuristics that leverages Conway’s law, as well as, you know, kind of what has been shown to work, that gives an organizational designer a set of design patterns to apply. And, it’s not necessarily a universal toolkit, but for the kind of companies that many of the people probably listening, it very likely does make some sense. And, it is essentially taking advantage. This is my view of it. The authors might disagree a little bit, but you know, taking advantage of Conway’s law and the importance in the modern age and what is enabled through technology to deliver value to customers sooner. And, it gives you kind of a toolkit for how to set up organizations that can do that. And, we applied that quite successfully, I think at TomTom, where we had kind of two large organizations, one working on SDK & services and one working on map. And, they were somewhat separated for quite a long time as the map company was an acquisition. And, we took our first steps into creating a single org by setting up the value streams, from map data all the way through the online services, to the SDK. We have a new, significant new map product coming out very soon. And, understanding how well that map was working with our services and SDKs was incredibly important to, essentially ensuring that the product is great. And the way the business had worked in the past, that was not a natural organizational pattern that was in place. And, so we implemented that. And I think, you know, one of the key takeaways from the book, and then my experience with those ideas is that the need for collaboration is a tricky thing because it’s very common in companies I’ve worked out in the past at least, that the idea that ‘we got to collaborate’ is sort of a universal good. And, it is true that when collaboration is needed, it has to go well. But, collaboration also comes at a cost. The need to collaborate requires energy, you know, which software engineers are balancing across a number of things. And, the whole point of many organizational structures is to combine people who are working on related things, so that they can create “synergy” between them. And, if you have to collaborate to do anything, it’s hard to go fast.

And so, one of the things that I very much like about the ‘Team Topologies’ approach is that it provides some heuristics for how to identify where is collaboration between teams important and worth it, and where, you know, is it better. Maybe a team, you know, has automation and kind of, what acts as a service. So, the direct collaboration between is not necessary. So, an infrastructure team providing cloud infrastructure, for example, if they have to directly collaborate with several 100 teams in the company for those teams to take advantage of the service they’re supplying, it’s incredibly expensive. It might be sort of fun and some good things about it, but it’s not worth it. Whereas, closer to the customer, and where you really want to kind of innovate and where you are really working to solve customer problems, you want to be able to rapidly work end-to-end, there that collaboration is almost certainly worth it. But again, it is expensive. And so, you need to be deliberate about where you expect teams to work that way and where that innovation is most needed. And I think it’s quite a refreshing view prior to that work. You know we all had, I think a much more simplified and less effective view of how to organize, really to deliver value sooner with as much automation as you can, kind of maximizing innovation. So it’s a very, very nice work.

Kovid Batra: Perfect! I think that was a great summary of what we can learn from the book. I think that’s a good recommendation too.

All right. I think I have one more question in my mind. When we are talking about the advice to the software developers, to the aspiring engineering managers, engineering leaders, one important thing is bringing a data-driven, plus an empathetic mindset to the way they are trying to improve their software delivery, trying to improve their teams, right?

Eric Bowman: Yeah.

Kovid Batra: And there has been a recent article by McKinsey which is trending right now about developer productivity. So, I just wanted to know your thoughts on that. How you have implemented such KPIs and metrics, like DORA in your team? And how to actually implement it at scale? How you’re looking at developer well-being? All this combined. It’s a big, big question, but yeah, I just want to know how you have done it at your organization, and what’s your thought on developer productivity, well-being and overall optimization of software delivery, yeah.

Eric Bowman: Yeah, the McKinsey piece created quite a bit of noise and some of the responses to it are quite excellent. And so I, I don’t think I can improve too much on that, but it is a fascinating, I think symptom of very often what is the challenge between a CTO and a tech team, and the more commercial side of the business. And you know, the McKinsey article is definitely, I think the target audience is more on the CEO side. And I think the criticism of that article reflects how industry-wide it is a challenge for CTOs and CEOs to really find a good way to work together, because ultimately in a modern tech company, the technology part needs to be everywhere and CEOs need to be pretty CTO-like in many of these companies. But, the bigger, the bigger question is very interesting and something that’s, that’s occupied a lot of my professional life in different forms, you know. The DORA KPIs became kind of widely-known with the publishing of the book ‘Accelerate’, I think in 2018. And, for a lot of people who had been working more or less in that way, whether we called it DevOps or not, found some version of that that made intuitive sense. And it was like a bomb going off in a positive way to have that research published and made accessible. And, it reaffirmed some kind of beliefs with a bit of science.

For those of you who don’t know, the DORA KPIs emerged from the research of Nicole Forsgren and others. And it’s basically four KPIs around a team’s productivity, which is essentially how frequently they commit code and how long it takes that code to get into production, how long it takes to restore service in the case of an outage, and how frequently code that gets deployed has to be rolled back or rapidly rolled forward. And, you know, the research demonstrated essentially, I guess it’s fair to say, a weak form of causality or a strong, very strong form of correlation between, kind of excellent DORA KPIs and business success, business health, cultural health. And it’s a very compelling research. It’s like, if you can actually move these KPIs, there is a causal connection, it appears, between the success of your company. Now, how you move them though is left a little bit as an exercise for the reader. And, you know, for people building online services, it’s kind of easy. When you’re building software for automotive, for example, where there is no way to deliver value, it’s a significantly harder, challenge. But of course, one can invent ways around that. And now a few years later, there’s a lot of tooling to help and there’s emerging best practices. There are, you know, common patterns that tools like typo, I think help with.

So the way, you know, you can think about productivity, kind of at a company-level, at a team-level, and at an individual-level. And, DORA is sort of focused on the team-level and then, Dr. Forsgren and others have now worked with the SPACE methodology to really look at individual productivity. And then, there’s still this open question of organizational productivity. But what all of these things have to a certain degree in common is this idea that flow is pretty hard to achieve. And, you know, you’ll find me frequently saying sooner “We want to deliver value sooner, and not faster.” And there’s a few reasons for that. When people are asked to go fast, they frequently make mistakes. But also by focusing on “sooner”, that’s where we find, you know, if like one team does some work and then they hand off to another team, which DevOps, you know, tried to remove that gap, but in a larger organization, there’s always handoffs. You can’t “everything” ops. And it’s those handoffs that end up eating most of the time. And so kind of with SPACE and DevEx, you know, this idea of fast feedback and flow and reducing cognitive load. And that helps people keep moving in the very small. And that like, once you get on a, sort of an intellectual path as a developer, you want to continue, you stay engaged and that allows you to kind of go farther through the sequence of small steps. And similarly with DORA, it’s a similar case, you know. It’s all about, “What is the delay?” If you’re releasing code in sort of small increments and then very quickly going to production, when something goes wrong, you very quickly consolidate it, reducing those delays. Those delays add up over time. And there, time is the only resource which is completely irreplaceable. Once it’s gone, it’s gone. And going faster then is like about, you know, you end up shortening the work times, but the wait times stay the same. This is all about closing the wait times.

Organizationally, then, you know, above DORA, there’s still an unexplored area. Although there, I mean, there are tools and there’s thinking around this, and Lean looks a lot at this, but the tooling is not great. And, the mindset is not there very often for people to really understand, “Where are those delays happening?” And honestly, things, you know, methodologies like scrum really exacerbate the problem. The idea of a backlog introduces delay, it builds it in. And, you know, one of the reasons why, I believe we see kind of a move away from scrum is it’s just not Agile enough. Sometimes, we need to be able to interrupt a team and say, “Hey, there’s a bigger thing going on, kind of in, in the business and we have to do this.” And that’s why Kanban, I think makes more sense, that it doesn’t build in delay. It’s more flexible around delay. And also, the nature of Kanban is on a much stronger, analytical foundation, that you’re able to apply Little’s law, and really understand bigger system behavior.

So, these three things combined, I think, you know, for anybody who’s trying to improve the value creation, which is, I guess, you know, ultimately why we want people to be productive, should really be looking at the individual-level, the team-level and the organizational-level, and always focusing on, “How can we identify where those delays are happening, and where value doesn’t keep flowing?”. And of course, there’s a lot to learn from the Toyota system. And you know, there’s a lot of thinking in the world around this, but it’s still maturing in software engineering. But very interesting moment, and a lot of opportunity, I think, for good toolings.

Kovid Batra: Perfect! Eric, that was really, really amazing. I think this is one of the best podcasts I have personally ever had. I would love to discuss even more topics that I get to hear from my customers, and in day-to-day, I’m meeting so many engineering leaders. So, I would definitely want you to come back to the show sometime.

Eric Bowman: Hey! My pleasure, Kovid.

Kovid Batra: All right, Eric. That’s all for today. Thanks for your time. It was a pleasure.

Eric Bowman: Thank you.