Guest: Martin Pengelly-Phillips, VP of Engineering at Zen Educate
In this conversation, Martin Pengelly-Phillips, the VP of Engineering at Zen Educate, shares his journey from the film industry to product engineering. He discusses the importance of a product mindset, collaboration within teams, and the role of mentorship in shaping engineering practices. Martin emphasizes the need for engineers to be problem shapers rather than just ticket takers, and he highlights the impact of AI tools in enhancing communication and efficiency. The conversation also covers practical steps for implementing product engineering practices and the challenges of scaling these approaches as a company grows.
Martin started his career building bespoke software for the film industry, where he learned full-stack depth, breadth, and product thinking in small, scrappy teams and once colour graded parts of Harry Potter and the Order of the Phoenix despite being colour-blind.He went on to scale himself at Intercom, growing from leading one team to an org of 50 people responsible for $120M ARR, and later delivered mission-critical healthtech software at Birdie.These days he works from home in rural Ireland with his wife, two boys, and their neurotic dog — living proof that distributed working really can work.
Connect with Martin: https://www.linkedin.com/in/martinpp/
Full Transcript
Peppe (00:01.848) Hello, hello, welcome everybody to a new live podcast of the ProRoot engineers community. So I will just double check very quickly if everything is working fine on YouTube. So I know that people are watching and then we’ll get started. Yes, it’s live. Okay, we have a few people already watching. Let me just welcome them.
So there is a chat on YouTube where everyone can just write their thoughts and asking questions. And at the end of this episode, then there’s going to be like a Q &A session. I’m going to read them and we can discuss them with Martin.
Cool, cool. Yeah, let’s get started. Welcome, Martin. It’s great to have you here.
Martin (00:59.061) Thank you, thank you, it’s good to be here.
Peppe (01:00.706) Yeah, cool. Yeah, so Martin is the VP of Engineering at Zen Educate. It’s a British startup that is tackling the global challenge of education, staffing to improve outcomes for children everywhere. Did I miss anything? Is that a good description? Cool, cool. Yeah, so Martin, before getting into the
Martin (01:22.653) No, no, that’s good, yeah.
Peppe (01:31.074) you know, the heart of this conversation. Could you share with us, like, how was your software, like your world, your software development, were before, let’s say, getting enlightened about this new way of working that is product engineering?
Martin (01:51.017) Yeah, I guess it’s kind of an interesting journey as well, because in a way it’s full circle for me. So I started my career in the film industry and in the film industry, particularly in visual effects. We were using technology to solve a lot of novel problems within that industry. And a lot of it was about putting, you know, big scary monsters up on screen. But there were also things to do with like, how do you manage
Peppe (02:02.702) Mm-hmm.
Martin (02:19.637) this amount of data, how do you manage it around the world? And that was the area that I found myself in, which was something today would be called pipeline. But it’s very much how do you track and manage different versions of creative work and really sort of build technology that feels natural to artists in a creative endeavor. And we didn’t have, you know, product managers and designers and the sort of PD set up that you might expect today. So a lot of it was on.
software developers, engineers to sort of figure these things out. So I kind of started almost naturally in that go talk to people, understand the problems that they have and then sort of slowly try to build a solution from there. But I was also very, very sort of keen on the tech, let’s say. And so, you know, for a long time, you’re kind of talking to people, but you kind of have an idea, you know, that’s something that you want to do. Maybe it’s a
cool piece of technology that you’ve seen. And so you fall into the trap of what a lot of people end up doing, which is I have a solution. I’m going to go look for a problem to fit it to. And so that was very much like in those early days of my career, perhaps looking a little bit too much at the tech before the problem. And as I matured in that industry sort of got better at that. But I would say when I really found
the place that gave me the language and the understanding was when I joined a company called Incom and who are very sort of known for being product led as a company. And so they gave me a lot of the mechanics, but also the way of thinking and partnering with other disciplines. And so that’s what I sort of carried forwards from that point on.
Peppe (04:03.662) Cool, cool. So before intercom, how would like a typical process or developing like a part would look like?
Martin (04:16.135) It varied from place to place. think a lot of the time, it would be very much like people asking for things. So you might chat to, you you’ve got a supervisor on a film and they’ve got a team and that team needs something within the product or that you’re building. And so they would ask for it. They’d say, you know, I want a button here that does this. And you would go and build a button there that did that. And over time, you would end up with quite an unwieldy.
sort of product that had all these buttons that did all these things and it become complex to use, but also complex to manage and maintain. And then you might react to that over time by saying, hey, I’ve got all this, you know, can I abstract it? Can I simplify it? And that would usually take you down the path of the configuration engine. It’s like, can I make everything configurable all the time so that they stop asking me to add the button and they can kind of add the button themselves.
And then eventually you might say, actually, there’s a whole area of this problem that I can figure out a very particular solution, a niche solution for and build a product to solve that niche. And I think what was interesting about my sort of experience, particularly in the film industry is there were definitely times where having a piece of product with lots and lots of controls on the page, which is like the big no-no, you know, today, I would say.
was absolutely the right solution. And so that’s something I remember as well as it’s always the right level of complexity for the user and the use case to solve their problem. And actually in that case, hiding all those things away would have been a disaster. so it’s not, know, simplicity is not always just get rid of everything and have lots of white space.
Peppe (06:05.038) So what was the thing that really frustrated you the most about not working in a product led way?
Martin (06:16.255) I think it’s two things. think, one, you never really sort of understand what you’re doing and why, you know, you’re, you’re sort of, it’s just an endless sea of requests. And I think as humans, you know, there’s a lot of psychology books around, you know, mastery purpose and things like this. But I think, I think that’s part of it. think eventually, the new tech becomes mundane.
the chasing new type becomes a bit less of a dopamine hit. And so you start to sort of think, well, where else am I getting my fulfillment? And if you’re just sort of someone gives you a request and you implement it, you know, it’s, kind of boring, I think for me. And so that’s, that ultimately becomes frustrating and where you also see a lot of frustration is of course the people that you’re talking to don’t all agree.
particularly sort of maybe if you’re working and you have multiple senior stakeholders who all have an opinion about how things should work and you become the point at which all that tension meets and has to resolve and so you know you’re constantly sort of on the back foot and not sure what you’re doing and why and are you following their request or what they want this and I think that’s very draining to a person so not only are you not getting that sort of fulfillment in
understanding, but you’re also getting torn in lots of different ways and you don’t have an opinion. And so I think that’s, that’s the main frustration from it is not, not being able to sort of see the impact of your work, but also being torn in many different directions, trying to satisfy too many people.
Peppe (07:55.02) Yeah. Yeah. The word impact is a word that I hear over and over from software engineers nowadays. And the ones that are not satisfied with a job are the ones that they don’t have impact. So it’s something that I’m hearing over and over. it’s, think it’s quite important. And as you were saying, it really touches in, in our human nature of where we want to do, we want to be doing something that is important, you know, helping people. So.
And I can relate with that myself. So you then join Intercom and you get exposed to this new way of working. What was for you your moment? Like what really clicked for you?
Martin (08:43.051) I think there were a few things and I think what was interesting was the aha moment being more finding common ground, common people. In that suddenly you had people who believed from the very top of the company down that this was the way to build a great company, a great solution and deliver a great product.
And so it wasn’t sort of you on your own a little bit trying to always push this thing. It was like, it’s the default path now. It’s not the thing that you have to do alone. So I think just having that like, you know, and not to say like this is this had started in the film industry and towards the end of my sort of career there. But it was never perhaps valued as much as it would have been Intercom who saw this as their competitive advantage almost from
from the get-go. And then along with that, were these other people that you could leverage that I hadn’t had access to before. So product managers and designers and researchers and specialists in these areas that could help accelerate you. when you, you it’s very hard to be great at everything, right? So if you’re there as an engineer and as a product engineer, you care about the experience and all, but you just might not have the skill, the time.
to go deep in those areas or to cover as much ground. So having these other people that you could suddenly pull on and leverage was really great. And I think that’s shaped a lot of how I like to operate today with teams as well. And at the moment with AI, there’s a load of discussion going on of like, do you need these roles or do you need that role? Should everyone do everything again? And so I sort of have that experience from Phil to know the trade-offs that you’re making.
and it’s more than just like who’s doing the
Peppe (10:43.02) Yeah, yeah, makes sense. Did you have any like mentors that really guided you to develop this way of thinking? Even like outside of intercom, for example, any public figure that you like to follow was very inspiring for you.
Martin (11:05.503) not really in that I’m sort of terrible at all that, you people ask me, what books would you recommend reading? And I tend to learn by doing. I have absolutely chatted lots to lots of different folks, different leaders and taken perhaps a little bit from many of them over many, many years. And sometimes it’s not even the sort of people that you maybe are looking up to as all they’re doing.
a great job, it seems, but it’s the impacts that resonate throughout the year. So it’s actually the people who’ve contacted me years later and so I said, this thing that you did, it made a real difference to me. And you’re like, okay. You know, I want to keep doing that. I want to have that. But at Intercom, I did work with a fantastic chap called Kuva. And I think he really epitomized this idea of like product mindset. So even though he was an engineering leader,
He was deep into the product. He played with the product daily. He understood the limits of the product as well. I think seeing that, seeing an engineering leader sort of go to that level of being a strong product leader as much as engineering leader and being as much in the product details as the technical details was very inspiring quite early on. And I think the other thing at Intercom that was a big shift for me is
I’d led teams, I’d actually been, you know, CTO of a small startup in the film industry and all. But it had always been like the people management was like the second thing. It wasn’t as valued in the film industry at the time. And I’d always been much more of the like lead architect hat. And at Income, I shifted quite dramatically into I wonder if I’m any good at this people stuff. And so I learned a lot through Income, not just about like the product, but also leading.
engineers leading teams and helping them deliver great outcomes.
Peppe (13:06.894) That’s interesting. So you’re saying that there’s also a big component into working with this mindset by having strong leaders can actually lead you and help you foster that mindset, right?
Martin (13:22.441) Yeah, because I think there are definitely times that you can sort of fly solo and perhaps as a product engineer, like that mindset is almost, you you should be able to do just about all of it end to end in terms of solving a problem and delivering a solution. But you’ll always hit a limit. You’ll always hit an individual ceiling quite quickly. And so it is a team sport and it’s, it’s about knowing how to leverage other people within your team, like whether it’s other engineers or whether it’s other disciplines.
And I think a lot about like, how do you set up the dynamics for a team, for an organization that that becomes natural and easy to do rather than hard to do.
Peppe (14:03.278) Yeah. Recently I spoke with the startup founder and they work as product engineers. they have a very small team of five engineers and each of them, it’s very interesting the way they work. They of course some product problems that they need to solve and they don’t work on features. So they work on experiments. So each person in the team has an experiment.
And I mean, the crazy thing is that he said to me, yeah, we’re going from having weekly sprints to daily sprints now because we can go so fast with AI experimenting and stuff. But yeah, aside this, the interesting thing he told me is the fact that you have all these people that are contributing to the product at the same time, at a certain point creates some conflict, of course, because everyone has different opinions. And I think.
I mean, I’ve seen different ways of defining what a product engineer is, but in this specific one, it’s like getting an initiative end to end. So from discovery to implementation to measurement. So in that case, you have a lot of conflict. Is that something that you also experience, this kind of conflict? So when you have more people involved into product work, of course, that can happen, right?
Martin (15:29.129) Yeah, I don’t know that I’ve experienced it as a sort of a conflict, maybe slightly, but I think the greater risk and the thing that I have experienced and that happens more is a dilution of accountability and ownership. think it suddenly becomes a bit harder to know who’s doing what and what you can rely on them for and expect from them. Particularly if you do have like dedicated product manager and designer roles and suddenly you’re asking engineers to
Lean in there, I think it can be a bit of a learning curve for individuals and team of like, wait, what’s my role again? You know, what am I doing? Not doing. I think there’s also a risk that you, a forget why you might have those specialist roles, but B that you just like users, this sort of, I’m just going to palm or work on, you know, it’s not all the engineer can do it all. you have to provide like the supporting mechanisms to make that successful.
And I think the thing that I keep in my mind that I’ve said to a few folks, and it can sound a bit harsh, today at least, maybe in the future with AI, who knows, but like today at least, if you have engineers, then you can build and maintain a product without anyone else. So a product manager, a designer, even someone like me in my role, we’re all kind of pure overhead.
And so we really have to find ways to accelerate what the engineers doing. And I think that’s where that idea of leverage comes in. So if an engineer can work faster because now they can talk to a designer who’s deep into the design craft and helps them sort of understand and build that muscle and go faster than if it’s just the engineer on their own shipping something and getting feedback and then shipping something and getting feedback like.
it’s still hard to get a very tight feedback loop with an end user at scale. So I think those things are important, but when you blur the lines, yeah, it’s less about conflict and more about who’s doing what, the things start to drop between the cracks. So I’m very clear always with teams to say, here’s who’s accountable for these things, and then define accountability as this is the person who’s ensuring that it’s getting done and done well.
Martin (17:53.495) but I don’t mind at all who actually does it. It’s just, you know, if it’s not getting done or it’s not getting done well, I’m gonna go talk to this person in this room.
Peppe (18:03.404) Yeah, makes sense, makes sense. So we can dig into now into Zeneducate, right? The culture, because that’s really what got me when I was going through the, everything I was reading about how you work there. And the, I think the sentence that really got me was the software engineers at Zeneducate are problem shapers. They’re not ticket takers.
And what does it mean exactly in practice?
Martin (18:35.509) Yeah, it’s a very catchy phrase. And I would say like, we are, one of the things I like about Zen and perhaps as a story to the folks watching and all, is this is a journey for us as well. Like we started when I joined, being a little close to perhaps being Ticket Taker’s, not quite, but we had an expectation of engineers and a process where, you
a product manager would write all your tickets and sort of hand them off and assign them to engineers. And engineers would then implement them. And then, know, engineers would have to show the work to a product manager to get it approved and signed off before it then went, you know, into production and things. And that’s just all very slow, but also quite not fun, I think, for engineers. And so we set about going on this journey of being more product engineer.
sort of mindset and attitude and that has been a shift. And so now what we see is still leveraging product managers to help, know, scope things to say these are the important problems that we’re hearing when we look around at the different use cases that we have, but involving engineers in that discussion for engineers to sort of say, well, why do we think this is that problem? Or is there actually a different problem over here?
have we actually sharply defined what the problem is and what success would look like in solving it. And similarly at the design stage as well, where a designer might be ideating on what it’s actually going to look like as a solution. Engineers now being invited and included in that discussion and helping sort of figure out, hey, we can actually do this slightly differently because we have this thing that exists. Whereas if we go build the thing that you’ve outlined, that’s going to take longer. That’s going to delay getting the value into.
uses hands, it’s going to delay us learning. And so very much involving them. So we still got today quite a linear process, I would say, where, you know, there’s a sort of problem definition and scoping, there’s a solution ideation and defilement, there’s a technical sort of assessment of what we need to do or change at an architectural level to make this work, and then an implementation and rollout phase. And so they are a bit, and what we’re seeing is
Martin (20:59.659) with the engineers that have really embraced this product engineering mindset, those loops and those feedback loops are getting tighter and tighter and people are almost starting to say they’re budding up against that sequential process and they’re wanting to move faster, which is obviously what you want to happen. Ultimately, as you get this wonderful sort of feedback loop going. There are also extreme cases. We try not to think about there’s one size to fit all.
provide a sensible default operating model for teams and then let them sort of experiment a bit. And we do that with engineers as well. So we have some engineers who’ve partnered directly with say a more of a commercial leader and just worked directly with that commercial leader to at least spike out a solution to a problem before an entire team takes it on and works with it. And that’s been very successful as well. And also a lot of fun for everyone, think, especially on the commercial side suddenly.
get a closer glimpse of like, what does it mean to actually build something and iterate on it?
Peppe (22:05.55) For commercially you mean like as salespeople or okay. Yeah account manager, okay
Martin (22:09.525) Yeah, yeah, so like an account manager or a sales leader or someone. And one of the things I should sort of outlined, like one of things I really enjoy about Zen and why I joined it partly is it’s one of those unusual companies that does operations and product and it’s the mix of these things that’s it’s sort of secret sources at work. it’s, you know, when we’re
using technology, we’re providing that technology both to internal teams and external schools and educators and sort of all of those things working together is what allows us to like deliver great experiences in terms of filling staff vacancies quickly and to high quality.
Peppe (22:54.574) Cool. So what would you say it’s like a signal that things are not working properly anymore, like in terms of collaboration? So what are you looking for exactly?
Martin (23:10.979) Collaboration between within a team, do you mean?
Peppe (23:15.01) Yeah, let’s say the team is working on a new product initiative. I guess, you measuring something or qualitatively or quantitatively? how do you make sure that this way of working is working, of course?
Martin (23:41.439) Okay, yeah. I mean, we’re small enough, like the product orgs under 40 people. So we’re small enough that you can get by a lot with just talking to people. And so definitely just checking in, know, teams run their retros. We also have a retro of retros where we bring up things from teams and identify patterns across the org. We’ve also invested in like a developer experience initiative whereby
Peppe (23:54.007) Okay.
Martin (24:09.911) on a regular cadence, roughly every six weeks, we’re actually setting out survey to engineers and asking them some common questions every time, but also some new questions that might be particular to something happening at that time and just gauging like what’s on their mind. I’m a big fan of whoever said, if you can’t do anything, if you have data or asking people and you have to choose between them, then ask people because engineers know.
And then we’ve definitely leaned into that. So I think that’s sort of the main ways. Then you’re also looking at like the output and the outcomes, like are we actually delivering faster perhaps? Are we doing it more sustainably? So we track the sort of the quality of the work, how many issues are being reported when we release things and how quickly are we to address those? And also sort of…
the sustainability or the efficiency of that. But yeah, a lot of it’s just talking to people, listening to people, then picking up on signals and chasing them down and sort of more often than not in my role. It’s very obvious, but know, someone has to kind of think of sometimes it’s just getting people to talk. But we don’t really have too much around that. I’d say
I’d say a lot of the time, the challenges are always like dealing with the whirlwind day to day of things going on and sort of staying the course on focus, which I think is the main thing that a product led sort of team needs in order to be successful is that focus. Cause without it, you end up with maybe you have a team of, you know, six engineers and a product manager and designer, but if every engineer is working on an entirely different problem, then in my mind, you don’t have a team.
you just have a bunch of people who sit together.
Peppe (26:03.842) Yeah. Yeah. So how are the teams structured so that this collaboration can be productive?
Martin (26:11.543) So we’ve sort of gone the classic stream aligned teams where we’ve tried to identify a clear end user that that team can revolve around. So for us, there’s an educator who’s using predominantly our mobile app to find work and sort of upload their preferences. There’s a schools team that’s looking after the school experience and how they sort of put roles out there and find the right educators.
There’s a marketplace team, which is like the intersection of those two, which is a bit funky. know, that’s, like serving two different, um, users simultaneously, but really the user is about like, how do you actually match, uh, effectively across these? And then we have an, and what we call internal tools team today, which is very much geared to that operations sort of side of the business. Um, how do we help them deliver a great experience? So if the school’s phoning up, uh, an account manager, how can we make that account manager?
more effective and more like up to speed on what’s going on in that school so that they can help and provide adequate support and relationship to that. And that’s very much about helping humans do what humans are great at by taking away some of the sort of more admin-y stuff that they might be responsible for. And then we have a very small team off to the side, which is the sort of enabling team. That’s the one focused on the developer experience, focused on things like…
can we improve sort of how fast our CI is running because you know maybe that’s identified as something that’s slowing us down.
Peppe (27:47.95) Cool. So let’s think about the typical week for one of the engineers at Zeneducate. How would it look like?
Martin (28:02.781) It depends team by team. try to say there’s a standard interface of things in terms of all of the teams, but we give a lot of freedom and flexibility then within a team to how they operate. But some of the common things are very sort of established standard things that you would expect. So a lot of the teams are doing a daily standup. Some of the variations that you might experience is some will do it async. So it’ll be sort of post on Slack.
where some will get together on a call. We’re a distributed team, by the way, so we’re mostly joining meet calls and things. There’ll be some period within the week that maybe the product manager is leading a review or a discussion on the problems that we’ve identified and doing that shaping together as a team. Similarly, the designer might be outlining the ideas that we have for how we could go solve a problem.
Some of the engineers might be involved in technical planning. And for me, technical planning is very much about are the non-obvious solutions to a problem technically? And if so, what are the trade-offs that we’ll be making when we pick between them? And if so, let’s write that up and get some input from the wider team before we move forwards. They might be writing their own tickets, breaking down work, iterating, doing QA.
shipping, monitoring, you know, the impact of those things in the observability systems in the product metrics sort of systems. So it’s kind of varying over every two weeks, you know, it’s kind of a mix of these things. We are sort of running this sort of two week sprint approach, but we might mix that up soon. That was very much like helping teams find a bit of structure. But we’re now seeing teams, as I said, being able to move quite fast without all of that mechanics.
So yeah, varies. And then, you know, it’s where’s your curiosity take you? I’m a very big fan of trying not to create too many small boxes for engineers. So we have some engineers that are very interested in design. And so they’ve been leaning into the design system and helping evolve that.
Peppe (30:18.146) Cool. So I like to kind of understand how different companies are implementing the product engineering approach. so for what I understand, then educate. So the problem shaper means that engineers are involved in shaping the problem with the product manager and the designers all together. they all shaping the problem altogether, right?
Martin (30:48.169) Yes, I mean, there are definitely, so there’s no blocker around as an engineer actually saying, hey, I’ve identified the problem and bringing it to the team. But from a sort of sheer who’s got the muscle, who’s got the time and the focus, it’s predominantly coming from the product manager, the sort of source of those things. But again, we’re not putting a restriction on that.
Peppe (31:00.078) Mm-hmm.
Martin (31:15.927) Yes, mostly engineers are contributing to the discussion and shaping in that way. But there are a few engineers who might also be saying, actually, I see the problem here and I’m going to bring it to the team.
Peppe (31:31.214) Cool. It makes me think about this new, it’s not new concept, but I’m reading out about the product builder trend. like, I think it was out of an article from Mardi Cagan. And so like everyone is becoming a product builder now, but you’re just bringing different expertise from different point of views. So designers are product builders, but with their skills and engineers the same PMs the same. So yeah, it’s.
It’s important, of course, that there is this collaboration and people with different point of views and experiences can contribute to the final outcome.
Martin (32:13.419) Yeah, like for me, because I’ve thought about this a lot and all, and I think there’s no nice one line description, but the one line description that I sort of hold in my head for what it means to be a product engineer is, it’s someone who loves solving real problems for users and just happens to be skilled at leveraging technology to do that.
as opposed to you know a more traditional engineer might be more focused on the technical side. I think a product engineer is first and foremost focused on there’s a problem to solve, how do I solve it? More often than I’ll solve it with technology, but sometimes I won’t. I think the mark of a product engineer is someone who solves a problem sometimes by not building anything.
Peppe (33:03.03) Yeah. best line of code is the one you don’t write, right?
Martin (33:06.484) Yeah.
Peppe (33:09.358) Yeah. So I was, was thinking about how do you handle end-offs? I can imagine maybe a designer has to create the user experience at a certain point, just stop doing it. And then the engineer has to implement it. And I mean, in my experience, this can create some delay, of course, because you need to wait for something to happen.
from, for some artifacts to be created. So it could be a blocker. So how do you handle this in within your teams? Generally speaking.
Martin (33:47.543) So at the start of the year, we rolled out quite a structured process to sort of provide support for that. And so that’s actually a process that takes place over six weeks. And you can imagine sort of four weeks lead up to the sprint execution phase. And so in the first sort of…
week or a couple of weeks, that’s when you’re really looking at, do we understand the problem? Have we pricked the problems that we want to go after? And again, sort of engineers being involved. And then following on from that, you know, are we designing it in a certain way? What are the solutions that we might want to go after? And then, you know, so we’ve actually created quite a lot of lead time in the process. And that’s that’s how we sort of tackled that.
that main, we laying the tracks far enough ahead that the team can run at it well? As teams have got more effective at working together, like they can shorten those lead times. But where we’ve seen some of the mentioned tension, where we’ve seen some of the tension in the past is if those things get too compressed, if the sort of problem document is sort of landed on
people that’s like, we should start building it in two days time or tomorrow or something like, then it’s starting to break down a little bit. So it’s always trying to find that sweet spot of how do you get far enough ahead that you’re giving people time to think and take things in and comment and give response, but not so far ahead that you’re like, we decided everything here and then we forgot all about it and the world changed. And so when we actually got to build it, we’re out of date. So for us in the moment, it’s around six weeks.
but we’re sort of open to experimenting with that. And then handoffs again, it’s relationships. We try to build these teams that are cross-functional, so product manager, designer, engineers, and sort of tech lead managers are the indivisible unit of a team, and they’re all working and collaborating closely. So how they do handoffs again varies within the team sometimes.
Martin (36:02.887) An engine might just sit with a designer and rapidly iterate while they’re talking. Other times, a designer might produce a detailed Figma design or a lovable app or something to show what they’re thinking and communicate that way.
Peppe (36:20.198) Well, I must ask, did the race of AI tools, did you see any difference since they started to become more mainstream and in the way you work?
Martin (36:34.205) a little bit. Yeah. I mean, I think, I think what’s interesting is we were very much a, an experimental, approach and attitude to AI. we’re not a company, and certainly not in product that’s sort of written the everyone will be four times more efficient. Let’s, you know, do this guy. We’ve learned more into like, Ooh, this is something that we’ve never had before and no one really knows. So let’s, let’s play with it. Lots. Let’s share our learnings.
and figure it out. And I’d say we’ve seen sort some of the biggest gains in the work around the work. So actually things like communication, you know, we have a diverse set of people from different backgrounds, different languages and all. And I’d say a lot of folks are now leveraging AI just to be clearer in their communication or to summarize and understand, you know, longer data sets. And so that’s actually been quite useful.
in terms of how these teams work together. And then engineers have been picking out up more in the day to day sort of coding. We did an AI survey recently, half of our engineers are using sort of more of the agentic AI approach where starting from, well, let’s plan together and iterate rather than, hey, can you just order complete something? We’ve got some designers who’ve then into like actually creating PRs.
and shipping fixes, particularly on the styling side. And we’ve encouraged that because like, you know what, that’s probably just gonna sit there in the backlog for a long time. So why not give it a go and see how far you get. And yeah, product managers, think leveraging it very effectively and all of these things come with like, you need to be able to stand behind the output of this tool. You know, we’re very clear that you can’t just be like,
Peppe (38:05.507) Mm-hmm.
Martin (38:29.271) Yeah, I did the work and I handed it off to you because then you’re kind of like, what’s the point of you? You need to add the value and the other stand behind it. But product managers, know, there’s a lot of information you have to deal with. Inflicts across stakeholders, users and all that you’re taking in. And it’s been very helpful in distilling that down and finding the sort of nuggets of information that you want to use.
Peppe (38:54.796) Yeah, makes sense. Now, the last thing you said is interesting. It’s something I usually think about, like the PMs have all these things to do and they usually are one person. Do you see this changing over time? Most of all now that different, let’s say traditional roles are getting more responsibilities, like getting the PMs a bit less busy.
so they can focus more on strategic work, I don’t know. And distribute the other responsibility across the team.
Martin (39:33.693) Yes, I mean, I think I’ve been around a while, but I’ve also looked at history and I would say in general, any major technological advance has yielded more work overall. Like it just increases the number of things that humans can go after and also raises the bar. know, the quality that you expect from a product today is far beyond what you expected.
10, 15, 20 years ago. So we as humans tend to, I think, fill that void. We create the ability to do more and then we create more to do. But I do think the roles shift slightly and change slightly. But at the same time, all these things, I think, are things that can happen anyway. It’s just another tool. if a product manager before was writing lots of tickets for their engineer and assigning the work to the engineers.
I’d argue you don’t need AI to solve that problem. You just need to, you know, empower your engineers to write their own tickets and pull on you when they need to clarify things. So there would be a terrible solution to say, well, as the PM, I’m going to leverage AI to write all my tickets for me and assign them to the right engineers. But I do think there’s lots of interesting things on as you become more senior or as you become more specialist, which is what a product manager role is. How do you
multiply yourself, you how do you scale yourself is often the question. And I think that’s interesting, like, can you train, you know, a chatbot or something with what you know, and your tone and how you respond to things so that when you’re not around, someone can ask you a question, you know, I don’t know, like, maybe that’s something that we’ll be able to do and do effectively. I think the hard thing with AI, as I sort of see it today is it’s not reliable.
And if it’s not reliable, then a lot of those gains disappear because if I’m going to ask my PM GPT, and sometimes I’ll get exactly what they would say and other times I’ll get total nonsense fiction, like that’s not actually useful to me. If I then have to like think each time, or do I trust it or not?
Peppe (41:53.366) Yeah, makes sense. Yeah. mean, probably there are better activities to spread knowledge. I’m thinking about like extreme programming, for example. It’s a, as a lot of activities that help spreading knowledge, like programming and like, think it may be, it’s also time to do like maybe preprogramming between different roles, not only between engineers, but also with program managers and designers.
So you always have this kind of knowledge sharing that would happen like automatically, right?
Martin (42:28.447) Yeah. And I think, I think we’ve all seen, you know, the, sort of the notion, you know, sites and things that just end up with this sprawl of information that’s not curated, not maintained and hard to follow. And so I think some of what we have now is wonderful because you can start to put that in a place that remains searchable and approachable. And then, you know, we have
the ability for people outside the product or perhaps to ask questions of the product, you know, why does it behave that way? And it didn’t need someone to write docs for every single little thing. Equally an engineer who’s joining the team, you know, might want to be asking like, what do I need to think about when working on this part of the product or code base and having the ability for it to sort of talk them through that and give them enough signposts to go and talk to people. I think that’s a, that’s a great skill to have.
Peppe (42:59.757) Mm-hmm.
Peppe (43:24.27) Cool. So on a different note, you said that you are as Zen Educator in this journey to experiment with this new approach. And so you still see how it works out. What have been like the main challenges that you’ve faced during this process? Did you find any resistance, anything that you haven’t seen working and then you had to tweak it to make it work? What’s been your experience?
Martin (43:51.465) think the thing that’s maybe a bit sort of obvious and simple, is the thing is just the need to constantly tell people and reinforce that you can do this. think, you know, if you’ve had people working a certain way and suddenly you change that, there’s always going to be some nervousness.
Can I do it as in am I allowed to am I you know, like as an engineer? Well, am I stepping on the product managers toes here? I don’t want to you know upset them so making that okay and safe and you know re-emphasizing continuously that no as a team this is how we do better and Actually, the PM is gonna thank you because as we said they’ve got a lot to do I think that’s part of it and then there’s also can I do this in that like
Well, maybe I’ve never thought this way before. Maybe I haven’t really thought about user problems in this way, customer problems. Maybe I don’t understand the commercial aspects of the business and why these things are important. And so there it comes down to like, do you have that curiosity? And I think that’s such an important trait of engineers is to be curious. And I think a lot of engineers are engineers because they’re curious about things. And so it’s about leveraging that as well.
It’s okay to not know. It’s okay to get it wrong. You know, if we’re giving you the ability to have more influence to more impact, we’re not also expecting you to nail it first time. You know, it’s a journey, and we want to support that. think those are the things that we’ve had to sort of repeat, time and time again. And it’s taken, you know, very, for some people, it’s like you say these things and they’re like, thank goodness I’ve been waiting for this. Let’s go. And then other people, it’s, you know, it’s like,
couple of months, other years of just sort of showing that this is great and this is how it works and it’s safe and you can do it and re-emphasizing that. I think those are the main things that we sort of see as a challenge beyond the stuff that we talked about earlier about like then what falls through the cracks, are we clear on at the end of the who’s accountable for certain things.
Peppe (46:11.532) Yeah. Yeah. I can imagine how it’s important that all the company also agrees on this. Like not only the engineering department, it’s also like the product and everyone. Yeah.
Martin (46:23.895) Yeah, I mean, if you do this and you don’t set expectations and you you’re sort of CEO’s, I would just say suddenly everything grind to a halt and nothing’s getting shipped anymore, then you know, that’s tough. So you need to set expectations, but also look for the quick wins, look for the champions. There’ll always be, I imagine in any engineering org, at least one or two engineers who just naturally get it and you can sort of leverage them.
to do something really quickly and well and show the success of it.
Peppe (46:58.392) Cool. So I want to pause a second just to see if there any questions. So if anyone has any questions, please write them down so we can answer them. I don’t see anything in the chat yet. So let me just see if I can refresh the page.
Peppe (47:27.98) Okay. So if anything pops up, I’ll pick it up later. How do you see this approach scaling as a company grows? Because I think when a company is smaller, it’s easier as also as you were saying, because people can talk to each other and it’s a bit easier to have like a bird eye view around like around everyone and everything.
As company grows, so they have like a lot of teams and maybe even different kind of subproducts and everything. How do you this working at scale?
Martin (48:06.807) I as with anything, it works if it remains important to you and you do the work and you focus on it and you put the effort in. I think anyone, I’m under no illusion if we sort of say, hey, it’s all great now and you take your hands off the wheel and you just assume, well, I’ve got the culture now and it will stay forever. That doesn’t work. You have to sort of work at it every day in how.
you show up how others show up, what you recognize and reward even, you know, and start to bake it into some of the other mechanics within the system, like performance reviews and things. But I think if you, if you have that kernel from the start and you sort of, you know, leverage that as you grow, so you might say, well, I’ve got these people who really are my champions for this approach. So I’m not going to put them all in one team over here. You know, I’m going to spread them out. I’m going to.
set up a way for people to go on tour with different teams, different areas of the business. So we’re constantly circulating these ideas and these approaches. We’re going to make sure that we’re very public in what we celebrate so that people know that this thing is respected and all. And then, you know, that’s sort of all the downward side within the team. And obviously you have to continue to work up and out as well to make sure that the rest of the business understands why.
this is the right approach, why this is actually a competitive advantage for the business and not just something we like to do, know, and how customers are delighted and, you know, singing praises about the fact that you fix an issue for them, you know, within hours, months or, you know, things like that. So it’s just constant effort. It’s being very clear, I think, writing things down. I’ve taken time to like write down what does
engineering excellence as the like, and sort of making sure that people can refer to that and then keeping that updated. You know, maybe that changes over time. Maybe we start to value different things over time, making sure that that’s always a durable piece of information that people can go to. And I think there’s, there’s like, as you scale, it’s the messy middle bit, that’s the dangerous bit. I think when you get to a certain scale, you just have lots of smaller companies again.
Martin (50:31.223) So, you know, you’re just sort of copying and pasting across those. But it’s that messy bit where it’s like not quite big enough to have groups that can, you know, maintain this culture themselves within the group as a unit, but also, you know, bigger than, you can go and talk to every engineer regularly and sort of help set this thing. So yeah, I think how you hire, what you value, what you recognize from reward and how clear it is to people.
what you even mean, what the expectations are.
Peppe (51:03.534) Yeah. So before wrapping up, could you share maybe with the someone that wants maybe to start implementing this in their company? Like one, two, one, two, practical steps that they should take? are the first things that they should start doing?
Martin (51:24.395) I mean, think obviously it depends as well who you are. It’s easier for me as a VP of engineering perhaps to say, hey, I want to change how engineering works.
Peppe (51:33.042) Let’s suppose for people in tech leadership. Of course it’s easier, otherwise it’s a very commission.
Martin (51:36.182) Yeah.
I think, I think, I think step one is, like really challenge yourself on why you want to do it. because it’s very easy, I think, to look at, you know, the things you read on the internet or, know, Hey, this thing’s, you know, apparently the great way to do it, but something like this is something that’s very much something you have to sort of internally build a conviction around, and a belief in now.
For me, that was perhaps easier because I’ve been an engineer. And I think if you have been an engineer before, a lot of it will just make sense. But if you haven’t, then you need to sort of really understand why this thing is the right thing and what you want to do. Step two is write it down. think use AI to challenge yourself. hey, imagine you’re an engineer reading this. Imagine you’re a CEO reading that. What are the flaws?
And in that you have to make decisions. You have to say, what does this mean to you? Because as we discussed, like it can mean a lot of different things. So what are the trade-offs? And I think that’s, if you can’t find trade-offs in what you’re doing, then you haven’t thought about it enough. think, I think with something as important as this, have to be trade-offs that you’re making. And I favor transparency here. in the doc that I wrote, it says what those trade-offs are.
and why we’ve wanted to make them. And I think if there’s nothing, no trade-offs made, it’s not, you know, perhaps worth writing down. And then the third is, you know, all of that up to that point is just a good idea and a nice doc. Then you have to really sort of roll it out and there you need partners. And so you have to find the engineers that are excited about this, that you can sort of back and amplify.
Martin (53:35.063) so that when they put themselves out there and go and do the thing that you want, you’re right there sort of celebrating it, recognizing it, calling it out and things like that. If you’re in a particular organization where you need to provide cover, I didn’t, but you need to make sure you provide cover for them, that you’ve set this scene for other leaders, the commercial leader and things. You don’t wanna be like, hey, I’ve come up with this great thing and I brought it out in my org after the fact.
You want to be explaining early on like why this is important to the business and why you’re going to do that. I think that, you know, it’s those sorts of things, but first and foremost, you got to understand why you’re doing it yourself. And if it’s just because you read it and it looks cool, it’s probably not going to work.
Peppe (54:21.294) So to recap, one, you need to internalize it and understand why you want to do in the first place, not just because you’re in somewhere. Two, you need to kind of write it down, reflect about it and understanding what are the trade-offs of this choice. And three, find allies, people that can support you in this change and trying to kind of talk with other people in leadership, trying to kind of find a collaboration.
So you can give an example.
Martin (54:53.067) Yeah, and I think also take a sense of where you’re operating. So there are some places where this would be a start small kind of thing. So you would be like, maybe I do this with one team and then when it proves successful, expand from there. Other places you might be like, go big or go home. And so just roll it out to everyone and go at it.
So I think you sort of have to think about like, what’s your execution and how you’re going to do that. would just say I’m going to with the trade-offs, not just the trade-offs of like product engineering, not, but also what’s your definition of it and your trade-offs within it. Like what are the things that you’re now convicted about? are, know, should you have product managers? What does that mean? What would they own? What would your engineers own? What are the trade-offs of that decision?
Peppe (55:34.478) Okay.
Peppe (55:48.75) Cool. Thank you. Cool. So before closing up, where can people find you if they want to get in touch with you? Where are you hanging out?
Martin (56:01.239) Yeah, I’m terrible at social stuff. I am on LinkedIn. I’m sure I’ve got accounts on Blue Sky and I’m obviously in the Discord community that you’ve created as well. So if you ping me on any of these things, I will eventually respond. Also, I have a very novel name. I have a unique name, I would say. So fortunately, I’m usually easy to find with a Google search.
Peppe (56:29.71) I’ll make sure to add all the links in the description. Okay, Martin, thank you very much for your time. And it was great having you here. It was very interesting.
Martin (56:41.313) Thank you, thank you, bye bye.
Peppe (56:43.2) Yeah. bye.