Software Engineers As Problem Shapers (Not Ticket Tackers) ၏ စာသားမှတ်တမ်းအပြည့်အစုံ

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.