James Trunk: From Agile to Shape Up - Lessons Learned in Product Development

Matt

My name's Matt, and I will be talking with James Trunk about how to foster a strong feedback culture and effectively manage integrated product and engineering. The first thing, and what caught my attention during our last conversation when we are preparing for today's, interview, which topics we should discuss, what caught my attention was the 5%, 30% rule. Yeah. We can operate on that. That's a really interesting concept.

James Trunk

Yeah. So, Griffin, where I work, we're a startup bank in the UK. We have this idea about feedback and creating a feedback culture and this 5%, 30% rule or guide is connected with that. So the basic idea is when you're working on something, you should ask people for feedback when you hit 5% complete and then again at 30% complete and then normally later. But the reason why we put the focus on the 5% and the 30% is to remind people getting early feedback is really important. And the reason there's a couple of reasons why I think it's so important. The first one is when you're giving feedback to someone on their work, it's easier to give it if they're just sharing so let's say someone's doing a presentation.

At 5%, they've literally just written a few bullet points. That's all they've done. You know, they've spent 10, 15 minutes on it maybe, and they're just starting to get a structure of their idea. You share that with someone and they see it's just so easy to give feedback on that. Whereas imagine the opposite where I've finished a presentation, now I'm sharing it with you, and it's got pictures and movies and slides and stuff, and then you've gotta give feedback and it feels, oh, but that wasn't the direction I wanted this to go, but now I've got and you're gonna have to rework it. So it's really nice from both a giving and receiving perspective psychologically. It creates that safety, but it also just encourages a feedback culture.

It encourages us that that's what we do here. We we work in the open. We're transparent with how we work. We wanna include people's ideas. We want to be better than we can be by ourselves. So there's so much value about opening up for feedback early and often. I think it's it's really, really important, and a sort of analogy to sort of help drive the point home is if you were trying to get somewhere in a car, you're driving, you wouldn't drive with your eyes closed and just sort of hope that you end up at the right place right.

You would have your eyes wide open. You'd be getting all the feedback you can get to to make sure you're making the right turns. And I think that's true for any kind of creative, knowledge work. The the more you can have your eyes open and get feedback, the more likely you are to end up where you want to end up. Does that make sense?

Matt

Yeah. A lot.

I it I think it reminds me making things in, as a waterfall. Like, that you mean a product in a waterfall way versus agile. Right? But the exact what you're saying is even more simpler. I think, like, everybody could remember it, and you could apply to kind of each department. So and I encourage this collaborative way of, doing stuff.

James Trunk

So Yep. And I wanna give a shout out to, Maria Campbell, who was our VP of of people, and it was her that I got this idea from, or she introduced it into the company. So this is not my idea, it's just an idea that I'm sharing and I really like, and

Matt

I think it's really helped to shape our feedback culture. Absolutely love it, Ally. And, recently, we talk about the product delivery, and I'm always trying to look for a secret sauce, like, how different companies approaching the product delivery. And you had a few, interesting bits that are different than versus other companies. Maybe you could talk a bit more about this product delivery.

James Trunk

Yeah. I I don't wanna oversell oversell as a secret sauce, for people, but I can definitely tell you what we do, why we do it, and then maybe people can grab whatever out of that that they find interesting or relevant to them. So I've been at Griffin for more than 3 years now and not long after I joined, we switched from doing pretty standard agile, we only had one development team at the time, into doing something called Shape Up, which comes out of Basecamp, And there's a book about it online, and I can't I don't wanna teach everyone what shape up is now. It's too much to go into, but maybe what I will try and do is just isolate the 2 core ideas from shape up. What what attracted us to it? Why we wanted to switch from sort of more standard agile shape up. And the first idea is it elevates and sort of separates the idea of shaping, which is where the name comes from, shaping work alongside building it.

So it's so it's like a dual track process in that way. And I don't know about you if you've ever tried scrum or more traditional sort of capital a agile. It tends to be more sequential. You know, the team works on a a sprint for 2 weeks, and then everyone panics in the sprint planning and is trying to do all of the shaping and all all of the thinking in, like, one day or half a day, and then you sprint again. And that that balance always felt a bit off to me. So just this idea of sort of elevating that that planning, thinking, designing, shaping work to it is really interesting and really powerful and it has paid so many dividends. So that that's the first really good idea.

