Subscribe
Share
Share
Embed
What if product managers, designers, and even VPs of Engineering are "pure overhead"? Martin, VP of Engineering at Zen Educate, makes the provocative case that engineers could technically build and maintain a product without anyone else—so every other role needs to prove they're accelerating engineering, not blocking it. His journey from building VFX pipeline tools in the film industry to leading product-led teams at Intercom shaped his conviction: engineers who love solving real user problems (and just happen to use technology) are the ones who sometimes solve problems by not building anything at all.
In this episode, we explore why "problem shapers" beat "ticket takers," how Zen Educate transformed from a world of PM-assigned tickets to engineers partnering directly with commercial leaders, and why a team of six engineers working on six different problems isn't a team—it's just people sitting together. Martin doesn't hold back on the trade-offs, the challenges of getting engineers to believe they're allowed to do this, and the practical steps for anyone trying to make this shift.
---
GUEST
Martin Östlin - VP of Engineering at Zen Educate
Martin started his career in the film industry building pipeline tools for visual effects teams before discovering product-led development at Intercom. Now he leads engineering at Zen Educate, a British startup tackling the global challenge of education staffing. He's leading the transformation from ticket takers to problem shapers across a distributed team of 40+ people.
Find Martin:
- LinkedIn: https://www.linkedin.com/in/martinpp/
- Zen Educate: https://zeneducate.com
---
TIMESTAMPS
00:00 Introduction and Welcome
01:51 Martin's Journey Through Film Industry and Tech
04:16 Before Product-Led: The World of Feature Requests
06:16 Frustrations of Being a Ticket Taker
08:43 The Aha Moment at Intercom
13:06 Leadership's Role in Fostering Product Mindset
18:35 Problem Shapers Not Ticket Takers - What It Means
23:10 Measuring Collaboration and Team Health
26:11 How Teams Are Structured at Zen Educate
28:02 A Typical Week for Engineers
30:48 How Problem Shaping Works in Practice
33:47 Handling Handoffs Between Roles
36:34 The Impact of AI Tools on Their Workflow
43:51 Challenges in the Transformation Journey
48:06 Scaling This Approach as the Company Grows
51:24 Practical Steps to Start Implementing Product Engineering
56:01 Where to Find Martin
---
KEY TAKEAWAYS
1. Engineers are the only required role - you can build and maintain a product without PMs, designers, or VPs. Everyone else is "pure overhead" that must prove they accelerate engineers rather than slow them down.
2. Problem shapers vs ticket takers - engineers at Zen Educate define problems with the team, challenge assumptions, and contribute solutions. They're not waiting for PM-written tickets or asking for sign-off before shipping.
3. Product engineers solve problems by NOT building - the best definition: "Someone who loves solving real problems for users and just happens to be skilled at leveraging technology." Sometimes the answer is zero lines of code.
4. Teams need focus to be teams - six engineers working on six different problems aren't a team, they're just people who sit together. Real teams rally around shared problems with clear accountability.
5. Three steps to implement this: (1) Internalize why you want this (not just because it sounds cool), (2) Write it down with clear trade-offs, (3) Find champions who get it and amplify their wins publicly. Start small or go big depending on your context.
---
RESOURCES MENTIONED
- Intercom (Martin's previous company)
- Lovable (AI prototyping tool)
- Figma (design tool)
- Marty Cagan's article on "product builders"
- Developer experience surveys
- Session replays and product metrics tools
- Extreme programming concepts
---
CONNECT WITH PRODUCT ENGINEERS
Host: Peppe Silletti
LinkedIn: https://www.linkedin.com/in/peppesilletti/
Product Engineers Community:
Website: https://productengineers.com
LinkedIn: https://www.linkedin.com/company/product-engineers
---
SUPPORT THE SHOW
If this episode challenged how you think about roles and ownership, share it with an engineering leader who needs to hear it. Drop a comment below with your biggest takeaway or tell us about your own transformation from ticket taker to problem shaper.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Product Engineers is the podcast about the convergence of product and engineering in the AI era: what's breaking, what's working, and the craft of doing both well.
There's no, like, nice one-line description, but the, the, the one-line description that I sort of hold in my head for what it means to be a product engineer is, you know, it's someone who loves solving real problems for users and just happens to be skilled at leveraging technology to do that, uh, as opposed to, you know, a more traditional engineer might be more focused on the tech- 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 not, 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. [rock music] Welcome, Martin. It's, it's great to have you here. Thank you. Thank you. It's good to be here.
Yeah. Cool. Yeah. So Martin, um, is the, uh, VP at engineering at, uh, Zen Educate.
Uh, it's a, it's a British, uh, startup that i- is tackling the global challenge of education, staffing to improve outcomes for children everywhere. Did I miss anything? No, no. Is that a good description? That's good.
Yeah. [chuckles] Cool. Cool. Yeah. So Martin, um, before getting into the, you know, the, the heart of this conversation, could you share with us, like, how was your
soft-- like, your, your world, your software, your software development, um, were before, let's say, getting enlightened about this new way of working that is product engineering? Yeah. Um,
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,
uh, we were using technology to solve a lot of novel problems, um, within that industry.
Uh, 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, um, 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 that today would be called pipeline.
Uh, 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 PED setup 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, uh, 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 wanna do.
Maybe it's a cool piece of technology that you've seen and, and so you fall into the trap of, um, what a lot of people end up doing, which is I have a solution, and I'm gonna go look for a problem to fit it to.
Uh, and so that was very much like in those early days of my career, perhaps, uh, looking a little bit too much at the tech before the problem. Um, 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 Intercom 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, um, from that point on. Cool. Cool. So be- before, before Intercom, how would like a typical, uh, process or, of developing like a product would look like?
It varied from place to place. Um, I think, uh, a lot of the time, uh, it would be very much like people asking for things.
Um, so you might, you might chat to, you know, you, you, you've got a supervisor on a film, and they've got a team, and that team needs something, um, 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." Uh, and you would go and build a button there that did that.
And over time, you would end up with quite an unwieldy, um, sort of product, uh, that had all these buttons that did all these things, and it become complex to use, uh, 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.
You know, it's like, can I make everything configurable all the time so that they stop asking me to add the button, they can kinda add the button themselves.
Um, and then eventually you might say, "Actually, there's a whole area of this problem that I can figure out, uh, a very particular solution, a niche solution for and build a, a product to solve that, um, 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, is um, it's always the right level of complexity for the user and the use case, uh, to solve their problem.
And actually, in that case, hiding all those things away would've been a disaster. Um, and so it's not, you know, simplicity is not always just get rid of everything and have lots of white space. Mm-hmm. Cool.
So what, what was the thing that really frustrated you the most about not working in like a, in a product-led way?I think it's two things. I think, um,
one, you never really sort of understand what you're doing and why. Um, you know, you're, you're sort of-- it's just an endless sea of requests.
And I, and I think as humans, you know, there's a lot of psychology books around, you know, mastery, purpose, and, and things like this. But I think, I think that's part of it. I think eventually,
uh, the new tech becomes mundane. The chasing new tech becomes a bit less, uh, 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, it's kind of, um, boring, uh, I think for me. Mm-hmm. 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.
Uh, particularly sort of maybe if you're working and you have multiple senior stakeholders who all have an opinion over 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, um, 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.
Uh, 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. Yeah.
Yeah. The, the word impact is a word that I hear over and over from software engineers nowadays, and the ones that are not satisfied with their job are the ones that they don't have impact.
So it's, it's something that I'm hearing over and over, so it's-- I think it's quite important.
And as you, as we were saying, it really touches in, in our human nature of we're-- we want to do-- we want to be doing something that is important, you know, helping people. So, and I can relate w-with that myself.
[chuckles] Um, so you then join Intercom, and you get exposed to this new way of working. Um, what was for you the, your aha moment? Like, what really clicked for you? I think
there were a few things, and, and I think what was interesting was, um, the aha moment being more finding common ground, common people, um, in that suddenly you had people who
believed from the very top of the company down that this was the way to build, you know, a great, uh, company, a great solution, and, and deliver, uh, a great product.
Uh, and so it wasn't sort of you on your own a little bit trying to always push this thing. It was like, "Oh, uh, it's the default path now. It's not the, the thing that you have to do alone."
Um, so I think, I think just having that like, oh, you know, um...
And not to say like this has, this had started in the film industry and towards the end of my sort of career there, um, but it was never perhaps valued as much as say it would've been at, at Intercom, who, who saw this as their competitive advantage almost from, from the get-go.
And then along with that, um, were these other people that you could leverage that I hadn't had access to before, so product managers and designers and researchers and, and specialists in these areas that could help accelerate you.
So when you, you know, um, it's very hard to be great at everything, right?
So if you're there as an engineer and, and as a product engineer, you care about the experience and all, but you just might not have the skill or the time to go deep in those areas or to, to cover as much ground.
So having these other people that you could suddenly pull on, um, and leverage was, was really great. And I think that's shaped a lot of how I like to operate today with teams, uh, as well.
And, you know, 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?
Um, and so I sort of have that experience from film to know the trade-offs that you're making. Um, and then it's more than just like who's doing the work. Yeah. Yeah. Makes sense. Um, did you have any,
um, like mentors, uh, that really guided you to develop this way of thinking? Um, even like outside of Intercom, for example, any public figure that you like to follow who was very inspiring for you?
Not really in that I'm, I'm sort of terrible at all that. You know, people ask me, "What books would you recommend reading?" [chuckles] And, and I, I tend to learn by doing.
Um, I have absolutely chatted lots to lots of, um, different folks, different leaders and, and taken perhaps a little bit from, from, uh, many of them over many, many years.
Um, and sometimes it's, it's not even the sort of people that you maybe are looking up to as, "Oh, they're doing a great job, it seems," but it's, it's the impacts that resonate throughout the years.
So it's actually the people who've contacted me years later and sort of said, "Oh, this thing that you did, that made a real difference to me." And you're like, "Oh, okay. You know, I, I wanna keep doing that.
I wanna have that." Um, but at Intercom, I, I did work with a fantastic, um, chap called Kuba, and I think he really epitomized, uh, this idea of like product mindset.
So even though he was an engineering leader, uh, he was deep into the product. He, you know, he played with the product daily. He understood the limits of the product as well.
And I think seeing that, seeing an, 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, the technical details was very inspiring, um, 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. Um, 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, um, hat.
And at Intercom, I, I shifted quite dramatically into, "I wonder if I'm any good at this people stuff."
And so I, I learned a lot through Intercom, not just about, like, the product, but also leading engineers, leading teams, and helping them deliver great outcomes. [clears throat] That's interesting.
So you're saying that there's also a big component into working with, like, this mindset by having, like, strong leaders can, can actually lead you and help you foster that mindset, right?
Yeah, 'cause I, I think there are definitely times that you can sort of fly solo and, and perhaps as a, a product engineer, like, that mindset is almost, you know, you should be able to do just about all of it end-to-end, uh, 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, um, it's about knowing how to leverage other people within your team, like whether it's other engineers or whether it's other disciplines.
Uh, 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. Mm-hmm. Yeah.
Um, recently I spoke with a startup founder, and they, they work as product engineers. So they have, they, they have a very small team of five engineers, and each of them-- It's, it's very interesting the way they work.
They have, um, of course, some product problems that they need to solve, and, uh, they don't work on features, so they work on experiments. So e-each person in the team has an experiment.
And I mean, the crazy thing is that they-- 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, um, the fact that you have all these people that are contributing to the, to the product at the same time,
at a certain point creates some conflict, of course, because everyone has different opinions. And, um, I think, I mean, I've seen different ways of,
uh, defining what a product engineer is, but in this specific one, uh, 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.
Um, is that something that you also experience, this kind of conflict? So when, when you have more people involved into, like, product work, of course, that can happen, right? Yeah.
I don't know that I've experienced it as a, a sort of a conflict. Maybe, maybe slightly. But I think, I think the greater risk and the thing that I have experienced and that happens more is,
um, a dilution of accountability and ownership. I 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?"
Um, I think there's also a risk that you A, forget why you might have those specialist roles, but B, that you just like use it as this sort of, uh, "I'm just gonna pile more work on." You know?
It's like, "Oh, the engineer can do it all." Uh, you have to provide like the supporting mechanisms to make that successful. And I think the,
the thing that I keep in my mind that I've said to a few folks, and it can sound a bit harsh, but, um, 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, um, without anyone else. Uh, so a product manager, a designer, even someone like me in my role, we're all kind of pure overhead. Uh, and so we really have to find ways to
accelerate, uh, what the engineer's doing. And I, 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, 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 then 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. Um, so I think, I think those things are important.
But when you blur the lines, yeah, it's, it's less about conflict and more about who's doing what, do 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, 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 role. Yep. Makes sense. Makes sense. So, um, we can dig into now, uh, into XEN Educate, right?
The culture, 'cause, uh, that's really what, 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, uh, XEN Educate are problem shapers, they're not ticket takers.
And w-what, what does it, what does it mean exactly?In practice Yeah, it's a very, it's a very catchy phrase.
Um, and I would say, like, we are-- One of the things I like about Zen and perhaps as a, as a story, um, to the folks watching and all, is this is, this is a journey for us as well. Like, we, we started when I joined,
being a little close to perhaps being ticket takers, not quite, but, um, we had
an expectation of engineers and a, and a process where, you know, a product manager would write all your tickets, uh, and sort of hand them off and assign them to engineers, and engineers would then implement them.
And then, you 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, and that's just all very slow, but also quite not fun, I think, for, for engineers. And so we set about going on this journey of, of being more product engineer, uh, sort of mindset and, and attitude.
And that, that has been a shift. And so now what we see is, um, still leveraging product managers, uh, to help,
you know, scope things to say these are the important problems that we're hearing, uh, when we look around at the different use cases that we have, but involving engineers in that discussion, um, 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, uh, in solving it?"
And similarly at the design stage as well, where a designer might be ideating on what it's actually gonna look like as a solution.
Engineers now being invited and included in that discussion and, 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 gonna take longer. That's gonna delay getting the value into users' hands. It's gonna delay us learning. Um, 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 definement.
There's a technical sort of assessment of, of what we need to do or change, um, at an architectural level to make this work, and then an implementation and, and rollout phase. And so they are a bit da, da, da.
And what we're seeing is with the engineers that have really embraced this product engineering mindset, those loops and those feedback loops are getting tighter and tighter and, and, you know, people are almost starting to say
they're butting up against that sequential process and they're wanting to move faster, which is, um, obviously what you want to happen, um, ultimately is you get this wonderful sort of feedback loop going. Um,
there are also extreme cases. Um, we, we, we try not to think about there's one size to fit all.
We try to 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, um, and just worked directly with that commercial leader to at least spike out a solution to a problem before an entire, you know, team takes it on and works with it.
And that's been very successful as well and, uh, also a lot of fun for everyone, I think, uh, especially on the commercial side to suddenly get a closer glimpse of like, "Oh, what does it mean to actually build something and iterate on it?"
[clears throat] For, for commercial leader, you mean like as salespeople or- Yeah. Yeah. So like- Yeah... an account manager or a- Account manager... sales leader or someone. Um,
and, and one of the things I should sort of outline, like one of the things that I really enjoy about Zen and why I, I joined it partly is it's one of those unusual companies that does operations and products, and it's the mix of these things that's its sort of, um, secret sauce, as it were.
So it's, you know, when we're using technology, um, we're providing that technology both to internal teams and external schools and educators, and sort of all of those things working together, um, is what allows us to, like, deliver great experiences in terms of filling staff vacancies quickly and to high quality.
Cool. So what, what do you, what would you say it's that like a, um, a signal that things are not working properly anymore, like in terms of collaboration? So what, what are you looking for exactly?
Uh, collaboration, um, between-- within a team, do you mean, or? Yeah. Let, let's say the team is working on maybe a, a new product initiative. Um, so I guess are, are you like, um,
measuring something or like quality, qual- qualitatively or quantitatively? Uh, or like how, how do you make sure that the, this way of working is kind of, um, is working? [chuckles] Of course. Yeah. Okay. Yeah.
Um, I mean, we're, we're small enough, like the product org's under 40 people. Um, so we're small enough that you can get by a lot with just talking to people. Um- Okay... and so definitely just checking in.
You 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.
Uh, we've also invested in like a developer experience initiative, um, whereby on a regular cadence, roughly every six weeks, we're actually, um, sending out survey to engineers and asking them, you know, some common questions, uh, every time, but also some new questions, uh, 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, you know, if, uh, if you can't do anything, you know, if, if you have data or asking people and you have to choose between them, then ask people 'cause engineers know.
Um, and then we've definitely leaned into that.Um, so I think, 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, uh, faster perhaps?
Are we, uh, doing it more sustainably? Um, so we track, uh, the sort of the quality of the work, um, how many issues are being reported when we release things, and all, how quick are we to address those.
Uh, and also sort of, uh, the sustainability or the efficiency of that.
Um, but yeah, a lot of it's just talking to people, listening to people, and then picking up on signals and, and chasing them down and sort of more often than not in my role, uh, are not very, you know, sort of obvious, but you know, someone used to it kind of thing of sometimes it's just getting people to talk.
Um, but we don't, we don't really have too much around that. I'd say, I'd say a lot of the time, um,
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. Like you just have a bunch of people who sit together. Yep. Yeah, so how, how are the teams structured so that this collaboration can be productive?
So we've, uh, sort of gone like the, the classic stream-aligned teams, um, where we've tried to identify a clear end user, um, that that team can, uh, revolve around.
So for us, there's an educator, uh, 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, um, and how they sort of put roles out there and find the right educators.
Uh, there's a marketplace team, which is like the intersection of those two, which is a bit funky.
You know, that's, 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, an 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 a school's phoning up, uh, an account manager, how can we make that account manager more effective, um, and more like up to speed on what's going on in that school, uh, so that they can help and provide adequate support and relationship to that.
Um, and that's very much about helping humans do what humans are great at, uh, by taking away some of the sort of more admin-y stuff, um, that they might be responsible for.
And then we have a very small team off to the side, uh, which is the sort of enabling team.
That's the one focused on the developer experience, focused on things like, uh, can we improve sort of how fast our CI, uh, is running because, you know, maybe that's identified as something that's slowing us down. Cool.
So let's take, um, let's think about the, um, um, typical week for one of the engineers at XEN Educate. How, how would it look like? It depends team by team.
We try to say there's a standard interface of things, um, in terms of all of the teams, but we give a lot of freedom and flexibility then within a team to how they operate.
Um, 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.
Um, some of the variations that you might experience is, uh, some will do it async, so it'll be sort of post on Slack, uh, whereas some will, you know, get together on a call.
Uh, we're a distributed team, uh, by the way, so we're mostly sort of joining, uh, meet calls and things. Mm-hmm.
Uh, 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, and doing that sort of shaping together as a team.
Similarly, the designer might be, um, outlining the sort of ideas that we have for how we could go solve a problem. Um, some of the engineers might be involved in technical planning.
And for me, technical planning is very much about are there 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, like let's write that up and get some input from the wider team before we move forwards.
Uh, they might be writing their own tickets, breaking down work, iterating, doing QA, um, shipping, monitoring, you know, the impact of those things and the observability systems and the product metrics, uh, sort of systems.
So it's, it's kind of varying over every two weeks. You know, it's kind of a, a mix of these things. We are sort of running this sort of two-week sprint, uh, approach, but we might mix that up soon.
Um, that was very much like helping teams find a bit of structure. Um, but we're now seeing teams, as I said, being able to move quite fast without all of that mechanics. Um, so yeah, it 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, uh, and things like that. Cool. [clears throat] So, uh, I, I like to kind of
understand how different companies are implementing like the, the product engineering approach. And so for what I understand
XEN Educate, um, so the problem shaper means that engineers are, are involved in shaping the problem with the product manager and the designers all together.
So they are, let's say, they're all pro- shaping the problem all together, right?Yes. I mean, there are definitely--
So there's no, there's no blocker around as an engineer actually saying, "Hey, I've identified the problem," and bringing it to the team.
Um, but from a sort of sheer who's got the muscle, who's got the time and, and the focus, that is predominantly coming from the product manager, uh, the sort of source of those things.
But again, we're not putting a restriction on that. So, um, yes, mostly engineers are contributing to the discussion, uh, and shaping in that way.
Um, but there are a few engineers who might also be saying, "Actually, I, I see the problem here and I'm gonna bring it, um, to the team." Cool. It makes me think about this new--
It's not new concept, but I'm, I'm, I'm reading out about the product builder trend. It's like, uh, I think it was out of an article from Marty Cagan.
And, uh, so like everyone is becoming a product builder now, but they'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, um, it's, it's important, of course, that there is this collaboration and
diff- people with different point of views a- and, uh, experiences can contribute to the final outcome. Um- Yeah. Like, um,
like for me, 'cause I've, you know, I've thought about this a lot and all, and I think there's no like nice one-line description, but the, the, the one-line description that I sort of hold in my head for what it means to be a product engineer
is, you know, it's someone who loves solving real problems for users and just happens to be skilled at leveraging technology to do that.
Uh, as opposed to, you know, a more traditional engineer might be more focused on the tech- technical side. Uh, 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 not, 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. Um. Yeah.
The best line of code is the one you don't write, right? Yeah. Yeah. Yeah. Um, so I, I was, I was thinking about how, how do you handle handoffs?
Like for ex- because I can imagine, mm, maybe a designer has to, you know, create the user experience at a certain point, just stop and doing the, doing it, and then the engineer has to implement it.
Um, and I mean, in my experience, this can create some delay, of course, because you need to wait for something to happen from s- for, for some artifacts to be created. So it, it could be a blocker.
So how, how do you handle this in, within your teams, generally speaking? So at the start of the year, we, we rolled out quite a structured process, um, to sort of provide support for that.
And, and so that's actually a process that takes place over six weeks. Um, and you can imagine sort of four weeks lead up to the sprint execution phase. And so- Mm-hmm...
in the first, uh, sort of week or 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.
Um, and then following on from that, you know, are we designing it, uh, in a certain way? What are the solutions that we might wanna 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've sort of tackled that, that main, are we laying the tracks, you know, far enough ahead that the team can run at it well?
Um, as teams have got more, uh, effective at working together, like they can shorten those lead times.
Um, but where we've seen sort of some of, you mentioned tension ear- where we've seen some of the tension in the past is, uh, if those things get too compressed. You know, if, if the sort of problem,
uh, document, you know, is sort of landed on people, it's like, "Ah, 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, uh, and give response, but not so far ahead that you're like, "Oh, we decided everything here, and then we forgot all about it and the world changed.
And so when we actually go to build it, we're out of date." Um, so for us at the moment, it's around six weeks. Um, but we're, we're sort of open to experimenting with that.
And then handoffs, again, it's, it's relationships.
We try to build these teams that are cross-functional, so product manager, designer, engineering, uh, engineers and, and sort of tech lead managers are the indivisible unit of a team.
Uh, and they're all working and collaborating closely. So how they do handoffs again varies within the team. Sometimes, uh, an engineer might just sit with a designer and rapidly iterate while they're talking.
Other times, a designer might, you know, produce, uh, a detailed, you know, uh, Figma design or a lovable app or something to show what they're thinking and communicate that way. Mm-hmm.
[clears throat] Well, I must ask, um, did, did the rise like of AI tools, like do you see any difference since they started to become more mainstream and in the way you work? Um, a little bit, yeah. I mean, I think, um,
I think what's interesting is we, we're very much, uh, an experimental, um, approach and attitude to AI.
So we're not a company, um, and certainly not in product that's sort of ridden the, "Everyone will be four times more efficient. Let's, you know, do this."
We've leaned 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, and figure it out."
AndI'd say we've seen sort of some of the biggest gains in the work around the work. So actually things like communication.
You know, we, we have, uh, a diverse set of people from different backgrounds, different languages and all, and, and I'd say a lot of folks are now leveraging AI just to be clearer in their communication, uh, or to summarize and understand, you know, longer, uh, data sets.
And so that's actually been quite useful, uh, in terms of how these, these teams work together. And then engineers have been picking that up, um, more in the day-to-day sort of coding.
Uh, we did an AI survey recently, um, over half of our engineers, you know, are using sort of more of the agentic AI approach where, you know, they're sort of starting from, "Well, let's plan together and iterate," rather than, "Hey, can you just auto-complete something?"
Uh, we've got some designers who've leant into like actually creating PRs, uh, and shipping fixes, particularly on the styling side. Mm. Um, 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, um, why not give it a go and, and see how far you get. Um, and yeah, product managers, I think, uh, 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, "Yeah, I did the work and I handed it off to you," 'cause then you're kinda like, what's the point of you? You need to add the value and be able to stand behind it.
Uh, but product managers, you know, there's a lot of information you have to deal with, and that's across stakeholders, users, uh, 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, um, that you wanna use.
Yep. Makes sense. Now, the last thing you said is interesting. It's something I usually think about, like that PMs have all these things to do, and they usually are one person.
[chuckles] Um, like, uh, do you see this changing over time? Like m- most of all now that different, let's say, traditional roles are getting more responsibilities, uh, like getting the PMs
like a bit less busy so they can, can focus more on, on strategic work, I don't know, and distribute the, the other responsibility across the team. Yes. Um, I mean, I think,
uh, 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, um, overall.
Like it, it just increases the number of things that humans can go after and also raises the bar.
You know, like the, the quality or that you expect from a product today is far beyond what, you know, you expected 10, 15, 20 years ago. Um, so we, we, we as humans tend to, I think, fill that void.
You know, we, we create the ability to do more, and then we, we create more to do. Um, but I do think the roles shift slightly and, and change slightly.
Um, but at the same time, all these things, I think, are things that can happen anyway. It's just a, another tool.
So, um, 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, uh, empower your engineers to write their own tickets and pull on you when they need to clarify things.
So there it would be a terrible solution to say, "Well, as the PM, I'm gonna leverage AI to write all my tickets for me and assign them to the right engineers." Um, 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 know, how do you scale yourself is, is often the question.
And I think there's interesting, like can you train, uh, 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, uh, something that we'll be able to do and, and do effectively. I think the hard thing with AI, as I sort of see it today, is it's not reliable.
Uh, and, and if it's not reliable, then a lot of those gains disappear because if I'm gonna 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, um, if I then have to like think each time, "Oh, do I trust it or not?" Yeah.
Makes sense. Yeah. I mean, probably there are better activities to, to spread knowledge. Maybe... I'm thinking about like extreme programming, for example. It's, uh,
it has a lot of activities that help spreading knowledge, like pair programming and, um, uh, like I, I, I'm thinking maybe it's also time
to do like maybe pair programming between different roles, not only between engineers, but also with program managers and designers. So you always have this kind of knowledge sharing,
uh, that would happen like automatically, right? Yeah.
And I think, I think we've all seen, you know, the, 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, and so I think some of what we have now is, is wonderful 'cause you can start to put that in a place that remains searchable and approachable and, and, you know, we have the ability for, um, 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. Um, equally, an engineer who's joining the team,
um, you know, might wanna be asking like, "What do I need to think about when working on this part of the, 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. Cool. So on a different note, um,
you said that you are, as Zen educator, is in this journey, uh, to experiment with this new approach, and so you're still seeing how it works out.
Um, what have been like the main challenges that you've, you've faced during this process with implementing your assistance?
Anything that you s- you, you haven't seen working and then you had to tweak it to make it work? What's been your experience? I think the thing, um,
that's maybe a bit sort of obvious and, and simple, but is, is the thing, is, is just the need to constantly tell people and reinforce that you can do this.
Um, I think, um, you know, if, if you've had people working a certain way and suddenly you, you change that, there's always gonna be some nervousness. Um, like, "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 manager's toes here? I don't wanna, you know, upset them.
Um, 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's gonna thank you 'cause as we've said, they've got a lot to do, you know?
Um, 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, maybe I haven't really thought about, um, user problems in this way, customer problems. Maybe I don't understand the commercial aspects of the business and why, you know, these things are important.
And so there it comes down to, like, do you have that curiosity? And I, I think that's such an important trait of engineers is, is to be curious.
And I think a lot of engineers are engineers 'cause they're curious about things. Um, and so it's about leveraging that as well and being like, "It's okay to not know. It's okay to get it wrong." You know?
Um, 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, uh, and we wanna support that.
I think those are the things that we've had to sort of repeat, uh, 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, uh, you know, it's like a couple of months at least 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, and re-emphasizing that.
Um, I think those are the main things, yeah, that we, we sort of see as a challenge, uh, beyond the stuff that we talked about earlier about, like, then, you know, what falls through the cracks, are we clear on at the end of the day who's accountable for certain things?
Yeah. [clears throat] Yeah. No, I can imagine how it's important that all the company also agrees on, on this, like not only the engineering department, uh, but also like, uh, the product and everyone. Um- Yeah.
I mean, if you- Yeah...
if you do this and you don't set expectations, and you know, your, your sort of CEO or someone you just see suddenly everything grind to a halt and nothing's getting shipped anymore, then you know, that's, that's tough.
Um, so you need to set expectations, but also look for, 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, and you can sort of leverage them to do something really quickly and well and show the success of it.
Cool. So I want to pause a second just to see if, are there any questions. Um, so if a- if anyone has any questions, please write them down so we can answer them. Uh, I don't see anything in the chat yet, so
let me just see if I... Let me refresh the page. Nope. Okay. So if anything pops up, we'll, uh, I'll pick it up later. Um,
how do you see this approach scaling as a company grows?
'Cause I think when a company's smaller, it's easier, a- 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, um,
around like around every- everyone and everything. But as, as company grows, uh, so they have like a lot of teams and maybe even different kind of sub-products and everything. How do you see this working at scale?
I think, um, I think as with anything, like 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, I think anyone, you know, I'm under no illusion if we, 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'll stay, you know, forever," um, that doesn't, 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, the other mechanics within the system, like performance reviews and things.
Um, but I think if you, if you have that kernel from the start and you, 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, uh, so I'm not gonna put them all in one team over here.
You know, I'm gonna spread them out. I'm gonna set up a way for people to go on tour with different teams, different areas of the business, so we're constantly circulating, uh, these ideas and these approaches.
We're gonna make sure that we're very public in what we celebrate, um, so that people know that this thing is respected and all."
Uh, and then, you know, that's sort of all theUh, downward side within the team, and obviously you have to continue work up and out as well to make sure that the rest of the business understands why, uh, this is the right approach, um, why this is actually a competitive advantage, uh, for the business and not just something we like to do, you know.
And how, uh, customers are delighted and, you know, singing praises about the fact that you fixed an issue for them, you know, within hours, not months or, you know, things like that.
Um, so it's, it's just constant effort. It's being very clear. I think writing things down. Um,
I've taken time to like write down what does engineering excellence at Zen look like, um, and sort of making sure that people can refer to that and then keeping that updated. You know, maybe that changes over time.
Um, maybe we start to value different things over time, making sure that that's always a durable piece of information, um, that people can go to.
And I think there's, 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.
Um, so you know, you're just sort of copying and pasting across those.
Um, 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, as a unit, but also, you know, bigger than, "Hey, you can go and talk to every engineer regularly and sort of help set this thing."
Um, so yeah, I think, I think work, how you hire, what you value, what you recognize and reward, and how clear it is to people what you even mean, what the expectations are. Yep.
So before wrapping up, could you share maybe with the-- someone that wants maybe to start implementing this in their company, um, like one to, one to three practical steps that they should take.
What are the first things they should start doing? I mean, I think, um, obviously it depends as well who you are.
You know, it's, it's easier for me as a VP of engineering perhaps to say, "Hey, I wanna change how engineering works." Uh- Let's suppose, let's suppose for people in, in tech leadership. So of course- Yeah...
it's easier, otherwise it's, it's a very- I think, I think-... tough commission. I think step one is, um, like really challenge yourself on why you want to do it. Um, because it's very easy, I think, to look at,
you know, the things you read on the internet or, you know, "Hey, this thing's, you know, apparently the great way to do it."
But something like this is, it's something that's very much something you have to sort of internally build a conviction around, um, and a belief in.
Now, for me, that was perhaps easier because I've, I've been an engineer, and I think if you have been an engineer before, um, a lot of it will just make sense.
But if you, if you haven't then, you know, you need to sort of really understand why this thing, um, is the right thing and, and, and what you wanna do. Um, step two is write it down, I think. Um,
use AI to challenge yourself. You know, like, hey, uh, imagine you're an engineer reading this, imagine you're a CEO reading this. What are the, what are the flaws? And, and in that, you have to make decisions.
You have to say, what does this mean to you? Because as we've discussed, like it can mean a lot of different things. So, um, 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.
I think, I think with something as important as this, there have to be trade-offs that you're making, and I favor transparency here.
So in the doc that I wrote, it says what those trade-offs are and why we've wanted to make them. Um, and I think if there's nothing, no trade-offs made, then it's, it's not, you know, perhaps worth writing down.
And then the third is, you know, all of that up, up to that point is just a good idea and a nice doc. Um, then you have to really sort of roll it out and, and there you need partners.
Uh, and so you have to find the engineers that are excited about this, that you can sort of back and amplify 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, um, and things like that.
Uh, if you're in a particular organization where you need to provide cover, you know, um, I didn't, but like you need to make sure you provide cover for them, that you've set, um,
this scene for other leaders, you know, the, the commercial leader and things. You know, you don't wanna be like, "Hey, I've come up with this great thing and I've rolled it out on my own," after the fact.
You wanna, you wanna be explaining early on, like why this is important to the business and why you're gonna do that. And I think that, you know, it's those sorts of things.
But first and foremost, you gotta understand, uh, why you're doing it yourself. And, and if it's just 'cause you read it and it looks cool, it's probably not gonna work. Yeah. [clears throat] So to recap.
One, you need to internalize it and understand why you want to do it in the first place, not just because you're already somewhere.
Two, um, 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, like people that they can support you in this change and trying to,
uh, kind of talk with other people in leadership, trying to kind of find a collaboration, so you can give an example. Yeah. And, um, and I think also take a sense of where you're operating.
Um, 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, you know, expand from there. Yeah.
Other places you might be like, go big or go home. Um, and so just roll it out, you know, to everyone, all the... you know, and, and go at it.
So I think you sort of have to think about like what's your execution and how you're gonna do that. I would just say on point two with the trade-offs, not just the trade-offs of like
product engineering or not, but also what's your definition of it and your trade-offs within it. Okay. Um, like what are the things that you're now convicted about?
Um, what are-- you know, should you have product managers? What does that mean? Um, what would they own? What would your engineers own? What are the trade-offs of that decision? Cool. Thank you. Um, cool.
So before closing up, uh, what-- where can, where can people find you if they want to get in touch with you? Where are, where are you hanging out? Yeah. I'm terrible at social stuff. [chuckles] But I am on LinkedIn.
Uh, I'm sure I've got accounts on Blue Sky and, and, uh, I'm obviously in the Discord, uh, community that you've created as well. Um, so if you, if you ping me on any of these things, uh, I will eventually respond.
Uh, also, I have a very, uh, uh, novel name. I have a unique name, I would say. Um, so, uh, fortunately, I'm usually easy to find with a Google search. Okay. I'll make sure to add all the links in the description. Yeah.
Okay, Martin. Um, thank you very much for your time, and it was great having you here. It was very interesting. Thank you. Thank you, Pepe. Yep. Well, bye-bye. Bye.