Should "Product Engineer" Be A Job Title? (with Phil Hornby)

You build the organization around the people you have. If then the people change, you have to change the organization. That's a bit of friction. But if you want to be super high performing, that's your best option because we're all wonky shaped objects. We don't all fit into a perfect whole. And so that's where you're gonna get the best outcome. (Upbeat Music) (Upbeat Music) Hi, welcome back to the Product Engineering Podcast. And this week we're talking about where that line is between product management and engineering. And indeed if there needs to be a line there at all. So for this episode, I'm joined by Phil Hornby. Phil is our product leadership coach, a global product lead for ZF and the founder of For Product People. Also the host of his own podcast, Talking Roadmaps, which we'll find a link to in the show notes of this episode. It's great to have you on the podcast, welcome. Great. And I'm just gonna extend the list. I'm also an engineer if we go back for a fact, till technically I'm a chartered engineer. I even went that far and ticked the box, you know, that no one ever does when they finish the degree and do all the time served and stuff. Well, that's perfect for this topic then. Because if you've started as an engineer and now you work fully in the world of product, that means you've experienced both sides of these divide. And that is actually not that common to have somebody that's worked as an engineer and then also worked as a product leader. So when we talk about that line between where product management ends and where software engineering should begin, it's almost certainly been getting fuzzier over the last few years. Where do you think it should sit and how defined do you think that barrier should be? I mean, I'm gonna pick up, you said software engineers. That's only one discipline of engineering. My background is mechanical, electrical and software. Like you're not full stack if you can't design the hardware, in my opinion. Back in the front end doesn't cover cut it. But where is the fuzzy line? Well, ultimately engine, anyone can do any of the work. But I think there's a fundamental human system at play here. There are some of us that have chosen to want to go and talk to people and understand the problems that they have. And there are some of us that have chosen to wrangle the code, wrangle the technology and make it and shape it into the way to do something. Now, don't get me wrong. The ability to do that shaping is getting easier. The ability to synthesize what you're doing in those conversations is getting easier. But I still think there's a human system at play. Like I stopped being an engineer because I got so annoyed. We'd basically been told to build the wrong thing. Really came down to that simple thing. I mean, there was a little bit of circumstance and so on as well, but I moved that direction because I recognize that if you've been, points you in the wrong direction, it doesn't matter how good you are as an engineer, you're doing the wrong thing. And if you're doing the wrong thing, you're wasting your time. And there was an element of I found the people problem, people wrangling a harder problem and therefore a more rewarding problem to work on. I mean, I can totally sympathize with that. That's why I do engineer management. I've been an engineer management for about 10 years because computers are easy and people are hard. And I wanted to tackle the hard problem, right? Like I wanted to deal with people not being predictable, not deterministic and actually sometimes you can't always fix a bug in a person and that sort of stuff. So yeah, I completely sympathize with that. In fact, I wouldn't call them a bug. I'd call them a feature. Like everything's a feature. Some of it's an undocumented, undesigned feature, but like I'm a great advocate for techniques developed by a guy called Meredith Belbin from many years ago, designing high performing teams. Like I am qualified in the techniques for assessing teams and this sort of thing on it. And one of its great principles is be the greatest of your strengths, not the least of your weaknesses. And so if I look at like these things that I'm not really great at, like I am not great at smoothing a team over and getting everyone happy and this sort of thing, but I'm really great at setting direction and making progress, but that one tends to upset people. And then I need someone who's more of that team worker to help smooth the way behind me. I'm not great at dotting the I's and crossing the T's. I need someone who's much more complete to finish around me. And so actually it's about knowing where the balance in the team is, how we get the best team is by getting everyone who's world class at some of those things and accepting that some people are not world class at some of the others, but we balance it by having the world class people. If you take away your weaknesses, you basically earn a beverage. If you amplify your strengths, you can be world class. And that to me is a leading principle in how I always think these days. So I'm playing devil's advocate a little bit here, but let's say I'm arguing the case that there should not be a boundary between product management's engines, right? Everything you've just said, you can't dictate what someone's good at or what someone's bad at just by their job title. There will be product managers who are, like you say, have strengths and weaknesses within the defines of product management and you'll have software engineers or other engineers that have strengths and weaknesses within the bounds of engineering, right? So if you have an engineer where speaking to customers is one of their strengths, then surely there shouldn't be any barrier. Surely they should just go all the way in that particular asset. I think, yeah, there's a whole school of thought around, do you build the organization perfectly? You design it from the top and then you fill the buckets, or do you build it around the people that you have? I was actually talking about this with one of my coaches who's a CTO only on Friday. And we both are absolutely of the perspective. You build the organization around the people you have. If then the people change, you have to change the organization. That's a bit of friction. But if you want to be super high performing, that's your best option because we're all wonky shaped objects. We don't all fit into a perfect hole. And so that's where you're gonna get the best outcome. Like, yeah, an engineer going out and talking to customers, bringing that insight back. To be honest, I want them doing that anyway, or at least standing next to me and listening, building that empathy, building that understanding because that ultimately is gonna get better delivery. Like, with the classic sort of mindset of a product team, it's found around this product trio, typically a designer, a product manager, or a product owner, and a tech lead. I don't like to have one tech lead because usually you've got, let's say seven plus or minus two if you use the classic number. I think the teams are shrinking on the engineering side relative to the team, the ratios are changing. But let's say we've got six people there. Well, there's gonna be a bunch of big initiatives that people are working on. And I would much rather have an engineer come and really get embedded on each individual initiative, really understand it, really live and breathe it, through the discovery process, and then go back and focus on delivery. And someone else comes and focuses on the next initiative that we're thinking about. And like, I think one of the key misconceptions is that product is just doing that part. Now, I'm a bit of more of an old school side of product as well. I spend as much time thinking about go to market and pricing and all those businessy things that even if a technology or an engineer wants to come and understand the problem, that's an even bigger stretch. And I think if we look back, like I did the history of product management as part of, I researched it as part of my MBA a few years ago. And it goes back to the 1930s. Like this is not a thing, a new thing. In fact, my first managing director in 2001, he had been a product manager in the 80s. He used the foundation of my product thinking. And the thinking hasn't really changed. Like, I think it's Bob Mester. He has this theory that every 10 years you have to rename a theory or a model to keep it relevant, to keep people's mind. Like I reread the Dell way recently. It's all about Michael Dell from the 90s building down. And as I went through it, I heard lean startup. I heard single-threaded leadership from Amazon. I heard all these principles that have now got new names and new concepts, but they're not that different. When I look at things like people talk about the Spotify model. So we're talking about matrix teams. We're talking about a, you know, where's your first home? Those concepts and communities of practice and things, they are not new, where they were just kind of given geeky names more recently. Yeah, I think that people are trying to solve the same problem, but with different structures. And you'll get that. I don't think they're different structures. I think they're just rediscovered structures. However, the structure can sometimes prevent people from bleeding into other worlds. So we don't talk, like you mentioned design in that triangle, right? We don't really tend to talk about design a huge amount. We're talking about product engineering, but I think that is quite useful because product designers for quite a while now have been going into the world of product, right? Product designers have been speaking directly of users and all that kind of stuff. And so they've almost kind of been through the transition that a lot of software engineers are facing at the minute, which is learning a little bit of product. And it's, you know, when I went into management, people always said to me, you don't want to go from being the best engineer on the team to being the worst manager at the company. And you can sometimes feel like that if you cross into somebody else's like expertise, you could go from being the best engineer on your team to being the worst product manager. And so, yeah, I think like designers, we could probably learn from the way that's happened because it's been successful for a lot of people in design, I think. It has, but I would put a caveat on that. Designers have transitioned really well, I think, in B2C because the customer and the user are the same thing. And they're used to talking to the user. When I think about who I talk to, I talk to users absolutely, but I'm much more talking to the customer. The person's actually paying the bill. The person's hiring this product to solve a problem and understand why they're going to buy, what value it's going to create for their business, which is not quite the same as the user in a B2B context. I think you're completely right. I would actually disagree because often in B2C, the customer and the user are not the same thing. So the user will sometimes be the product that you're selling to an advertiser. Like take Facebook, for example, right? Like a lot of people will complain. That's B2B at that point. It is. You're now B2B on that advertising side of business model. Facebook is a B2B company, right? Like it's an advertising company. So if you're a user of Facebook, people will complain that Facebook has terrible customer service. Like, no, they have great customer service. You're just not their customer. So like, but you are the user. So you're a user of Facebook. That's where I want the designer to be advocating for it more than the product manager. That's where I see that transition worked well in a pure B2C play, in a B2B to C play like you have with Facebook. For certain teams, someone from a UX background works really well. For others, they don't. But everyone can learn, right? It's not saying that they can't. It's just the skills that are transferable are less direct. Like the user research I do, or the discovery work that I do, is far less intense, far less rigorous, far less structured than what a designer is going to be, a user research is going to do. Because I'm not, I have a fundamentally different motivation. As a product manager, my goal is to de-risk things. Not to make the perfect solution, it's to de-risk. It's like, what's the smallest thing I can do to understand that this is valuable for a customer? What's the smallest thing I can do to understand it's valuable for our business? And then let's go and build it. Let's make progress. It's a different motivation. And I think, if we come back all the way to the fundamental topic here of like product engineer versus product manager, absolutely that mindset can be taken by anyone. I struggle with the idea of getting down to, just say a one person team. I actually think that the cognitive diversity of having multiple viewpoints, a different perspective and different people in the team is super valuable. Yes, I spar with my AI agent all the time to try and accelerate that. And I tell it to take on different roles to do that, but nothing beats a real person. I agree. But then let's talk about AI because people are starting to think, can I just have a one person team? And anything I can't do, I can just get AI to do. Like that is a common thing. So a common question that I hear about product engineering in particular is, is a product engineer an engineer who's learned a bit of product? Or as a product engineer, a product manager has just picked up claw code and they can do engineering, right? Now those are two very, very different, on the surface of it, they look similar, but they're very, very different because what you're doing is, the concept of AI being the average of the internet, like it's never gonna be the best software engineer, it's definitely never gonna be the best product manager. So you can kind of get by. You can get by filling in gaps in your skillset with AI. Yeah. But I think we were both agreeing on this though, right? That like there are some things you're always gonna know your product better than an AI, AI will possibly know it because it's not, it doesn't know it's not in the training. I mean, I use a, I have a huge personal knowledge management system, a bit like Dave Colleen here. Dave and Teresa, Torres have put a lot of material out there in the world about that, those sorts of concepts. I didn't pick up anyone's existing system. I listened to them. I mean, I had dinner with Dave in Paris, I think two years ago. And like I've sat there with him and a CEO of an AI company, the size of the, Brinn's the size of the planets. I'm thinking, can I keep up in this conversation? But I'm listening and I'm learning. And one of the things I took away was fundamentally what Dave was doing. And so I went back to first principles and I built my own knowledge management system myself. So I now have this, in fact, I have two. I have one at work and I have one at home. And they are both, you know, and they both influence each other. Like I learned something in one, I take that knowledge back to the other one and vice versa. And they are building up a huge amount of context. And I get a good first stab of everything. Like, but one of the things that you see with a lot of AI in writing in particular, is you get a vanilla, you know, middle of the road sort of way of writing. Until you take some time to train it. Like I'm lucky that I've got a ton of content out there in the world, speaking at events, this sort of thing. So I can go take all these transcripts. How does Phil speak? What's Phil's voice like? Phil uses hot ticks, slightly more controversial ways of phrasing things. Uses copywriting style of like, can start a sentence with a but. And all of a sudden, the writing starts to be me. It's consistent and it is how I write. How successfully have you found the output of that? Because I'll be honest, I've tried doing that. I'm writing a book at the minute and I have tried like taking a couple of chapters that I've written myself and writing the whole bit myself, obviously. But I've taken a couple of chapters and I've said to it, okay, this is how I write. Just do a paragraph for me. And you can see it trying. You can absolutely see it trying. You can see it doing British English and you can see it doing all the little quirks and that. But it never really gets it. I never read it and think I would have written that. Like, I don't know. So yeah, I think I've got there. I might be heavily using Claude as a ghost writer in a writing project right now. And I feel it's pretty consistent with how I write. But I have got hours and hours of content, right? So it's maybe just about how much I've got. But I also spend a lot of time tuning. When I do things at work, most of my output is not code. So I'm not teaching a style guide. I'm teaching it how to write like me and how to bring content in and analyze it. And then I'm sparring with it about that content. I'm not taking it and saying this, but then every single session, one of the things, I think it was a Dave one, end of every session I have a slash reflect skill. It looks back through the whole session and sees, what did we iterate on? What did it not get right? And constantly improves the system to be more like, you know, get to that answer in less steps and so on. So I think I'm getting pretty good. It's getting pretty good. It's not perfect. I'm not aiming for perfect. I'm aiming for 95% say, because that is still better than, it's probably better than I would do if I spent the next year working on something. And it depends where you're writing, right? Like if you're writing a book, you probably want to go for 100%. If you're writing marketing copy, you could probably get away with a little bit less. If you talk about product management, writing is an important skill, as I'm sure you know in product management, but you don't have to have it, it doesn't have to be pros. Like you're writing, if you're writing a product requirement documents or something, if people still write those, or you're building a slide deck to set out your vision to C-suite or something like that. Like that's still writing. It definitely is a type of error on the side of pros, not on decks. I'm a deck hater, but I live in corporate lands, I have to do some. But yes, for me, I'm trying to create, and I work with a, where I am, we have a two in the box model. So there's me as a product manager, and I have a product owner that I work with. If I was in a SaaS business, I'd probably be called a principal product manager and him a product manager. And the title's very right. But the way that it works is like, he's directly in the squad and working on things. And so we collaborate on things, but we use our first drafts, but we share our knowledge, our personal knowledge management systems. It's linked up to the whole Jira, so it can see all the context. It's pulling a lot of stuff in. And what we found definitely in the last few iterations, because we've both only been there working together for just 18 months. And so we've been going through iterations how we work together. And how we work with our engineering partners and so on. Get your storytelling is the critical part, like getting to that story that we can hand over to engineers, like the story, and I don't mean the user stories. The user stories are like the little bit of detail behind that, but the overall story, the customer led story, the user led story, that's been the critical part. Because there's been those epiphany moments for the engineers of, ah, that's what we're trying to do. Which actually, if they're out in the room, having to do the discovery, they've already got that. No, I completely agree. And those are the kinds of skills, I keep trying to think of software engineers like learning basics of products and stuff like that. And those are the kinds of skills that people don't tell you you need to learn, but you absolutely do need to learn. And in fact, you need to learn that kind of stuff as an engineer, if you want to progress to lead staff software engineers and stuff like that. Because the stories are how human beings consume information in the most successful way, right? Like we're not very good at just reading a bunch of bullet points, like LLMs can do that. But we think of things, we imagine a flow through something. And so, yeah, no, I think that's a really good one. Just put it in simple context. Humans in our form have existed for 100-ish thousand years. It's the last 400-ish years, maybe 500-ish years, maybe a little longer, that it's been written down in a language that most of the population could access. We've been sharing and passing knowledge through stories and that oral tradition. So much longer, it is baked into the structure of our brain to learn that way. So how do you learn storytelling then? How do you learn it? How did I learn it? Trial and error, a bunch of training, a bunch of reading. Like you can see, I'm a prolific reader. This isn't a virtual background. I was, yeah, I was wondering. (Laughs) I often make a point, I'll just pick a book. We're talking about storytelling, so okay, let's go and get, oh no. Your red thread, that's a good one on storytelling. Or save the cat, another one, good one on storytelling. I consume knowledge, but I also bring that knowledge into my system, like I'll tell it, "Ah, I liked this aspect of save the cat." Bring that into your knowledge, into your writing system. Or one of the key things, if I'm using AI to help me with writing an email, I always tell it to use Mentos Pyramid, because that means it puts the most important thing right up at the top. Like don't bury the lead. Because seeing people read the first two or three lines, and then they're done. So get it at the top, get it in the head, and everything else is just fluff. Yeah, I mean, why do you even need everything else if anybody's gonna just take your email and summarise it with AI anyway? So I've stopped trying. Here is this whole, I'm gonna write a long email with AI, then someone's gonna summarise it into bullet points, and then they're gonna use those bullet points to tell it to their AI to write their long answer, and lossiness. I mean, okay, so take that concept that you just described jokingly, and apply it to customer feedback coming in to a product, turning into product requirements, turning into some code. It's the same kind of thing, like AI is being used to work on this. That is what synthesis is in reality, yeah. So should AI be used to simply turn a feature request into some code, and then test it, and then ship it? Is that the right use of AI, or is that just gonna lead us down a path where we're not really in control of anything anymore, and we're not actually building what makes sense for the long term? A feature request, absolutely not. Because a feature request is from a customer, or from a user in solution language, like I want a button that does X, and then you have to ask the question of why. I mean, you never actually ask why. Why is a really accusatory word, but if you ask so you can dig down and get underneath the surface of what they're really trying to achieve, that's the skill of it, that's the art of it. Like, I'm gonna be walking around a bus depot tomorrow, because that's one of my customers. And I'm gonna be understanding, I'm literally going there to spend two hours just understanding their business, how they operate in terms of their maintenance model. There is no, it's completely open-ended discovery, like nothing more than that. But it's, I'll come away and I'll literally, as I get in the car, I'll start a chat GPT session, and I'll have a conversation with that, with it just to capture my thoughts after I come out. That's my, because I'm not gonna record the whole walking around the depot, but I want to synthesize as quickly as I can, and get as much out, but it's opinionated. It absolutely is, it's biased by all of my intuition, and my experience, and so on of working in the industry. And I don't think that's necessarily a bad thing. Like an engineer knowing that designing something in a particular way is gonna lead to tech debt issues in the future. That's that intuition coming in again. That's like that understanding of the type of tech stack and how it's gonna work. We're actually all paid to have opinions. I believe like, you don't pay someone senior to not have an opinion, you pay them to bring that intuition, bring that experience, and bring that opinion about how it's best to do something. Yeah, software engineers definitely have opinions. But I mean, one frustration I see sometimes with software engineers is that they have a lot of opinions about a very narrow subset of questions. So it will be whether we use Vue or React, or it will be whether we do TypeScript here or where. But when it comes to like the really big questions that really matter, like are we gonna go for this type of user flow or this type, they don't seem to get that, waiting for somebody to guide them, or someone to tell them the answer, and I think. But I'd say that's like the last 15 years. And before that, I mean, when I was an engineer, we got involved, like I was doing product work as an engineer. So I guess I was a product engineer, if we put it in that context. I drove the roadmap, I defined the roadmap. It was always how we worked. Like we just had a small group, there were 15 of us. We were all senior, experienced, full stack engineers. We could all turn our hands to everything. So we didn't have that narrow strong opinion because we hadn't gone so deep in each individual area. We had the, this is the problem space we need to address. How do we work here? These are the things we care about. Yeah, I mean, that's kind of the argument for generalists. And a lot of the, like small companies will have just generalists, right? Like if you found a company of three other people, then you will have to be generalists, or you have to be able to cover everything themselves. But then as companies grow, like having specialist skills, you have to be a trade off for having specialist skills. So if you have somebody that's super, super understands, like browser dom interactions or something, then maybe it is okay if that person doesn't necessarily understand how to interview a customer or something. I think that's true. I mean, if you look at like team topologies, like when you're thinking about designing your organization, in a specialist subsystem team, whatever they, if I remember, that's what they call them, something like that. It's really, it's not a short supply. It's that deep knowledge that you've got to keep together. It's got to look after components because you need that depth. But I don't think there are many teams where that's really true. At what size? Because once you go over like a large enterprise customer or company where they have hundreds and hundreds and hundreds of engineers, do you just have a hundred generalists? I think you could. I mean, the mythical full stack engineer, right? Is just a version of that kind of phrase. That is the thing we see. Like there are companies that are approaching a thousand engineers that would just have product engineers and they'll have like, you know, senior product strategy people and they'll have go to market people, but they won't have front end engineers, back end engineers, dev ops people and all that sort of stuff. Everybody sort of does as much as possible. There are some companies that are being very successful in that model, but then conversely, there are a lot of companies that would never dream of doing that. There are a lot of companies that are higher for a very, very specific, you must have had AWS experience, the worst kind of stuff. And that's where-- I mean, there are organizations that have, you know, there are different organizational cultures and all can be high performing. Like let's take Apple and Google or Apple and Spotify as two examples. Apple are massively functionally organized. You live in your discipline and that is your organization and then there's a lot of organizational tax going between them, but they pay that tax and they deliver what seems to be cross-functionally coordinated stuff anyway. On the other hand, you have some like, a Spotify type organization, where it is absolutely living in that cross-functional team where you've got everything you need in a small organization. And again, delivers in a similar way, but every time you go outside of each of those functions, there's a tax. And so it's about what do you want to optimize for and what's going to deliver better for you and align with your company culture and how you think. Like there's no one size fits all. As everyone uses the phrase and it's my favorite one, it depends. You can build an optimal organization in any of these models, but you're choosing to optimize for other things. I think that goes back to the point you made at the start, which I do really agree with, of building the structure around the people. It made me think of like the football team analogy, where if you've got like a lean or messy in your team, then you kind of try and build the team around them. Now, obviously, lots of people would disagree with that. Lots of people would say you should try and fit people into a system and all that sort of stuff. But yeah, I do like that approach though. I do like the idea of identifying what people are weak at and what they're strong at and building the structure around that. I think especially with smaller teams, which we're seeing more and more of now, working out how people can compliment each other and then just making that the structure, I think is useful. Yeah, I mean, you're probably still gonna end up with someone who is more businessy, someone who is more usury, and someone who is more technology. But the lines are fuzzy. I mean, with the classic Venn diagram from Martin Erickson that shows the three sort of areas, it purposefully overlaps to show fuzziness between things. It's got the business side, it's got the user experience side, and it's got the technology side. They're supposed to be an overlap. The classic sort of way people phrase it is, product is in the middle there, product management. In fact, product management, not product, is in the middle. I don't agree. The team is in the middle when it's balanced. And the team can be made up of any group of people. As long as you can cover those three areas, you've got a balanced team. And typically the product person is gonna take more of the business angle. There's a group of people who've chosen to do that. There's no surprise that if you go back 15, 20 years, the classic qualification for a product manager was an MBA, because it was a business role. And we've seen, Lean came out, Lean Startup, what was it, 2010, 2012? And we saw Lean Startup and Agile thinking and so on swing the pendulum all the way towards much smaller teams, much more junior product managers than they used to be. You were 10, 15 years into your career to ever think of being a product manager back then. Like I had a $300 million P&L, just as I speak. Like things change. And I think we're seeing it swing me back a bit more towards the business. I think product people for the last 15 or so years have done themselves a disservice because when they turn up in the room with the engineers, they have that business conversation. But when they turn up in the room with the CEO, they're usually the one representing the team. And so they talk about the technology all the time. And so they get seen as another technology person. When actually what they're doing is they're balancing the conversation because they can never be more businessy than the CEO. That's really interesting. No, you're right, you're absolutely right. And I've seen that happen and you're right. Because product managers embed themselves in the team, especially if they're technical product managers, and they see themselves as part of the team. And they're not, they're part of the business. And actually the team is itself part of the business. But I like that idea of holding the whole team accountable to driving outcomes in those three areas. I mean, I consider product managers actually live in two teams. They are in the squad or the development team, whatever you want to call it. They're also in the go-to-market team. So they're working with sales. There's another trio over there, sales and marketing and product. And it's not talked about so much. Might be part of one of the books I'm writing. I think that's the same as any management because product management is still management. I do engineer management and we are part of the team, but we're also part of the business team. And I consider myself part of a product leadership team as well, right? So we've got a couple of minutes left. A lot of our audience is senior staff, software engineers and engineer managers, and people that are kind of thinking, oh, okay, I know I need to become more product-led, but how do I do that? So what advice do you have for people that have been engineers their entire career and they know that they need to become more product-led and they just need some more advice? Drop the word product-led and just think about being user and customer curious and business curious. Like get to understand the business. Understand like one of the key things that everyone misses is what is the thing that's most important to their business? Go and listen to your next town hall. What are the two to three metrics they get talked about? Probably revenue, probably some sort of profitability. That is the thing your business cares about the most. Can you couple your activities to driving that? There will be some strategic initiatives that they believe are driving towards that. How can you support those? Ultimately behind that, it's all about, go and listen, go talk. Take every opportunity you can to have a business conversation. Like Marty Keegan is famous for, you know, the godfather of product management. Looking enough to be in the room with him as part of a coach the coaches event a few years ago. And he tells the story of how he got into product. He was an engineer at HP and he saw this product role and thought it looked interesting. And he went and spoke to a product leader. And the first thing they said is, do you understand finance? And they sent, they actually got someone for finance to train him in all the like the financial stuff so he could understand it. And I think it's less critical these days, but understanding the business is key. And then take every opportunity. If you're out and you're talking to someone and it happens to be there, a perfect target customer for you, just have a conversation with them. Like take every opportunity to be curious. That's actually excellent advice. Well, Phil, thank you so much for coming on. It's been honestly, we could probably talk about it for hours, but it's getting late in the day. So thanks so much for coming on. I'll put show notes in the description for your podcast and everything else you do, which is quite a long list. And if people can reach you, what's the best place to find you? LinkedIn, just find me Phil Hornby, or if you put my name in YouTube, you'll find me as well because there's a fair amount of content out there. But yeah, been pleasure being here, James. And thanks for having me and putting up with my slightly wild and pointed opinions. I'm just glad we both wore orange T-shirts. Thanks very much. Of course.