And the second one is how it encourages you to split up the work into these different slices. In in shape up lingo, they call them scopes, but I think it's easier to think of it as a slice through the feature that you're building. And going back to our point about fast feedback, it's connected to that because instead of imagine building a new feature and everyone's working on their own thing and it's not end to end slice and you kind of bring it all together right at the last minute and then you find loads of problems, and finally you have something that works end to end, and then you can share it with people and get feedback. That's way too late. Right? If we're talking about 5%, that that's way too late. So this slice idea is really good because it gives you a chance to focus on, okay, what's the thinnest possible slice of this feature that we can build so we can show it to stakeholders, show it to customers and get the, is this what you meant?

And that's absolutely huge. So both of those two ideas we've kept, but we have developed it. Now, we don't really have a good name for it, I would just call it name Griss Inshaper because we've been iterating on it as you do. We do something we call bet prospectives. Every time we deliver a bet, which is what we call product or projects, everyone in the team that works on it sort of looks back at it's a classic retrospective, the idea is what can we do better? What can we learn? What can we do differently? And we've done loads of those obviously over 3 years, and each time we come up with little tweaks and sometimes we'll experiment in one team and it sticks because it's helping and then it spreads to the other teams, and now we've gotten to a point that instead of just shape, build, and then cool down, those are the 3 sort of phases in traditional shape up.

We've added a few more. There's a few more hats that we put on as we're building, and the first one is discover. So before we shape, we discover what should we shape, and the reason we do that is because shaping is quite an expensive part of the process. You're trying to understand what's involved in the problem here, really describe the problem as clearly as possible, really capture all the requirements. It's a way of handing over requirements from product to to engineering at that stage, and coming up with fluffy versions of the you're not it's not a final version but it's like fluffy versions of what potential solutions could look like. That's a lot of work. Engineers are involved, so a lot of people are involved there.

So we we needed an extra step before that figure out and do more sort of customer research. Where should we spend our time doing the shaping? Because that's an investment. So that's an additional step we do, and then we do shape, and then we do another additional step we we call architect, and that's before you start building. And it's for the engineers to put a different hat on, like not dive in and build, but we're gonna go into an explore mode. We're gonna experiment. We're gonna do design and planning and make sure we're being thoughtful about what we build.

You need to be careful there because like you talked about, agile is about iterating. You don't wanna do waterfall. But for us being a bank, we'll maybe talk a bit more about this later, but it's really important that we're very thoughtful each time we do something and that we make sure that the design is gonna stand up and that we're not gonna have to just go back and revisit it straight away. So we do an architect phase, then we build just like in in shape but not really different. Then there's another new phase which we call accept, and that's all about testing what we're building. Test is a huge thing for us building a bank. I'll talk more about it later, but accept is when the requirements that we've captured in the shape phase, we ensure that that's how the system works.

We show it to the stakeholders. We show it customers. We record evidence that that is how the system behaves. So it's like a record. So it's not just the code that describes how the system behaves. We actually have these scenarios that we write as job stories. So instead of user stories, job stories flip it so you care about when x happens, I want to do y so that I can achieve zed.

So that's the basic sort of formulation of a good job story, and that really helps us capture, okay, when is the end of the day, we need to do this kind of calculation for our chart of the capital, whatever it is that we're we're working on. So that adds a lot of value in that accept phase, and then instead of calling it cool down, we call it stabilize. And the idea it's similar to cooldown, but the idea there is that the team is focusing on improving what they've just built and improving the underlying tooling, sharpening the tooling so that next time we go around the loop, we're in an even stronger place than we were last time. Because I think a lot of companies struggle the technical debt just tends to build over time and if you create space for tackling that you don't solve it I'm not saying we have no technical debt but you you give yourself a chance to chunk away a little bit at it and come back stronger for the next loop.

Matt

