Should you have an engineering roadmap? | Ron Lichty

In Episode 68 of Talking Roadmaps, Phil Hornby interviews Ron Lichty about the value of engineering roadmaps in an Agile environment. They explore how engineering roadmaps align with product roadmaps, emphasizing their role in guiding technical priorities and managing tools, frameworks, and team capabilities. Ron highlights the importance of collaboration between product and engineering leaders, the contextual nature of roadmaps, and how they adapt to change. A must-watch for those looking to strengthen cross-functional alignment and roadmap strategy.

Ron Lichty, Principal of Ron Lichty Consulting, has been managing software development organizations for over 30 years, the last 25 of those in the era of Agile. For the last 12 years principal and owner of Ron Lichty Consulting, Inc., he takes on fractional Interim VP Engineering roles, trains and coaches teams and executives to be more effectively agile, and coaches leaders in managing software people and teams to make their software development “hum.” Ron's 500-page book, "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams,", coauthored with Mickey Mantle and published by Addison Wesley, is now in its second edition, and has been translated into four languages. Ron also coauthors The Study of Product Team Performance and blogs about managing software people and teams.

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

In the next episode we are talking to Kenan Akbas, Product Creator and Founder @ AlignWith. So watch out for Season 1 - Episode 69!

• Transcript

  - My experience with engineering roadmaps is that every one is different. They are truly unique and I've never seen two engineering roadmaps that, I can't templatize it is partly what I'm saying. I find them very contextual. They have to live within the context of our current engineering stack, our current tech stack, our current tools, our current level of maturity. They have to serve the product roadmap.

  - Welcome to "Talking Roadmaps," the channel where we talk about everything roadmapping. The good, the bad, and the ugly. My name is Phil Hornby, I'm one of the co-hosts of the channel, and today, I'm joined by Ron Lichty. Ron, introduce yourself.

  - So, I'm a VP of engineering, VP of software development. I began my career in tech as a programmer. I was a programmer for seven years. I then got recruited into Apple Computer, this was decades ago, as a product manager for development tools. So I spent a couple of years in product management and said I need to be deeply techie, and went back to being a programmer. They made me a manager. I went back to being a programmer. They made me a manager. I got to manage the UX in Macintosh for a few years. I've managed as a director of engineering and startups. I got promoted to be a VP of engineering in a Fortune 500 company and 12 years ago, switched to, pivoted to consulting to helping make software development home. That focus of being an interim VP of engineering, and coaching engineering leaders, and training teams and their executives, and making their Agile development more effective.

  - [Phil] If you're enjoying the channel, subscribe, hit the bell, and give us a like. Love it, I'm gonna love having that kind of more technical perspective on roadmappings on the channel today 'cause we typically have product managers on the channel or kind of thought leaders in the product management space, and it's gonna be great to bring that view. I'm a former engineer myself who wrote a lot of software, so I can empathise with that. I almost went down the sales route from engineering at one point and then pulled myself back, and then found that product was a better home for me.

  - I totally understand trying out things and discovering,

  - And I may even have used some of the products that you created. I definitely have used Xcode and things like that as well for those developer tools in the Apple sort of space.

  - Oh, well, I went from Apple to doing screensavers and games. So I was director of engineering at Berkeley Systems where we did "After Dark" and "Flying Toasters" and moiré patterns, and fish, and all those kinds of things that we had to have to save our CRT screens back in the day. There are probably listeners to this podcast who have no idea what a CRD screen is so.

  - I'm old enough to remember it. I'm old enough to remember the Turbo button on my pc. I think the first PC I owned personally was a 286, and I had one megabyte of RAM I remember that. It was an amazing amount at the time.

  - Ah, the first one I had have 20K of RAM.

  - I tried to show my daughter who is 5.5 some of the games and things that I used to play, and they just look at it like where's the graphics? In fact, I was joking with someone on a podcast the other day about needing to play "Gauntlet" which was a game I played a lot as a kid and was very almost text-based. Let's go straight into a really simple question, but a fundamental question. What is the purpose of a roadmap?

  - A little bit of context. From an engineering standpoint, I am a fan of product roadmaps and a believer that we need not just product roadmaps, but also engineering roadmaps. From an Agile standpoint, an Agileist standpoint, there are those who say, "Well, we're Agile. Why do we need roadmaps? We're gonna change things all the time." And as I said, I'm a believer in them and it's because they provide a guiding star to a direction that my teams, the organisations that I manage, need in order to know where they're going. And that may change. It may change a lot, it may change rapidly, it may change frequently, and that's okay, that's goodness. But we need that guiding star.

  - Yeah, I mean, I often say this is plan A. I started working on plan B yesterday. I get the viewpoint from an Agileist of we know that things are uncertain. They're likely to change. That doesn't make the process of planning and having some idea or direction of travel have no value. Actually it helps teams think about well, what choices should they make today in the context of we believe we're going somewhere in the future? Yes, maybe those choices end up being slightly wrong because we change direction, but it's better than having no idea is always my viewpoint.

  - Yes, there's some general who, and you probably know the quote of this, there's some general who said the moment you enter battle, the plan is out the door, but the planning is incredibly important.

  - So that would be MVon Moltke the Elder. "No battle plan survives contact with the enemy." He was the Prussian general that united Germany the first time around in 1870ish. But we can go for the American one. "A plan is useless, planning is invaluable." I think that one's a Eisenhower one if I remember rightly.

  - I was gonna pick Eisenhower too, so I think that's probably right.

  - The end of the day, the wisdom ends up appearing in multiple places around the world.

  - Grooves replay themselves over and over.

  - So we've got this thing providing guidance for where we're going and no matter what way we're working, assuming we're working as an Agile team, it's giving us that direction, I assume the Agile team is therefore an audience of this roadmap, but is there anybody else that's looking at it?

  - Well, your business partners, the go-to-market side's definitely looking at your roadmap. I think there are a lot of companies, so I'm doing an assessment for a Canadian company right now and the product road, and what they build is a product. They're in an entirely not technical. Their customers are, actually their customers are mostly not technical, but they use the software that they build, and so what's this company about? It's about its product. It needs a corporate strategy from which the product roadmap, the product strategy and then the product roadmap derive, but it fundamentally is about that product roadmap. And that product roadmap then revolves for everybody in the company. Whether it's the go-to-market side or whether it's customer service, the product roadmap needs to tell everybody in the company what we're not going to do so that the developers know what we're not gonna do, but also the sales side doesn't go selling stuff that we're not building that so that customer support can get a call from somebody who says, "Yeah, well this would be really great." And they can have the spin on it that says that's not on our roadmap. Now that's not on our roadmap right now. We will revisit that maybe in three months, or six months, or a year, or two years. We've got a timeframe on the nos, on the things we're saying no to, but they're there and they're real, and we stick to them for that period of time. And that's really helpful for everybody in an organisation. So really hopeful for alignment.

  - Yeah, and I find, adding onto that, even the person in customer support being able to say, 'We're not going there because we're doing this other thing that is more valuable to you."

  - Yeah, and it may not be more valuable to that particular customer, but it is more valuable to the product and the customer set in general, and to providing the base and the platform that these folks are looking for.

  - Yeah, the hope is it serves them as well, but it what might not serve everyone in the customer base, that's very true. Now I know you have a particular view or point around kind of the technology roadmap as well then, so tell me more about that and kind of who the audience is for that.

  - Yeah, so my contention has been for several decades, several decades that we need not just a product roadmap, but on the engineering side, engineering leadership needs to come up with an engineering roadmap. That roadmap needs to succeed, needs to follow the product roadmap maybe by five minutes. We need to know what the product roadmap is, what the current product roadmap is, and identify what do we need to do on the engineering side? What languages, what tools, what frameworks, what libraries, what clouds? All of those kinds of decisions. We're working on a particular version of a language and that language has evolved and is now a version or two or even three later, and we're on the verge of being deprecated, and what are we gonna do about that? So we've got all engineering management's looking at, it's looking at things like what IDE is and what source control, and what DevOps, but it's also looking at things like how do we test out LLMs and Copilot? And the kind of tooling that we use internally in development, but from of the standpoint of that long-term, we need that long-term roadmap to say this is where the product's going. Therefore this is where engineering needs to be going. It needs to be thinking about, it needs to be experimenting with, it needs to be tried.

  - Yeah, I've made a joke in the last few years or last year or so that everyone had AI on their roadmap. It was three years out, and what they should have been doing is looking at that and saying, "Right, these are the capabilities we need to be building as an organisation to be ready for three years out." The problem is it had been three years out for the last three years as well. It's never come in any closer, so they'd never felt the pressure to actually get ready for it and really understand what was needed and what was possible at the technology level. And to me it's interesting 'cause I would argue that there should be one roadmap, but it's different views or different content. And Oxford, sorry, Cambridge University has this interesting concept of three layers on the roadmap of the why or the market, the pull side of the things. The middle layer or the product side of things, and then at the very bottom, the how or the solution or the technology side of things, the push. And so the principle being it's actually, and I think this is a Marty Cagan phrase of in ways that are only now possible. So it's you get to that point, it's like ah, all these things have come together technologically that now enable us to deliver this product that delivers on that particular market need, and that kind of connection of the three is a super powerful way of thinking about it.

  - Marty Cagan, if I'm not mistaken, is a recovering engineer as well, and easily understands that lower level. And in fact, a lot of product managers come from the place that I did when I became a product manager for two years and then opted back out, a place that you've come from where you're gonna look at that lower layer layer and feel fuzzy, warm and fuzzy about it because it says hey, this is gonna get me where we wanna go. On the other hand, there's a whole realm of product managers who don't come from engineering itself that would rather know that I'm working on a roadmap and would like me to walk them through it in a light kind of way, but don't want it part of their roadmap. And so whether we call it one roadmap or whether we call them parallel roadmaps, and it's why I said we need the product roadmap at least five minutes earlier, five minutes before we come out with the engineering roadmap, whether they're one roadmap or whether they're parallel roadmaps I think is probably virtually the same outcome.

  - It's probably a semantic argument.

  - Not having them is the outcome we wanna avoid.

  - I agree, so then we've got these two roadmaps. There's products and the technology roadmap. Who owns them both and who maintains them?

  - So I think of our chief product officer or our VP of product owning the product roadmap and our CTO or VP of engineering owning the engineering roadmap. And my good friend, Rich Mironov, has written a blog post about engineering leaders and product leaders working in concert, a blog post he titled "Shoulder to Shoulder," which the moment I read it, it just warmed my heart and made me wish that I had written it myself, but from the engineering side. So I think that's the core is that our product leader and our engineering leader need to own those two roadmaps or those two parallel parts of that roadmap, but they need to be working in concert. They need to be working shoulder to shoulder.

  - Oh, yeah, to me, it's a partnership of peers. I like to actually call engineering product development because it puts the product part on the front of their name as well, in the same way as product design and product management because we're all part of products in terms of delivering products. Too often, people use the phrase product to mean products management when actually we're all part of product.

  - Boy, we are in concert on this, Phil. I feel the same way. I use the word product to mean developers, and testers, and product managers, and everybody who's working on, everybody who's not on the go-to-market side basically who's in a product company who's working on the product, and I get myself in trouble every once in a while because somebody who hears me use the word product thinks I'm talking about product managers.

  - Yeah, in fact, I mean, I'd even put someone on the go-to-market side potentially in product, especially product marketing in that space. In fact, I start to think of product marketing almost being the equivalent to product design in terms of marketing and sales become the equivalent of development and operations in a little bit of a mental model I'm thinking about in terms of go-to-market paths and delivery paths. So we've got these roadmaps and you mentioned earlier that they kind of flow from a company strategy to a product strategy. Just kind of unpack that a little bit more, vision, strategy, objectives, how they kind of link into to these things called roadmaps.

  - I said that I train teams in Agile and sometimes I find myself training product teams. In working with backlogs, and backlogs for a product are backlogs of stories of ethics, and we're looking at how do we organise that so that we're delivering the most value to the customers and the most value to our business? But sometimes we're dealing with projects, or products, or product features, and we're organising those in the backlog. And we can't do that, we can't organise by value unless by value to the company, unless we know what the company cares about. And so the company strategy might be revenue. It might be profit. It might be new customers. It might be retention of existing customers. There are so many different directions and they would result, they might well result in a different backlog of what's important to us. That backlog, the in-between of that strategy of well, we're looking for retention of existing customers and that backlog is our product strategy and our product roadmap.

  - And so what's on our roadmap? We've talked about this kind of abstract thing. I mean, what are we putting on it, what's the content?

  - So I think of the product roadmap of here's where we're going five years, three years from now, but I'll say five years from now. I like five-year roadmaps. Here's where we're going. Here's our horizon that we, all of us in our company, are marching toward. And so if we did story mapping, for example, as a way of looking at the product and figuring out what our product is, then what are the core features? What are the features that add value after that? What are the features that add value after that? And we can coalesce them into well, so this is probably a first release and this is probably a second, and a third, and a fourth. And we can see it's a value progression of we're gonna deliver the most value ideally tomorrow. We're gonna deliver the most value tomorrow, and the next most value the day after that, and the next most value, or maybe it's this sprint and next sprint. But it's the same idea, that it's a progression of value, and the reason that we were talking about product roadmaps changing and the Agileists being, some of them being reluctant about product roadmaps being useful is because we're gonna discover things along the way and our product roadmaps gonna, and we're gonna insert them in places because wow, that thing that we thought had the next most value for tomorrow, there's something that's got even more value than that or for next sprint, and we'll work on that in the next sprint. And we will push off the thing that we thought was gonna be the next most value to the one after that.

  - We might even cancel some of the things that we thought we were gonna do as well.

  - Well, I think we'll probably cancel the last 2.5 years of the five-year roadmap actually honestly, and so one of the core principles in Agile that I think is really important here is that we're not, I date from the waterfall days when product managers, yeah, I figured, when product managers in the waterfall days would give us a hundred pages of requirements for a product or project, or 200 pages or when I'm doing Agile training, I'll ask people how many date from the waterfall period and how many pages of requirements did they get? And sometimes I get into thousands of pages of requirements and then I'll ask, "And what percentage of those did you actually deliver?" Any idea, Phil, what the common answer to that is? What the most common range?

  - I'm gonna guess the most common is, I don't know, 25%.

  - That's right in the middle. 15 to 45% is the common range. And then I'll say, and then I'll ask so what part of that a hundred pages or a thousand pages of requirements, what part of those did you deliver? And I never get the answer, the ones most valuable to our customers. I'll get the shiniest, the most interesting, the most fun, the easiest, sometimes the hardest. It varies, but you can't spot, in a hundred pages of documentation, you can't spot the most valuable for our customers and the most valuable for our business. It's really hard to see it. Whereas in a backlog and in a roadmap, they are organised by what's gonna deliver the most value to our customers and in small increments so that we can deliver a small increment that's the most valuable to our customers and our business, and then move on to the next one and we may do that thing of inserting something that we discovered along the way that is even more important than we thought. What are the outcomes that we're trying to see our customers get as a result of the work that we're doing? And that allows all of us, that partnership of product management and design and development, to think about what's the most powerful thing, what's the most valuable thing that can deliver that outcome? How can we deliver that outcome most powerfully?

  - Outcomes is one of those loaded phrases that can mean different things. Is it a product outcome? Is it a business outcome? Is it a user outcome? User outcomes being essentially jobs to be done. The first is product outcomes being a change of customer behaviour. Business outcomes being more like business metrics like ARR and things like that. Out of interest, where were you thinking there just to zoom in?

  - Let me go back to my Agile roots which my software development roots predate my Agile roots by decades, but my Agile roots go back to the Agile manifesto, and I go back to it all the time and I try to bring teams of people and companies all over the world into the Agile manifesto because I think it's really well written. It's as well written for today as it was, what? 25 years ago when it was written in the first place, 23 years ago. But I take issue with one statement and that is that, and I forget the exact wording, but it's our job is to satisfy customer. And I think that is understated. I think our job is to delight our customers and if I could rewrite the Agile manifesto, it would be to replace the word satisfy with the word delight. So one, outcomes that delight our customers and two, outcomes that fulfil our business, our business goals, our business objectives.

  - So let's shift gears a little bit. What do you consider to be best practise in roadmapping?

  - My experience, so one, I'm not in product management, so I don't write product roadmaps. My experience with engineering roadmaps is that every one is different. They are truly unique and I've never seen two engineering roadmaps that, I can't templatize it is partly what I'm saying. All of us would really love to have a template that all we have to do is fill in the dots, and I find them very contextual. They have to live within the context of our current engineering stack, our current tech stack, our current tools, our current level of maturity. They have to live with, they they have to serve the product roadmap which is gonna be different in every single case. And so they end up being very unique and it's I think really problematic to try to attempt to templatize it because it's never worked for me. I've never been able to do that.

  - If I were to say that's exactly the same challenge for products, it's just that level further abstracted from the concrete technologies. The technology needs are different, our market's different, the organization's different, everything's different, and so it's very hard to have a one-size-fits-all roadmap style and sort of templates. So much so that my co-host and I have gone to the point of creating essentially a design sprint for your roadmaps and a tool called the Audience Canvas that we use to understand who are the people looking at this thing and what do they need from it so we can design the right artefact

  - Right, and on the engineering side, we need to bring together the teams or the team leaders in order to get the best understanding of what we can do to contribute to the product roadmap. And so it's not VPs of engineering and CTOs off on their own imagining. It's not software architects off on their own imagining, but leveraging the wisdom of the crowd if you will.

  - And the same thing is true. So you mentioned earlier about the CPO or the VP of product owning the roadmap, and I think there's a lot of truth to that, but again, it's rolling up from that wisdom of all the product managers and the product teams behind them.

  - Yeah, so I have a responsibility to make sure we have one, but personally my focus is people and process, not the technology. And I have been a deep technologist. I have patents in software development, but as you become an engineering leader, you tend to move further and further away from the tech itself. And the people who are hands-on have a really deep understanding of what we can do with that we need to draw from.

  - I'm very much mirrored in the product organisation. You move further and further away from the depth of the product into the process and the people as well, and basically helping the organisation perform. Interesting, yeah, it's interesting, the parallels, and what I've noticed in the last few years is the increasing sort of realisation that in product management, we also need the expert path. That's been much more mature in the technical space like the senior onto sort of principle and possibly distinguished engineers, for example, being a path or the architect take. The product, we're starting to see those equivalent types of roles more and more these days, recognising that some people just wanna be a really good IC and not go into leadership.

  - Yes, when I was at Charles Schwab, a Fortune 500 investment financial services company, we had a VP of engineering who was an individual contributor. And that was the, and so the parallel tracks actually used the same titles. So it was clear to the people on the management side that this person had that same responsibility, that same weight of authority.

  - Yeah, I've heard that VP is the about the, I think it's the highest you can get to with that IC track. So there is still possibly one, the C-level that you can't escape being that one step above. So we talked about best practise. What about the biggest mistakes people make when roadmapping?

  - Biggest mistakes? I think probably the one we just discussed which is believing that you have the truth and the truth doesn't come from the gathering of the troops, the gathering wisdom coming from everyone.

  - I think a previous guest even referred to the roadmap as consensual reality. We all know it's not necessarily true, but it's what we all, as a whole, have kind of agreed we're gonna accept as truth and work towards. So whose advice on road mapping do you listen to, Ron?

  - On the engineering side, I have seen almost none. So I've written five books. The fifth of my book is, actually I'll hold it up now. My fifth book is "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams." And my coauthor and I wrote it because when we began writing it 20 years ago, there were six books in all of the history of software development on managing software people and teams. There was just almost nothing. There's now probably three times that many, but that's still pretty pathetic. So there's just not a lot out there in the engineering leadership space, in the engineering management space. I follow product management, and I'm not gonna say I follow product road mapping, but I follow product management and I read Rich Mironov, almost everything he writes because there's some application to engineering in almost everything that he puts out there. I love Theresa Torres's insights into incessant discovery. She uses the word continuous discovery. Marty Cagan, of course. There's a bunch of you who are providing insights into product management that are just exceptionally useful. There are more books on product management than there are on engineering leadership, but not a lot.

  - Yeah, I think we tend to be a little bit more outgoing as a discipline than many engineering people. At least that's the stereotype, so maybe that's why there's a few more books.

  - Probably so.

  - I think everyone you mentioned there is a previous guest as well so. So if you had to distil your philosophy on roadmapping down to one or two sentences, what would it be?

  - Yeah, I'm gonna go for your word, consensual. Consensually gathering insight into where we need to be in the future, organised by delivering the most value.

  - Now I have to do my classic sort of last question of is there anything I should have asked you about roadmapping from your particular point of view that I haven't asked?

  - Actually I will read you what Mickey and I wrote in "Managing the Unmanageable" about roadmaps, it's fairly short, which is, "Given our acceptance that change is inevitable and product features will emerge, some will espouse the myth that we don't need product and technical roadmaps. On the contrary, a vision of where we're going is as essential in Agile as in any other approach to technology projects and product management. The truth is that the vision will change probably often. But having a vision, a horizon to drive toward, brief as it may end up being, helps everyone target all their arrows in the same direction."

  - So Ron, it's been wonderful chatting to you today. Always like to finish up with an opportunity for you to pitch yourself, your services, how people can get in touch with you, fire away.

  - So you can find more about me at ronlichty.com and about my fifth book, "Managing the Unmanageable," at managingtheunmanageable.net. And both sites point to each other, so you spell one wrong, and if you spell them both wrong, you're in trouble. And there's definitely the possibility of that. But managingtheunmanageable.net and ronlichty.com are a source of those kinds of things. I looked last year, I thought last year, I wonder how many Agile trainings I've done over the last 14, I think 14 or 15 years? And counted them up thinking oh, 60, 70? I've done 176 through the end of last year, 176 Agile trainings including ones I had teams that were then begging me to train their executive teams to help them stay out of the way, don't tell anybody. To help them be more effective in supporting their teams. And so a number of those were trainings of executive teams.

  - The number of times I have that exact same request from product managers. It's like you've just told us all of this, now you need to go and tell them so they know it and they get out of our way, it's so true.

  - Right, and the response is you have to get them to ask.

  - So Ron, absolute pleasure having you here. We'll make sure those links are below, thanks very much.

  - Hey, it's fun chatting with you, Phil.