Software Engineers As Problem Shapers (Not Ticket Tackers)

WEBVTT
1
00:00:00.100 --> 00:00:22.660
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.
2
00:00:22.800 --> 00:00:30.600
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.
3
00:00:30.740 --> 00:00:46.140
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.
4
00:00:46.280 --> 00:00:54.760
Yeah. Cool. Yeah. So Martin, um, is the, uh, VP at engineering at, uh, Zen Educate.
5
00:00:55.540 --> 00:01:09.330
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.
6
00:01:09.340 --> 00:01:21.520
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
7
00:01:23.500 --> 00:01:37.920
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,
8
00:01:39.760 --> 00:01:50.740
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,
9
00:01:51.780 --> 00:01:56.600
uh, we were using technology to solve a lot of novel problems, um, within that industry.
10
00:01:56.980 --> 00:02:07.700
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?
11
00:02:07.760 --> 00:02:13.530
And that was the area that I found myself in, which was something that today would be called pipeline.
12
00:02:14.200 --> 00:02:23.920
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.
13
00:02:24.800 --> 00:02:35.360
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.
14
00:02:35.420 --> 00:02:45.420
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.
15
00:02:45.720 --> 00:02:58.020
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.
16
00:02:58.120 --> 00:03:09.800
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.
17
00:03:10.060 --> 00:03:23.020
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.
18
00:03:23.820 --> 00:03:25.620
But I would say when I really found
19
00:03:26.940 --> 00:03:43.540
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.
20
00:03:43.580 --> 00:03:59.360
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?
21
00:04:01.640 --> 00:04:09.380
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.
22
00:04:09.740 --> 00:04:20.820
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.
23
00:04:20.840 --> 00:04:27.880
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.
24
00:04:28.100 --> 00:04:40.600
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.
25
00:04:41.390 --> 00:04:51.340
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.
26
00:04:51.480 --> 00:04:58.760
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.
27
00:04:59.540 --> 00:05:11.880
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."
28
00:05:12.480 --> 00:05:18.220
And I think what was interesting about my sort of experience, particularly in the film industry, is
29
00:05:19.180 --> 00:05:31.200
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.
30
00:05:31.240 --> 00:05:39.920
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.
31
00:05:39.950 --> 00:05:51.740
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.
32
00:05:52.660 --> 00:06:03.932
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,
33
00:06:05.952 --> 00:06:15.052
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.
34
00:06:15.092 --> 00:06:25.412
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,
35
00:06:26.552 --> 00:06:37.592
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?"
36
00:06:38.272 --> 00:06:48.472
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.
37
00:06:49.352 --> 00:06:55.772
And where you also see a lot of frustration is, of course, the people that you're talking to don't all agree.
38
00:06:56.812 --> 00:07:08.892
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.
39
00:07:09.572 --> 00:07:19.892
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.
40
00:07:19.972 --> 00:07:27.871
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.
41
00:07:28.952 --> 00:07:40.792
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.
42
00:07:42.012 --> 00:07:54.032
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.
43
00:07:54.672 --> 00:07:58.212
So it's, it's something that I'm hearing over and over, so it's-- I think it's quite important.
44
00:07:59.092 --> 00:08:11.091
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.
45
00:08:11.242 --> 00:08:29.072
[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
46
00:08:30.612 --> 00:08:45.132
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
47
00:08:46.772 --> 00:08:56.872
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.
48
00:08:57.712 --> 00:09:07.012
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."
49
00:09:07.732 --> 00:09:11.792
Um, so I think, I think just having that like, oh, you know, um...
50
00:09:12.012 --> 00:09:27.552
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.
51
00:09:28.381 --> 00:09:42.272
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.
52
00:09:42.372 --> 00:09:46.092
So when you, you know, um, it's very hard to be great at everything, right?
53
00:09:46.192 --> 00:09:58.112
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.
54
00:09:58.192 --> 00:10:09.712
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.
55
00:10:09.752 --> 00:10:17.812
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?
56
00:10:18.552 --> 00:10:33.812
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,
57
00:10:35.032 --> 00:10:49.432
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?
58
00:10:51.052 --> 00:10:59.342
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.
59
00:10:59.572 --> 00:11:12.432
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.
60
00:11:12.552 --> 00:11:25.692
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.
61
00:11:25.712 --> 00:11:35.272
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.
62
00:11:35.352 --> 00:11:47.652
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.
63
00:11:47.732 --> 00:11:58.092
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.
64
00:11:58.132 --> 00:12:06.148
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...
65
00:12:06.208 --> 00:12:18.568
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.
66
00:12:18.628 --> 00:12:26.728
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.
67
00:12:26.768 --> 00:12:35.528
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.
68
00:12:35.548 --> 00:12:40.808
And at Intercom, I, I shifted quite dramatically into, "I wonder if I'm any good at this people stuff."
69
00:12:40.868 --> 00:12:53.528
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.
70
00:12:53.568 --> 00:13:06.628
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?
71
00:13:08.048 --> 00:13:23.408
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.
72
00:13:24.188 --> 00:13:25.848
But you'll always hit a limit.
73
00:13:25.888 --> 00:13:37.068
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.
74
00:13:37.748 --> 00:13:50.508
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.
75
00:13:50.648 --> 00:14:04.328
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.
76
00:14:04.358 --> 00:14:17.908
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.
77
00:14:17.938 --> 00:14:27.268
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."
78
00:14:28.108 --> 00:14:37.708
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,
79
00:14:38.708 --> 00:14:48.328
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,
80
00:14:49.308 --> 00:15:02.428
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.
81
00:15:02.728 --> 00:15:15.048
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.
82
00:15:15.148 --> 00:15:25.648
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,
83
00:15:26.748 --> 00:15:37.528
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.
84
00:15:37.988 --> 00:15:44.288
Particularly if you do have like dedicated product manager and designer roles, and suddenly you're asking engineers to lean in there.
85
00:15:44.328 --> 00:15:51.668
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?"
86
00:15:52.608 --> 00:16:05.648
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?
87
00:16:05.688 --> 00:16:13.307
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,
88
00:16:14.228 --> 00:16:27.608
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,
89
00:16:28.548 --> 00:16:45.208
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
90
00:16:46.188 --> 00:16:52.628
accelerate, uh, what the engineer's doing. And I, I think that's where that idea of leverage comes in.
91
00:16:52.688 --> 00:17:09.428
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.
92
00:17:09.488 --> 00:17:18.508
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.
93
00:17:18.548 --> 00:17:28.728
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,
94
00:17:29.648 --> 00:17:41.688
"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."
95
00:17:42.008 --> 00:17:58.228
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?
96
00:17:58.368 --> 00:18:06.308
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.
97
00:18:07.028 --> 00:18:16.508
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.
98
00:18:17.428 --> 00:18:23.380
And w-what, what does it, what does it mean exactly?In practice Yeah, it's a very, it's a very catchy phrase.
99
00:18:23.560 --> 00:18:38.160
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,
100
00:18:39.420 --> 00:18:44.110
being a little close to perhaps being ticket takers, not quite, but, um, we had
101
00:18:45.160 --> 00:18:57.480
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.
102
00:18:58.200 --> 00:19:06.080
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.
103
00:19:07.160 --> 00:19:20.880
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.
104
00:19:20.900 --> 00:19:29.320
And that, that has been a shift. And so now what we see is, um, still leveraging product managers, uh, to help,
105
00:19:30.260 --> 00:19:44.620
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?
106
00:19:44.680 --> 00:19:52.920
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?"
107
00:19:53.560 --> 00:19:59.700
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.
108
00:20:00.640 --> 00:20:10.500
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."
109
00:20:10.520 --> 00:20:21.620
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.
110
00:20:21.680 --> 00:20:31.199
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.
111
00:20:31.320 --> 00:20:43.290
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.
112
00:20:43.300 --> 00:20:54.960
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
113
00:20:55.980 --> 00:21:07.920
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,
114
00:21:08.840 --> 00:21:14.020
there are also extreme cases. Um, we, we, we try not to think about there's one size to fit all.
115
00:21:14.160 --> 00:21:21.420
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.
116
00:21:21.500 --> 00:21:37.960
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.
117
00:21:38.000 --> 00:21:50.000
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?"
118
00:21:50.780 --> 00:21:59.549
[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,
119
00:22:00.940 --> 00:22:18.880
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.
120
00:22:18.940 --> 00:22:38.340
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.
121
00:22:40.079 --> 00:22:52.540
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?
122
00:22:54.420 --> 00:23:10.060
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,
123
00:23:11.000 --> 00:23:27.820
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.
124
00:23:27.920 --> 00:23:41.840
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.
125
00:23:41.880 --> 00:23:49.480
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.
126
00:23:50.020 --> 00:24:11.440
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.
127
00:24:11.480 --> 00:24:23.040
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.
128
00:24:23.160 --> 00:24:35.924
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?
129
00:24:35.994 --> 00:24:48.304
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.
130
00:24:49.064 --> 00:24:53.704
Uh, and also sort of, uh, the sustainability or the efficiency of that.
131
00:24:54.084 --> 00:25:10.224
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.
132
00:25:10.964 --> 00:25:18.504
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,
133
00:25:20.164 --> 00:25:33.044
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.
134
00:25:33.494 --> 00:25:43.244
'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,
135
00:25:44.184 --> 00:25:55.564
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?
136
00:25:57.084 --> 00:26:09.084
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.
137
00:26:09.144 --> 00:26:16.844
So for us, there's an educator, uh, who's using predominantly our mobile app to find work and sort of upload their preferences.
138
00:26:17.444 --> 00:26:25.264
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.
139
00:26:26.004 --> 00:26:30.524
Uh, there's a marketplace team, which is like the intersection of those two, which is a bit funky.
140
00:26:30.744 --> 00:26:39.944
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.
141
00:26:40.664 --> 00:26:50.784
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?
142
00:26:50.864 --> 00:27:05.844
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.
143
00:27:05.944 --> 00:27:14.544
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.
144
00:27:15.224 --> 00:27:20.104
And then we have a very small team off to the side, uh, which is the sort of enabling team.
145
00:27:20.124 --> 00:27:33.644
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.
146
00:27:34.284 --> 00:27:49.864
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.
147
00:27:49.944 --> 00:28:01.864
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.
148
00:28:02.704 --> 00:28:09.464
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.
149
00:28:10.104 --> 00:28:19.304
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.
150
00:28:20.004 --> 00:28:26.184
Uh, we're a distributed team, uh, by the way, so we're mostly sort of joining, uh, meet calls and things. Mm-hmm.
151
00:28:26.504 --> 00:28:37.824
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.
152
00:28:38.184 --> 00:28:48.514
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.
153
00:28:49.424 --> 00:29:01.024
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?
154
00:29:01.054 --> 00:29:06.144
And if so, like let's write that up and get some input from the wider team before we move forwards.
155
00:29:07.044 --> 00:29:20.104
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.
156
00:29:20.684 --> 00:29:31.583
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.
157
00:29:31.884 --> 00:29:43.164
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.
158
00:29:43.724 --> 00:29:52.584
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.
159
00:29:52.614 --> 00:30:06.944
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
160
00:30:07.864 --> 00:30:15.864
understand how different companies are implementing like the, the product engineering approach. And so for what I understand
161
00:30:16.904 --> 00:30:28.264
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.
162
00:30:28.344 --> 00:30:35.684
So they are, let's say, they're all pro- shaping the problem all together, right?Yes. I mean, there are definitely--
163
00:30:37.264 --> 00:30:46.604
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.
164
00:30:47.344 --> 00:30:58.474
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.
165
00:30:58.544 --> 00:31:06.804
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.
166
00:31:07.504 --> 00:31:19.654
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--
167
00:31:21.124 --> 00:31:29.204
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.
168
00:31:30.164 --> 00:31:37.764
And, uh, so like everyone is becoming a product builder now, but they're just bringing different expertise from different point of views.
169
00:31:37.904 --> 00:31:51.424
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
170
00:31:52.444 --> 00:32:00.144
diff- people with different point of views a- and, uh, experiences can contribute to the final outcome. Um- Yeah. Like, um,
171
00:32:01.304 --> 00:32:14.664
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
172
00:32:15.564 --> 00:32:23.684
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.
173
00:32:24.464 --> 00:32:36.724
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?
174
00:32:36.764 --> 00:32:48.724
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.
175
00:32:49.344 --> 00:33:01.084
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?
176
00:33:01.924 --> 00:33:16.444
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.
177
00:33:17.424 --> 00:33:27.504
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.
178
00:33:27.664 --> 00:33:43.004
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.
179
00:33:43.124 --> 00:33:56.024
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...
180
00:33:56.084 --> 00:34:08.684
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.
181
00:34:09.764 --> 00:34:17.744
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?
182
00:34:18.424 --> 00:34:30.844
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?
183
00:34:31.724 --> 00:34:39.624
Um, as teams have got more, uh, effective at working together, like they can shorten those lead times.
184
00:34:39.844 --> 00:34:50.024
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,
185
00:34:51.044 --> 00:35:00.304
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.
186
00:35:00.384 --> 00:35:16.464
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.
187
00:35:16.484 --> 00:35:24.564
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.
188
00:35:25.284 --> 00:35:27.494
And then handoffs, again, it's, it's relationships.
189
00:35:27.564 --> 00:35:40.244
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.
190
00:35:40.904 --> 00:35:51.964
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.
191
00:35:52.504 --> 00:36:04.884
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.
192
00:36:05.764 --> 00:36:22.414
[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,
193
00:36:24.224 --> 00:36:31.834
I think what's interesting is we, we're very much, uh, an experimental, um, approach and attitude to AI.
194
00:36:31.964 --> 00:36:39.963
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."
195
00:36:40.644 --> 00:36:51.364
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."
196
00:36:51.444 --> 00:36:58.824
AndI'd say we've seen sort of some of the biggest gains in the work around the work. So actually things like communication.
197
00:36:58.964 --> 00:37:15.884
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.
198
00:37:15.944 --> 00:37:25.704
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.
199
00:37:25.884 --> 00:37:41.504
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?"
200
00:37:42.524 --> 00:37:53.664
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?
201
00:37:53.784 --> 00:38:06.964
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.
202
00:38:06.984 --> 00:38:11.984
And all of these things come with like you need to be able to stand behind the output of this tool.
203
00:38:12.624 --> 00:38:22.284
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.
204
00:38:23.004 --> 00:38:38.424
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.
205
00:38:40.344 --> 00:38:51.684
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.
206
00:38:51.823 --> 00:39:05.364
[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
207
00:39:06.584 --> 00:39:21.384
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,
208
00:39:22.784 --> 00:39:33.064
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.
209
00:39:33.284 --> 00:39:39.544
Like it, it just increases the number of things that humans can go after and also raises the bar.
210
00:39:39.624 --> 00:39:54.044
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.
211
00:39:54.144 --> 00:40:02.744
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.
212
00:40:03.064 --> 00:40:09.604
Um, but at the same time, all these things, I think, are things that can happen anyway. It's just a, another tool.
213
00:40:09.664 --> 00:40:20.544
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.
214
00:40:20.604 --> 00:40:26.504
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.
215
00:40:26.544 --> 00:40:37.604
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
216
00:40:38.764 --> 00:40:49.644
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.
217
00:40:50.704 --> 00:41:03.844
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.
218
00:41:04.024 --> 00:41:15.204
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.
219
00:41:16.144 --> 00:41:25.124
Uh, and, and if it's not reliable, then a lot of those gains disappear because if I'm gonna ask my PM GPT,
220
00:41:26.524 --> 00:41:39.024
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.
221
00:41:39.124 --> 00:41:49.584
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,
222
00:41:51.004 --> 00:42:00.004
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
223
00:42:00.984 --> 00:42:09.444
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,
224
00:42:10.464 --> 00:42:14.264
uh, that would happen like automatically, right? Yeah.
225
00:42:14.284 --> 00:42:27.264
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.
226
00:42:27.324 --> 00:42:44.444
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?
227
00:42:45.064 --> 00:42:51.184
And it didn't need someone to write docs for every single little thing. Um, equally, an engineer who's joining the team,
228
00:42:52.104 --> 00:42:58.903
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?"
229
00:42:58.934 --> 00:43:11.684
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,
230
00:43:12.904 --> 00:43:21.264
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.
231
00:43:21.564 --> 00:43:28.684
Um, what have been like the main challenges that you've, you've faced during this process with implementing your assistance?
232
00:43:28.724 --> 00:43:39.124
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,
233
00:43:40.824 --> 00:43:54.344
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.
234
00:43:55.444 --> 00:44:10.124
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?
235
00:44:10.284 --> 00:44:16.484
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.
236
00:44:17.164 --> 00:44:29.364
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?
237
00:44:29.504 --> 00:44:36.244
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.
238
00:44:36.284 --> 00:44:47.384
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.
239
00:44:47.414 --> 00:44:56.084
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.
240
00:44:56.124 --> 00:45:07.684
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?
241
00:45:07.964 --> 00:45:19.324
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.
242
00:45:19.364 --> 00:45:30.164
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.
243
00:45:30.244 --> 00:45:30.644
Let's go."
244
00:45:31.333 --> 00:45:42.084
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.
245
00:45:43.064 --> 00:45:56.524
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?
246
00:45:57.084 --> 00:46:09.744
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.
247
00:46:09.784 --> 00:46:10.564
I mean, if you- Yeah...
248
00:46:10.604 --> 00:46:22.944
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.
249
00:46:23.164 --> 00:46:28.944
Um, so you need to set expectations, but also look for, look for the quick wins, look for the champions.
250
00:46:28.984 --> 00:46:42.184
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.
251
00:46:43.924 --> 00:46:58.844
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
252
00:47:00.564 --> 00:47:17.604
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,
253
00:47:18.764 --> 00:47:23.804
how do you see this approach scaling as a company grows?
254
00:47:24.554 --> 00:47:36.194
'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,
255
00:47:37.584 --> 00:47:50.684
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?
256
00:47:52.264 --> 00:48:03.664
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.
257
00:48:03.804 --> 00:48:09.574
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,"
258
00:48:10.624 --> 00:48:17.943
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.
259
00:48:18.004 --> 00:48:30.724
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.
260
00:48:31.484 --> 00:48:37.524
Um, but I think if you, if you have that kernel from the start and you, you sort of,
261
00:48:38.444 --> 00:48:47.844
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.
262
00:48:48.104 --> 00:48:58.524
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.
263
00:48:58.624 --> 00:49:05.324
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."
264
00:49:06.084 --> 00:49:27.474
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.
265
00:49:27.514 --> 00:49:39.084
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.
266
00:49:39.834 --> 00:49:44.234
Um, so it's, it's just constant effort. It's being very clear. I think writing things down. Um,
267
00:49:45.154 --> 00:49:56.574
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.
268
00:49:57.354 --> 00:50:05.013
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.
269
00:50:05.734 --> 00:50:16.054
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.
270
00:50:16.874 --> 00:50:20.034
Um, so you know, you're just sort of copying and pasting across those.
271
00:50:20.254 --> 00:50:37.774
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."
272
00:50:38.014 --> 00:50:49.184
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.
273
00:50:50.374 --> 00:51:05.254
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.
274
00:51:05.294 --> 00:51:13.434
What are the first things they should start doing? I mean, I think, um, obviously it depends as well who you are.
275
00:51:13.574 --> 00:51:22.044
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...
276
00:51:22.054 --> 00:51:37.564
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,
277
00:51:38.514 --> 00:51:43.554
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."
278
00:51:44.194 --> 00:51:52.653
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.
279
00:51:52.834 --> 00:52:01.714
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.
280
00:52:01.834 --> 00:52:14.054
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,
281
00:52:15.014 --> 00:52:25.394
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.
282
00:52:25.494 --> 00:52:34.734
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?
283
00:52:34.794 --> 00:52:40.114
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.
284
00:52:40.214 --> 00:52:48.414
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.
285
00:52:48.514 --> 00:52:59.534
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.
286
00:53:00.914 --> 00:53:12.354
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.
287
00:53:12.934 --> 00:53:29.054
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.
288
00:53:30.134 --> 00:53:38.474
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,
289
00:53:39.514 --> 00:53:49.354
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.
290
00:53:49.594 --> 00:53:58.744
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.
291
00:53:58.794 --> 00:54:09.233
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.
292
00:54:09.274 --> 00:54:14.674
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.
293
00:54:14.754 --> 00:54:29.114
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,
294
00:54:30.034 --> 00:54:45.694
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.
295
00:54:45.954 --> 00:54:58.634
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.
296
00:54:58.674 --> 00:55:06.034
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.
297
00:55:06.494 --> 00:55:14.064
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
298
00:55:15.274 --> 00:55:24.244
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?
299
00:55:24.514 --> 00:55:37.894
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.
300
00:55:38.094 --> 00:55:51.394
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.
301
00:55:51.534 --> 00:56:03.454
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.
302
00:56:04.094 --> 00:56:18.834
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.
303
00:56:20.034 --> 00:56:32.184
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.