I think it's really important to put, like, a context because you are telling a lot of stuff about experimenting, starting small. Yeah. Like, iterating a lot, like, starting with a scratch. Right? But you work in a highly regulated industry. So I I I would spoke spoke I had, like, a few interviews and talks with, people from, like, classical banking or, like, from neobanks, And I I haven't heard so many, like, I would say regarding the process, such a, such a I haven't heard so much about such a theoretic experimenting, like, process.

And you create, like, a at the Griffin, you create the bank as a service platform. Banking as

James Trunk

a service. That's right. So our customers often text to build their financial products on top of our banking platform, and then they have their own customers.

Matt

Yeah. So we are, like, a good proof, regarding the process that you can still experiment, still start small, and try the things, and it doesn't have to be, like, perfect from the day 1. So it's, like I think it's, like, really modern and pragmatic approach, but not obvious in the industry, so this is what I've seen before. So and another interesting concept that we discussed, that, you follow as a as a person for life, and you name it like a correct contrarian. And I haven't heard it before, and I think not many people have familiar with that. Yeah. I I really like this idea.

It it's not my idea. It's it's a way that

James Trunk

I've been trying to live for a while, but I didn't really have a phrase to put on how I was thinking, and I think it was, Mark Manson who has a YouTube channel about life advice and coaching, basically. I think I got it from him at the actual correct contrarian sort of formulation. He may have got it from somewhere else himself, but the basic idea with it is if you want to be world class at something, just doing what everyone else is doing is an unlikely avenue to get there. I mean to outperform people, you can't do the same behaviors that they're doing. You can't use the same tools. You can't use the same processes. So correct contrarian is about analyzing, are there any low hanging fruits that we can think about from a fundamentally different perspective where we tackle it from first principles?

So it's almost like an anti copy paste philosophy. If you like that, I don't know if you've noticed this in our industry, but it seems kind of cargo cult y that somebody uses a certain framework and everyone jumps onto it. Somebody starts using Kubernetes. Everybody somebody starts doing microservices. Every we're a little bit like that. We just kind of follow the herd, And I understand why from a sort of human psychology perspective, it feels safe to be in a group. It feels safe to not sticking your neck out than doing something different. And if your goal is to just be, you know, in the pack and average, I think that's a good strategy because it's unlikely to be terrible, but it's also unlikely to differentiate you and if you're in a startup, I don't think you've ever read Paul Graham, he writes a lot of fantastic essays, but he talks about how he thinks technology choice can be this kind of change where he's contrarian about arguing for why Lisp was so powerful when he was creating one of his companies.

And it's that kind of thinking that this idea captures. So how do you how do you spot cracks that people are falling into, either as an organization or as an as an individual, and avoid those? And how do you spot tools, technologies that are gonna push you, that are gonna give you a force multiplier or a yeah. The idea isn't just to lift you 5%, it's to lift you significantly. I can give you a couple of examples if if that would be useful. So from a personal perspective, I'm not on social media, and I never have been. And in the beginning, I think if you asked me it would have been, well, I'm worried about the privacy, you know, as a software engineering background, I understood that it was a bit scary to put my whole life on the Internet.

But as time has gone on that the reason for not being on there has changed because it feels like the research is starting to come in really strong about how damaging it can be to mental health. And not only that, how much time people spend on it. So if you're trying to do things differently than other people, that's an example of where, I can be spending time with my kids or reading a book or doing something while other people are doomscrolling. I'm not doing that. Kind of a basic example, but I think ShapeHub versus Agile is a good one from a sort of organizational level. It's not just everyone else does scrums, so we're gonna do scrum. It's why do we want the process to look like it is?

What are the foundational reasons behind it, and how can we optimize towards what we're aiming at together? Does that make sense, Matt?

Matt

Yeah. It James a lot of sense. And, like, when you mentioned this, current contrarian approach, it reminds me, like, especially for the founders who are starting to start up outside of their niche of, where where they specialize. Right? I think they are kind of, like, unconscious, contrarians because they are not familiar with all the, you know, borders and all the things that you cannot do or you are not able to do. Right? And they do things differently.

And very often, like, they they fail, but in most of the cases, they disrupt very often the the industry. So, I mean, I, absolutely, agree with that what you said, and I think it absolutely makes sense.

James Trunk

And there is a higher risk approach to it. Right? Like you're saying I mean, you mentioned startups.

It's a good example. Most startups don't succeed even if they're trying to be disruptive, even if they're trying to do things differently. So this isn't a safe option. There's a reason why people say you don't get fired for choosing IBM. Right? So it's not always the right thing to come in and be gone. And like, no, we're gonna ignore everybody else, all the common wisdom, and do everything completely differently.

That that can be too risky. So you definitely have to balance it and be nuanced and pick the right levers for the right situations. But when you do, it's incredibly powerful because it at least gives you a chance to hit that sort of world class level.

Matt

I mean, another question that I wanted to ask you, is, what are the biggest pain points or maybe challenges of your current role that nobody is widely mentioning or not seeing from the outside?

James Trunk

Yes. So I'm I'm VP. I don't think we've said what my role is, but I'm VP of engineering at Griffin. So essentially leading the people and process part, if you describe it very shortly, of of the engineering team. And it's a really good question. We've been growing a lot recently or throughout my whole journey there, you know, from one team. We're up to 9 product engineering teams now, almost 40 engineers.

And so scale is definitely part of what we've been doing, but connected with that is just the amount of information that everybody, including me, has the process. And because I'm trying to understand what's going on across all of those teams, it's it almost feels like a fire hose of information sort of coming at me every day. And I don't know how other people with similar roles deal with it, what their tools and techniques are, but I I can share a couple of the ones that I'd use and how I think about it. And I use writing as my main sort of tool to defend against that. I don't have the world's best memory. And by writing down what we're talking about, the decisions that we made, what our plan is, and and reflecting as well on how I'm feeling about things, what the challenges are, that enables me to to process all of that information and hopefully not drop too many balls because I think when you have a leadership role, it's really important to build trust by if you say you do something, you're going to do something, you actually try and do it, so it adds an overhead to my day because that's a lot of writing. That's a lot of information to process.

But unless you have a photographic memory, I I'm not sure how other people do it. And in the same way, I I depend on my calendar to know what's happening and which meetings I'm going to. I depend on my notes to understand, okay, what do I actually have to do? My notes sort of turn into to dos, if you like. I don't know how maybe lots of other people are talking about this. I know productivity and time management and note taking. They're starting to take off maybe in the collective consciousness a bit, but I still feel like maybe maybe I'm missing a Trunk, maybe that isn't the right way to do it, but that's what's been working for me and enabling me to sort of feel on top of things.

Matt

I'd say there are no silver bullets. And you mentioned, Griffin and, Griffin and Engineering, and I'm just wondering how the engineering approach you mentioned a couple things already, but how the engineering approach to engineering is different in Griffin versus your pre previous organizations.

James Trunk

Yeah. The first thing that jumps to mind is kind of already what we talked about a bit, this this approach with ShapeHub. But maybe the the thing I could zoom in on, the sort of key difference maybe, is and not just ShapeHub, but maybe the grissing version of ShapeHub is so it creates such a symbiotic relationship between product and engineering that it sort of it gets rid of the division between us in a strange way. So I think in some organizations, and even ones I've been part of or led before, it can feel a bit deme en us where product is, you know, asking for things and then engineering delivers things. But when you break down the process in the way that we've done where, okay, products are driving the discovery, they're driving the shaping, but they're pulling in engineering to support, and then we kinda pass the baton over to engineering for the the architecting and building, but products are there to support. So there's no there's basically no part of the process where it's just one or the other. It's always us together, and it just creates a different feeling, a different unity, a different togetherness, and a different level of understanding of the of the domain and the problems that we're solving.

It puts a heavy load on the PMs, on on the product managers because they are having to predict the future and be thinking way ahead. They're having to do really deep planning, thinking, and writing about what's coming next. They're having to support what we're already delivering at the same time, testing things that we've just built, you know, and dealing with stakeholders and different requests coming from that's a really intense role that we've created because of how the process is set up. But each team, it doesn't just have a product manager, they also have an engineering manager and it's kind of their joint leadership, so we have product engineering teams. And the engineering manager is is sort of the yin to the yang or vice versa, where they're balancing on the quality, on the testing, on the engineering side, on caring for the growth and development of all of the engineers, and it I think there's something about that symbiosis that works really, really well for us and it does put pressure on both, and I want to shout out for to all of our PMs and and engineering managers. They really are world class. But I think if you can get really strong people in that, get strong engineers into the teams, the quality and the speed that you can deliver when you're sort of in sync with each other like that is like nothing else.

Matt

I I like this approach, so it reminds me that in many organization, there is a problem. Right? When you have, 2 kind of departments, living in a different silos. Right? So they kind of then collaborate together. It reminds me, like, each company, marketing versus sales, product versus engineering. Right? So even now you have those roles of a CTPO, right, that disconnecting kind of 2 words, and they want to bring the teams together to work in a synergetic way.

So, yes, I I think it's a good approach, a good approach. And another concept that, that we discussed, we discussed a lot of different concepts, which which caught my attention, principles over process. What does it mean and how does it translate?

James Trunk

Mhmm. So that's I've talked before on on other podcasts. I think I've even written a blog post about if people are interested to read about decision principles and the power of condensing an idea, a value, into a principle that helps you make better decisions, and this is one that I've updated this year. So I've added this idea of, principles over process. And where it comes from is that I was a software engineer for a long time before sort of going on to the leadership Trunk. And I think my brain is naturally drawn towards systems and processes. You know, understanding them, taking them apart, adding to them, fixing them, improving them.

There's something about the reward center of my brain that it's optimization driven. I like making things better for some reason. It just makes me feel good. And so what that means is I'm drawn to process. But and process isn't bad. And especially as you scale an organization, you tend to need a bit more process. But one of the the insights that I had is if you can get people aligned on principles rather than getting too hung on the the exact way, the exact how, you focus a bit more on the why, alignment just seems to come more naturally and the how becomes less important.

Because if we can agree on what are we aiming for here, what's our goal, what are some guidelines that enable us to make better decisions together, then you can kind of step back and the right you know, you're all headed with the same, direction better. Whereas if you focus on the how but people don't understand the why, there's such a risk that as things start to change in the process, we're not really conscious about how and why we're changing it. Whereas if we're all aligned on that the why, it doesn't almost doesn't matter how you achieve that why, if that makes sense. And I want to give a shout out to our current chief people officer, Jenna Baker, because he really inspired this change in my decision principles because she's an absolute master at putting the why first and getting people aligned on the underlying principles, and I just see the impact that makes on the quality of what comes out of it and how the team can then align and how you can give people more autonomy to figure out how to solve it themselves. You know, it's the difference between, boom, here's the book, follow this step by step to here are a few guides, you know, be creative and come up with something that works for you.

Does that make sense?

Matt

Yeah. Yeah. That's I answered that question really well. And, you work for quite a while in, in the Fintech, but you worked in a different industries. I'm trying to see if, do you see any, like, major differences in building the products in the Fintech industry versus your other organizations

James Trunk

or other experiences? Yeah, that's a good question, and I think it's a pretty strong yes answer. My gut feeling is, so when you're a bank, you're heavily regulated. You mentioned it briefly before, but it's a heavily regulated industry, and rightly so, and it's really important with consumer duty or caring for your customers and for their money. Banks are, they're a backbone of a country's financial system essentially, so them being stable is incredibly important. So it makes sense that you have to jump through way more hoops in terms of quality and control than a standard SaaS or, you know, startup would have to do, but it it does change the balance a little bit about how you have to think about building things and understanding what you've built and testing what you've built. We touched on it a little bit before but maybe there's a phrase that could sort of sum this up for the listeners quite clearly.

It's a lot of startups have a mantra of let's move fast and break things. In a bank, that doesn't really work.

So if we have

Matt

we don't have the mantra, but

James Trunk

if we had a mantra, it would be more like let's move as fast as we can whilst trying not to break anything at all, if that makes sense. And it just it forces you to focus more on quality. And for us, that comes out a lot in the technologies that we choose. So we choose things that are as simple and as exposed as possible and don't hide away a load of complexity that we are not in control of, but also the testing part that we for us, automated testing is incredibly important for building confidence that we understand what we've built, that it behaves the way that we expect, that it scales to the level that it needs to. We do lots of different types of testing, including types of testing that aren't that common in the industry, for example, as well as unit or sort of example based testing. Every everybody does that, or hopefully they should be doing that. But we also do something called property based testing or generative testing, where you're sort of firing a machine gun of random data of a particular shape of your code to discover corner cases that you'll probably miss if you're just having to come up with those examples yourself.

We also do contract based testing, so parts of our system that have clear APIs or interfaces. You can set a contract against that API and then you can basically ignore that part of the system and give, canned responses or mocked responses so that you can isolate and test other parts in extreme detail without being dependent on third party payment rails or things that can be slow or difficult to test. And chaos testing, I guess that's becoming more and more common. But, you know, you turn off bits of your infrastructure randomly at different sizes of well, you could start with Chaos Monkey and Chaos Gorilla and Chaos Kong when you just shut down entire, you know, Amazon regions, etcetera. And all of that helps to build confidence, which helps us get to that as fast as we can goal whilst being confident. Because without that sort of safety net, I think it's really easy that you just lose confidence to make changes and that's a really terrible state to be in. So we try and avoid that right from the beginning by building those tests straight away.

And then I talked about the accept phase in in shape up, you know, the one of the phases we added. So a big part of our shape phase is to capture these those job stories, the requirements, and then we test those. So again, it's about building confidence in the behavior of the system and double checking it behaves how we expect. So, yeah, move slightly slower and try not to break anything.

Matt

That's the big difference. But the scales engineering, it's an interesting concept. I heard about it, like, just recently during one of the talks. I think it's coming from the Netflix. They figured out the James engineering and those monkeys. Right? Yeah.

James Trunk

That could well be the origin. Yeah. I haven't looked into exactly which company was first, but it sounds like the kind of thing Netflix will come up with you. Right?

Matt

Yeah. But it's so, it's so, like, simple. That's very simple. But, it's, it's brilliant to kind of, like, have to find the holes in the system. Right? Especially, when it needs to be so stable, you need to put a lot of emphasis on, on, on testing, automated tests, and various different kind of scenarios here. And so and, 2024, like, each of us, we have our challenges and pain points, and we learn from them.

And I'm wondering, James, in in your case, what what are your challenges and pain points? What do you type in Google? Right now. That is for Chat g v p.

James Trunk

Chat g v p. What what do I get hallucinated answers about? That's really interesting. The first idea that comes to mind is is the scale challenge. So as we're growing, I may be specifically connected to that culture is a really important part of Grifton, and we're very intentional about culture and what that means to us and the kind of values that we share with each other and that we hire for. But, obviously, if you're a company with just a small group of engineers and 30 people, it's different when you get to a 100. It's gonna be different for us when we get to 200, when we get to 400.

So what I've been thinking about is how do we grow in a way that maintains all the important parts of the culture? We can't keep everything that we do because something's not scale, but how do we grow in a way where it still feels like Gryphon, where the people who joined us early on still feel like they belong and it's not become a totally different entity. And I think hiring is part of that because matching on values is part of how we hire. It just automatically means that even though we're grown, we're grown with a type of person that has that sort of vector based blind, but it's also how do we stay aligned as we grow, give people the space to innovate and come up with new ideas, but get that balance right. Because if people innovate in a way where it suddenly changes the culture for that whole part of the business in a way that's derogatory to how it feels, that's not gonna be great, but you also don't wanna clamp down and say, no, you you can only do this and that. And maybe going back to the principles over process, I think if we can apply that thinking across the organization, that could be one way of tackling it, that we make sure we're in alignment on those important things.

Matt

And and for yourself, I'm always wondering because we learn, as as I mentioned, from the challenges and pain points you already tackled a bit. But I'm just wondering what was the hardest thing in your career and you have ever done, and what what are your lessons there out of it?

James Trunk

I I did this other project I'm really proud of when I was CTO at a recruitment company where we open sourced the architecture that we came up with. And, we did it on our own time at all of the sort of open source work. There was like an additional lift on top of our day job, if you like, but I and that was difficult to do, but it was such a pleasure to work with that team and to come up with an idea that we thought was world class and pushing the envelope different than other people were doing and sort of going against the microservice, sort of mindset that was very prevalent back then. It's called Polylyph if anyone wants to check it out, but that that's a piece of work that I'm really, really proud of being involved in and seeing it starting to grow now in the in the Closure community and a little bit in the Python community and some other languages potentially, it's a really nice feeling that, ah, it wasn't just us that thought that was a good idea. Other people are picking up on why that's an interesting way to think about building software. So I'd say that one.

Matt

Do do you checks from time to time on GitHub, the stars Yeah.

James Trunk

Repository? For sure. Not that often. And it's my friend Joakim, he's he maintains this. He's I don't spend time maintaining it anymore. He does. But I'm sure he's checking the stars and seeing how it's growing.

Matt

Uh-huh. Yeah. I I I do the same.

Like, we release, like, couple of open source products, but, each couple of months, I really like to go and check. And I'm just sometimes, amazed that the people are using it. So, like, from all around the world, sometimes they are writing some messages that they really like they implemented on the product. So it's, it's really rewarding, I would say.

James Trunk

So I totally agree. For me, a real highlight was I review a lot of CVs.

It'd be part of my role as hiring. So I don't know how many I review in a year, but it's, it's a lot. And, I remember the first time I got a CV and they had poly lit. There's a technology they'd used and, you know, they'd used it in a bank or they'd used it or they'd used it in Australia. And I was thinking, wow, you can have an idea and it has that, you know, guess out into the world. It's, it's

Matt

a very nice feeling. Last 10 points of the very beginning of the,

James Trunk

Yeah. Either that or what they've done is they'd look me up online and then, oh, James created Polyvib. I'm gonna pretend that I've used it and getting these good books. Okay.

Matt

Okay. And the last question that I have that I asked all of my, guests, I'm wondering if you could recommend any books, podcasts, maybe conferences that have been particularly helpful to you, as a leader, as a tech

James Trunk

leader. Yeah. Good question. I'm not much of a podcast person, these days, but I do I do tend to, watch certain types of channels on YouTube. So I can recommend a couple of my favorite creators there. I tend to maybe connect it to our fire hose of information and time management and productivity and being effective. I tend to watch quite a lot in that field, about note taking or personal knowledge management or, yeah, those kind of related topics.

The one that jumps to mind first is is a Kiwi or someone from New Zealand called Sam Matla, m a t l a, and he has, I guess it's productivity focused or building strong habits focused channel. And I I take, notes from, content that I consume. So if I read a book, I don't just read the book. I take notes and try and extract insights and connect insights together. And I would I think he's, at least from a video content creator perspective, the one I've taken the most notes on, so that's some kind of a an indicator of the amount and the quality. And then one that's probably more familiar with most people because he already has loads of subscribers, but have you heard of Ali Abdaal? He has a kind of entrepreneurship, a little bit productivity, a little bit psychology focused channel, but very high quality content.

I it it's quite often you'll have a video that I want to take notes on.

Matt

Yeah. Awesome. The the second guy I know, the first one I need to check, for the for the recommendation. So so, James, that that that all what I have prepared for today, but I think we have a lot of, so called meat, I call it meat, where from the conversation, that, a lot of new years will appreciate. So I think those for me, the the concept with the 5%, 30%,

James Trunk

and the

Matt

correct contrarian, it's, it's it's really something that resonates with me personally. So

James Trunk

so so

Matt

I really, I mean, really enjoy it. So thank you so much for today. Thank you for so many insights.

James Trunk

You're very welcome. It was an absolute pleasure talking with you. Trunk you. Follow Matt on LinkedIn and subscribe to the Better Tech Leadership newsletter.

‍