Jaime Lopez on Building Great Engineering Teams

Steve Westgarth: 0:00

My name is Steve Westgarth, and this is the engineering leader so that we can help more leaders just like you find the show, it would massively help if you could take a moment to write a review about the podcast and then post it on Apple podcasts, Spotify, or Google podcast. Letting other engineering leaders know about the show is so important, and the only way that the community will grow and which other leaders just like you. Also, please don't forget to hit the subscribe button, so the new episodes download automatically onto your device. Today on the engineering leader, I'm joined by Jaime Lopez, a developer relations manager working with Jack Henry and Associates, where he focuses on developing open banking API's. He's also the co host of the more than just code podcast. Hi, ma is an accomplished software engineer widely recognised in the community as dev with the hair. Jaime, it's a pleasure to have you on the engineering leader today. Before we kick off, really important question for you. And could you just confirm that you also write bad code?

Jaime Lopez Jr: 1:15

Yes, I definitely do write bad code. The the point for me is to see how little code I can write because every every line of code becomes a potential liability and sort of my my way of thinking about it.

Steve Westgarth: 1:31

Yeah, no, absolutely. I think it's, you know, something, everybody does write bad code at times, right. But I guess it's how you go back to that bad code and how you maintain it going into the future, which is really interesting. The other thing I want to cover off with you, before we really get into things is devil with the hair, why the hair? What's that all about?

Jaime Lopez Jr: 1:51

So, gosh, how long has it been? It probably was like 2008 2009, I could probably go look through my photo library history and see when does this hairstyle appear. But I started doing something a little bit different with my hair. And I went to a conference. Now the background for the conference is it was when I was still doing consulting in aerospace, previously working many years at Boeing, and then went to work at one of their consulting vendors, purchased surface books, and encountered some people who I had known before, and they brought their group of colleagues to our booth, and chit chatted and etc. Later on, had an interview with that company, because I knew that people as a bio might be great and brilliant to work with them. And they had described to me how the way that they had, you know, said who was coming for the interview was like, Oh, do you remember that guy with the hair at the conference, and it seemed like that instantly made the connection for them. And so I started thinking about turning this into the brand, as I like to say, so I'm definitely the hair just about everywhere, and you know, GitHub, Twitter, etc, etc. And it's worked out pretty well. It's, it's something that like, you know, I'll I'll see people at conferences, back when we have those in person, although definitely remember me, you know, even several years later, and some people because, you know, my Twitter profile, and my GitHub profile is actually a, an illustration and Avatar created by my significant other, and people have talked to me and conference, it'd be like, your dev with a hair, even though they've literally never seen my face, because it's quite in line with the brand. So it works out for me is sort of the short of it.

Steve Westgarth: 3:40

And you're right. I mean, it does work out for you. I mean, I always I've always known you as Deaf with the hair, and I mean, you're instantly recognisable. How important do you think it is to build a personal brand?

Jaime Lopez Jr: 3:52

I think it's definitely helpful, right? Like, when I've, you know, in my career, been trying to help mentor people who are earlier in their career, people who have made career changes into software, and they're usually coming down into questions like, how do I, how do I get the job? Right? I say, Well, there's a couple of different things you need to do. Like from a hiring manager standpoint, you definitely need to find ways to reduce the risk, right? This is why everybody loves having, you know, referrals from employees, because there is some sort of vetting that has gone on, like, at least you're bringing in somebody that hypothetically you would approve of working with. So that reduces risk for a manager versus the 1000s. Or at least hundreds of resumes that might be getting for a job. And then there's other things I talked about, like you know, it's definitely helpful to have, you know, open source contributions, if possible, because people get to actually see your code and they don't really have to test you as much Canvas person code. A less sort of common thing. It's not something I would say like everybody go find your brand thing is just sticking out in their mind. Right and When you've got hair like mine, maybe that has closed some doors and some opportunities for me, like, you know, I probably couldn't go work at a place that had a suit and tie and everything is three piece suit, Wall Street sort of thing. But thankfully, we're blessed for technology that people largely don't care and my hair is increasingly less wild as people have, you know, the side shave with the long you know, pink hair, or they've got, you know, a huge bit of, of Mohawk or some other things like tattoos, etc, it's become much more inclusive. So in a way, you, you could almost build a brand by not having one in many ways. But I do think it's, it's pretty solid as a way to just stick out. I'm not saying that people should, you know, try to be inauthentic, I think people can tell if it's, you know, just the mask that you're putting on. But if there's something about you that you're really into, you know, go have at it, if you're the person who wears fedoras, a cowboy hats or baseball caps. Cool, by all means that that could be your brand, right? If you're somebody who you know, loves dressing up. Sure, by all means, be the person in the bow tie, be the person in the, you know, the ball gown, whatever, really, you know, works with it. Certainly I've known people who've had pets, pretty notable, you know, dog and cat owners, sometimes they show up, you know, at conferences and stuff. I'm like, Yeah, I can kind of see why you turned that into your brand that, you know, these pugs, or these beagles, or this Russian Blue Cat became sort of a thing for you. So yeah, it's something

Steve Westgarth: 6:43

I'm finding more and more particularly as I go on to my career, the value of network and actually been recognised by people in the community, the amount of times that I'll put a tweet out or a LinkedIn post out and say, hey, you know, I need some help with something, or do you know, anybody you can, or you have you come across somebody with this particular skill set. And I always get people kind of coming back to me, I remember actually coming into I started new job at the start of the year, within GSK. And we were looking for some contract iOS developers. And, you know, historically, we've always been about news recruitment companies that get very expensive, and all of those sorts of things. And I just put a tweet out when, you know, hey, I'm looking for a couple of 100 iOS developers. And within a few hours, I had your three or four different interviews set up with people, you're just off the back of the network that I built, and people who recognise my name, or were able to introduce me. So it just really kind of, for me shows that the real power of kind of getting yourself out there into the community, and building yourself and kind of becoming recognised. I don't know if you found some of the things.

Jaime Lopez Jr: 7:43

Yeah, it again, it helps, right. So people may or may not remember the name, Jaime Lopez, it may not be meaningful to you, if you are sifting through tonnes of resumes, I mean, it'd be meaningful to you, if somebody even just has a conversation with you of like, hey, you know, I know this person might be interesting. But when you have that visual that goes along with it, that you know, has seared itself into your brain of the crazy person with the wild hair, or the conference, or the profile photo, or apparently now, you know, this very video version of the podcast on YouTube. It helps, right, it gives us a little bit of an edge, it's not going to get you the job necessarily. It's not like oh, I could just completely not know what I'm doing and be incompetent and rubbish. Now, you still have to put in the work, you still have to have the skills. But there's a lot of other people out there in a very competitive world who put in the work and have the skills and getting just a little bit of an edge, I think is helpful. I think, for example, the more than just code podcast has gotten me probably two or three jobs. Now I'd have to look at my resume to see, you know, specifically which ones but I've had hiring managers a while we, you know, took a listen and a couple episodes and really liked the way you think about this. And that's why we were interested in interviewing you and probably why they ended up hiring me.

Steve Westgarth: 9:07

So I guess in your current role, you do get to do some hiring I guess you act as a hiring manager in different circumstances. When when you get a bunch of CVS coming across your desk for a role. What do you look for? How do you decide who was worth taken for an interview?

Jaime Lopez Jr: 9:22

Well, that's an interesting one, as a hiring manager owning guns that in in one cycle. So I currently have two direct reports. One was an internal transfer, and another was net new hire from outside the company. And it was sort of challenging going through. We were using Stack Overflow or using hiring services and etc. So you you kind of end up having to do really quickly figure out is this person even in the right ballpark? Because I certainly got a lot of resumes a lot of LinkedIn profiles that came across my desk. because that were, you know, I mean, kudos to you for trying, but like, you're not even a developer, I gotta need somebody who has development skills. And so trying to filter things out was was a challenge that I'd seen from the other side of the table as an interviewee, or a candidate trying to get people to, to look at my resume, and it was pretty eye opening scene from the other side, why people will use automated tools to sift through the resume like they should, if we're looking for Swift and Objective C, by golly, it's your job somewhere in the resume as a key word, otherwise, we'll just carve it out. Because otherwise you have this huge mountain of things to look at. And although I started off the conversation, saying that, you know, it's good to have things like open source code, it's good to have things like, you know, YouTube videos, blogs, podcast stuff, that's really only as a hiring manager has narrowed it down to a reasonable set of candidates that they're going to take a deeper look at. I think no matter what, you're always going to have the get through the first filter, gate, sort of thing of automated tools, or at least a human being very quickly scanning in 30 seconds or less and deciding, in many ways your future of your career. Right. It's, it's one of those things where people might want to take a look at Job scan.io, or something that does the, you know, they do the analysis of your of your resume and try to figure out if it'll match a job that you're, I assume you link a job and, you know, does machine learning tech magic to figure out with this candidate's resume be likely to be picked up by, you know, the Human Resources filter, or the manager filter?

Steve Westgarth: 11:45

It's a massive challenge. I mean, you know, I think, thinking of my own Well, I mean, we see your hundreds of people that we interview for roles, and I think you're especially in the current climate, I mean, the the tech sector is so hot at the moment, you know, you can, you've only got a sneeze and you're talking to a recruiter about you know, about your the next greatest job or the next company, you might want to work for. And I actually think it's really difficult from both sides to make sure that your as a candidate, you're interviewing for a company you really want to work with and actually feel that you're the right fit for that company. But you're also on the company side to make sure that you're finding the right candidate. And I think often companies can feel pressured, because there are your so few developers out there with the right skill sets, you're to make sure the right people in often a company can feel pressured just to put an offer out there and just to get somebody in quickly. But actually, that time invested in making sure that you've found the other candidate who's willing to do a good job for you. So important, because these are people who are really going to invest in you, and you're going to invest in them and really build a relationship relationship with you for the long term, which is a massive challenge for everybody concerned, I think.

Jaime Lopez Jr: 12:49

Absolutely. And I think this is why it's not really necessarily the purpose of this podcast episode, because it could be an entire episode in and of itself. But I think some of the challenges that you described are a big reason why we end up with diversity and inclusion and equity challenges in this industry, because the the risk is so high that like, it will take you know, serious investment to get this person on boarded up to speed, paying their salary. And if you discover that this candidate just can't code or you know, it's a huge personality issue with them fitting into the team culture or the corporate culture, people are afraid for that. And I think when when managers are afraid about this, they start defaulting to is this person similar to people we already have? Which naturally says that like, okay, look at your team? And what sorts of you know, broad brush, you know, generic attributes might they have there in common? Well, are you accidentally excluding people even just intentionally, I'm not saying, you know, like, bias, that's intentional, I think it's very easy for people to say, Yeah, I don't know if I'll give the benefit of the doubt to this person. And it could not be, you know, related to the actual skills or whatever. It's just something tickling in the back of your brain and like they're dissimilar enough from the current set of people and as you go through rounds and rounds and rounds that you accidentally end up with some of the issues. Like I don't know what it's like in the United Kingdom, but in the USA, you know, all of these Silicon Valley, giant tech companies put out these reports and it's really sad in terms of, you know, choose choose a diversity and inclusion angle, and you will find like, fewer fewer women in technology in general, especially in engineering, especially in upper management. You choose race, you choose sexual orientation, politics, like there's a bazillion different ways in which even if we said okay, there's probably not a lot of moustache twirling villains exclusively trying to keep out particular people. but it doesn't mean that we're necessarily doing a great job as a, as a community of including people and making sure that they feel like they're a big part of the team that they actually do belong in this industry.

Steve Westgarth: 15:13

I think you raise a really good point that it is actually our problem is a community to fix. I was really privileged a few years ago, I went to dub dub DC in San Jose, and Michelle Obama was there and she was talking. And she was giving a talk actually a really inspirational talk about you know, everything was gonna happen in the US at the time and your her role kind of yelled at in the White House and various things. And you were looking at a course you're absolutely packed, dub dub DC auditorium, you're, though there were 1000s of people there. And you could almost count on one hand, the number of women that were in the room, and she was saying, we're in a world where, you know, women and girls outperform men at GCSE or the outperform in college, and then you kind of go through this thing, when he kind of entering the workplace where suddenly, you're from a computer science point of view, and you've got your very few women entering the industry and kind of coming into the world. And that that, for me is, is a problem that we need to solve, because there's a reason why that your women, you aren't really into the industry or aren't applying for those jobs, who aren't kind of you're getting involved in engineering practices. And I'll be honest, I mean, so in my team, you know, we've actually got, you're from a diversity inclusion point of view, you're a really high proportion of of women in my team compared to compared to men, which is really unusual. And actually, you're the woman I'm working with, in my current role as some of the most talented engineers that I've ever worked with. So you know, you can't say you can't try to argue it's about skill, or it's about ability or aptitude. You know, it's absolutely a problem that we, as a tech industry have got to grapple with. And we've got to find a way to solve it.

Jaime Lopez Jr: 16:45

Yeah, and maybe the put a ribbon on this, because W FDC, when it was in person, pre pandemic, I do remember going there. And the line for the restrooms for the men's restroom is so long that you kind of have to leave a session prior to the end of it, if you want to make the beginning of the next session, whereas the women's restroom was like, nobody in line just walk in and out and be done with their business. And I recall, maybe 2018 2019, I wasn't there in person, but I remember people talking about how it was, I mean, it's a really sad feather in the cap, but at least it shows some progress that people were saying, you know, what the lottery system helped improve some of the diversity of attendance in such a way that there actually was a little bit of problem with enough capacity of the women's restroom, which you can literally only have, if you have women in attendance. So we'll see how things come out as things, you know, eventually open up for real life stuff. But you know, we got to do better as an industry.

Steve Westgarth: 17:52

So great to be getting back to in person events to write, you know, it's so good to kind of see conferences coming back and to actually be able to get back out and just start meeting people again, right. Which which actually, in a weird way brings me to to actual job. So your developer relations manager within Jack Henry and Associates. So I mean, I guess that means you get to talk to a lot of developers and you like getting out there and doing a lot of networking and kind of really finding out what what developers need and what developers what developers want. But if you had to sum up your job and say what a developer relations manager does, what do you do?

Jaime Lopez Jr: 18:26

So I split it into two parts. So let's put the manager part aside and talk about what does Developer Relations does, is it's it's not exactly new, per se. But it's new enough that not everybody has had experience with it. So what it boils down to for developer relations is, we are here to help enable developers to build cool stuff on our company's platform. I do that for Jack Henry, pick a developer relations professional from Google for Microsoft, from Twilio stripe, that's what they do from one angle of helping enable developers to build cool stuff. But it's not just outwards, sort of outreach, right? Because that would make it more of a sales or marketing kind of thing, but turns it into into relations is having that inbound set of things where it's, you know, okay, well, interesting that developers are encountering this problem. This part could be a little bit easier to understand could be a little easier to use, and bringing that feedback back into product design and engineering teams so they can improve the product, turns it into more of a two way conversation versus just, you know, outreach, it becomes really, Developer Relations is sitting in the middle as you know, to quote Marian thing bowl who's got sort of the canonical book, the business of developer relations out there. She has a great quote that says to the community I represent The company and to the company, I represent the community. So that's in a nutshell, what Developer Relations does. What a manager, which is my title does is manage a set of developer relations professionals. So, you know, not just doing individual contributor type work, but also trying to figure out, what's the strategy? What tactics are we going to have? How are we going to measure and improve and evolve our team, the software, the way that we approach handling developers?

Steve Westgarth: 20:33

So you're an engineer by background, right. And I guess that in this role, you're pretty hands off from a coding perspective. I mean, that must be a difficult thing to reconcile moving into a role that's so different to what maybe you've done previously.

Jaime Lopez Jr: 20:46

It is interesting. So I'll definitely point out that not everybody who goes into developer relations has an engineering background. People come from technical writing, sometimes they come from product management, they could come from community type backgrounds, it certainly is helpful when or at least I've found it helpful in working with developers, in terms of understanding what the developer experience is like, and the kinds of challenges you're likely to encounter. Because when developers say, hey, this part is rubbish. Can you make it better? I'll have a pretty good sense of like, oh, yeah, I can see why from an outsider's perspective, this would be a challenge. And let me see if I can figure out how to, to make that better, not me personally, because, again, the product design and engineering teams are the ones who build the product. But I can help translate, you know, in in synthesise what many, many developers are talking about as sore points and make that usable as as cohesive feedback, right, versus just a a collection of complaints, which you get turned into without having that background. And in terms of writing code, I still do write code, not as frequently as when I had a software engineering title. That's true. It's not day to day writing code, we communicate a lot of what we're doing in terms of not just, you know, solid documentation, or you know, video or diagrams, but there's also code samples that we provide out there and put it out there on the on the open web on GitHub, that's pretty useful for people to, you know, download the code, login their credentials, try it out, and also gives them some hints as to how to combined, you know, sort of various features of our platform. And I've sort of, I've sort of had to reconsider my opinions of the kinds of things that go into sample code, because a challenge that I run into is having to do a balance between, well, I could write the code this way. And it would be more real, you know, with scare quotes real, like a production engineer would actually build. But that's more complicated to understand, for somebody who's coming in new, right. So have had to lean more towards education as the focus versus, you know, we'll discover all of the error cases no, generally not. Because there's a lot of surrounding code that needs to go for that. And it just starts to clutter, what somebody's trying to read. So now coming back to like, for example, Apple's example code for a very long time for the engineering side, I was one of the the rabble rousers shaking my fist and say, Apple, like don't give us this massive view controller architecture give us a real example of an app that uses all your cool new stuff. Being on the other side of the table, now, I can understand why that would have been very challenging to do. And it's way easier to say, Look, you just need to be able to get something on screen. So you can see how the new geolocation services stuff works. The point isn't, of this example isn't to teach you how to code, it's to teach you how to use the SDK. And so now I run into a lot of those problems, like I really wouldn't want to put, you know, as an engineer, I wouldn't want to put all my code in one file. But for this training, or education type of code, it actually is easier to see it all in one file versus jumping around and doing things that sometimes is easier to repeat yourself versus having some abstraction that then becomes another layer of context that somebody has to keep in mind.

Steve Westgarth: 24:34

I think the idea of developer relations is becoming really, really interesting. I mean, in my own company, we're starting to think about Yes, how external people might want to access our API's and how your we might want to provide external services to other organisations. But actually, even within the company, we now have your sub teams who are focused on building back end API's or as we call them internally mid services some module integrated digital services are We also have your front end team, so building apps or building web front ends or whatever it might be. And I think you're we're starting to actually realise that, you know, we need to almost kind of have Developer Relations inside the company, just to kind of promote how our API's work, how our SDKs for work, I think can be consumed by other teams. And I think companies are, you're finding that that more and more important now, and I can see it myself in my own company, it's something that I think that you're, as we move forward, it's going to become an integral part of every engineering team, don't you think?

Jaime Lopez Jr: 25:31

Yeah, you know, we started off this conversation on Developer Relations, I was definitely focused on the more visible part of it, which is the, you know, working with people outside of the company. But there is an internal facing component of this where I think, hopefully, I started out by saying that, you know, enabling developers to build cool stuff on our platform, I didn't hopefully didn't specify external versus internal or third party versus first party, as a very intentional thing, where, you know, ideally, people who are inside of the company are building and using the same platform that we've exposed and made enabled for third parties and people outside of the company. And it is helpful for people to I don't know if they have this term, colloquially, in the UK, for this, but like here in the USA, people often say, you know, dogfooding, eating your own dog food, using your own software, so that, you know, it's, it's good, or it's rubbish, right? Is it actually 10% beefier than it was last year sort of thing. And there are actually roles out there that are specifically internal developer relations. This is largely, you know, massive companies like an Uber or Google or an Amazon where, you know, they've got 1000s and 1000s, of engineers, hundreds of teams, and everybody does their best to build using stuff that's already there. Realise, oh, this doesn't fit my use case. Let's make this n plus one different way. And eventually, somebody says, Why do we have 30 different ways to communicate with the database? Shouldn't we have one or at least smaller than 30. And then you have people doing sort of internal developer relations, like, Hey, did you know the infrastructure team has built this cool thing that you know, you don't have to roll your own way of handling Kubernetes, or Oh, you don't have to roll your own way of putting a web service exposed to the internet. So I think, I think it will grow as as software starts to eat the world, as it already has, and, and becomes more pervasive throughout every industry.

Steve Westgarth: 27:42

You touch on a particular challenge that I think that your tech companies versus perhaps your big corporates that aren't necessarily your from a tech background, have really tackled in different ways. Now I'm talking about this idea of duplication and of reuse. So in my professional experience, I've worked in two large corporates in relatively recent history, with very different approaches, your one was very, very aware of every instance of duplication and every instance of waste, or you're doing things twice, and really try to wrap governance around that to find ways to prevent that from happening. And you're almost kind of your, when you're too far, in terms of trying to insist that no, we have to have really good control over what we're building here. And make sure we don't do things twice. The company I'm now in hasn't had any control at all, historically, and they've got duplication all over the place. And we're only just starting to really wrestle with what that duplication means and how we can really get a handle on that, and how we can kind of really create corporate reuse and create capability for the organisation. I think in the tech world, you find that, I mean, if you look at a Spotify, or an Uber or an Amazon, it kind of almost self conference itself, where we've kind of got this idea of, you need to promote your services, promote what you build, promote, why it's cool, and kind of build that collegiate nature within the company and how you the things that are really good that people like will therefore have a life and will grow and will will get life within the company. And the things that aren't very good or maybe aren't as useful, will kind of fizzle out and die. I don't know if you've got any perspectives on that. I mean, in terms of the right way to approach that and to make sure that actually as a company, we're investing our time and energy and building the right things.

Jaime Lopez Jr: 29:25

Yeah, I'm going to pull out the old trope of it depends for the the right way. I don't know that there will be a one true right way. But I do think that we have to take you know, take stock and catalogue where are we really what kind of company are we where are we in our lifecycle? Where are we relative to competitors? I think there's a very large difference when the stick one of my former employers for many years ago, when you are Boeing building large commercial aircraft building defence systems, they You've been around for decades, and you're one of a handful of suppliers, literally could all could all fit in, in one conference room for the leadership. You're going to necessarily think well, I need to manage 106. I don't know how many there are there were there were like 150 260, some 1000 employees, you know, maybe a decade ago, they, I could probably look it up online, but it's the scale I'm talking about, right that like, they've got a mature product set, they've been around for decades, they have to worry about how do I control costs, and variability is a huge source of costs. Right? If we have, you know, 10 different suppliers of, you know, eight and a half by 11, white sheets of paper for the printer at Boeing scale that is a significant, you know, missing out on cost savings of having a singular supplier with a larger, singular order. But if you're a startup, which, you know, I've been at companies, where I was, you know, one of the first 10 People at that startup, duplication is sort of less of an issue, because we were trying to rapidly hit market fit. And even though it was a little bit easier to contain in terms of like, hey, oh, do you have a thing, person who sits across the desk for me, that already works? Great, I'll use that. But if your thing doesn't work, I can build something, you know, relatively one off to get us to the next milestone to get us to that next round of funding, and it was always trying to stay alive, where, you know, it would not have made sense to invest a whole lot in heavy procedures to to control costs, because costs weren't necessarily the biggest factor, the biggest factor was, will we get enough traction in the market to build something cool. And if we spend a bunch of time locking down it principles, somebody else who isn't doing that gets to market gets to scale? And then we fizzle out as they become, you know, the next unicorn company? And those are probably the two extremes between multi decades old company that, you know, software isn't their main business and a relatively small startup, where software is the business.

Steve Westgarth: 32:22

Cool, I think you're absolutely right. I mean, you make some some really good points. And I think that it's something that particularly in the corporate that I've had experience of, you're the people that have been trying to make those decisions haven't necessarily been from a tech background or necessarily you're being engineers by background. How do you think engineers can do a better job of taking responsibility for some of those things, and recognising that actually, you know, we're spending company's money here. Every time we decide to build something, you're the time we're investing in building it. It's literally your your money that we're spending, the The analogy I used to use, I used to work for boots in the UK. And I find myself talking to engineers a lot about how many tubes of toothpaste we would have to sell in the pharmacist in order to pay for the time that it was taken to do a particular activity.

Jaime Lopez Jr: 33:09

Yeah, I think taking, you're taking stock of the kind of company that you are and the kinds of things that you're dealing with. And I think critically not having a hard wall between you and the business side and understanding what is it that's driving their needs? And it's not fair to bifurcate? The the software or information technology world into revenue generating versus cost centre? There's a lot of things in between. But there's a big difference between you know, are you a software team that is building tools that are a necessary cost of the business, but aren't things that are going to necessarily drive revenue? If you understand that use case, you're going to be in a better position to understand when the business is, you know what, we got to cut costs by 10%? Then you might decide, you know, what, instead of hosting our own servers, maybe we should go to a colocation solution. Or maybe we should go to the cloud, maybe that will make more sense because we can't afford to have the capital for dealing with servers. If you're a revenue generating side, it becomes a little bit easier, because people tend to pay a lot less attention to what it is doing as long as it keeps making a lot of money. Yes, somebody might say, you know, this software as a service that we sell, it could make a little bit more profit if we reduce our costs by 10%. But nobody's going to be putting the Eye of Sauron on your budget so much, because it is a revenue generating case where every dollar spent, you know, maybe brings in $1.50 whereas on the cost, cutting side, the cost centre side, every dollar you spend is $1 less than the company So just being aware of where that sits, will be incredibly helpful for you, it will make more sense as to why you might get more budgetary pressures, or why you might get more pushback or less pushback, again, depending on which of those situations you're in.

Steve Westgarth: 35:17

I think a big part of this is engineering teams having external kind of, you know, visibility and awareness of what's going on around them. And actually kind of reaching out and finding ways to be part of the solution and not being part of the problem. You have you sit back and wait for someone to tell you that, hey, you're too expensive, or you're costing too much, then it's already too late. Whereas actually having that awareness of you know, what's driving the company, what's driving the revenue, ultimately, what's paying your paycheck, that's what's important, because then actually, you can reach out and say, hey, you know, what, senior management, I can help to solve that problem. If we just, I think that will then be seen as a way to you become an enabler and enable for the company to achieve its objectives, rather than just a drain on budget.

Jaime Lopez Jr: 35:59

Yeah, and I think maybe the a good analogy that might people might help people to understand on this on this very show, you know, what does it mean, to go beyond just the basic specifications, what you were told, at, oh, you know, the software needs to do X, if you can get to the Y, that might change the approach that you have. So an analogy that's completely hypothetical. But imagine if you're an engineering team, and they come to you and say, you know, I need to transport people really quickly from you know, one coast to the other coast of the country. And if you ask no other questions, you might build a complete brilliant Ferrari it just you know, it will go a couple 100 miles per hour, whatever that is, and kilometres your kilometre, which may vary. And then you'll be really excited. You spent all this money and you built this, this beautiful Candy Apple, red Ferrari, and you show it to the business person, they say, wow, yeah, so that can move, you know, people really fast to two miles an hour. But you know, I've got 75 people to move, how long will it take, as your two seater Ferrari goes back and forth across the coasts, it will take way too long, and they get very upset. Whereas had you realised that when they said, We need to move people from A to Zed very quickly, if you would ask, well, what's the quantity and scale of people they'd said, 75, you would have made a bus that drives, you know, 60 miles an hour's tops, but we'll fit 75 to 100 people, and just slowly but surely get across the country in a much quicker time than the Ferrari shuttling back and forth as high performance as it was. So I think that's, again, a very, sort of artificial sort of example. But hopefully a good way to think about, you know, getting to the reasons why of what the business is asking for will help you be in a better position to enable them, which means you'll be in a much better position of partnership versus just being the execution arm of the company.

Steve Westgarth: 38:09

It's a really good analogy, and it is something that we regularly get wrong with in the software development community. I don't think we spend enough time you're kind of trying to put ourselves into the shoes of the user, somebody said, you should always try to walk a mile in another person's shoes to understand their problems. And I think there's so much truth in that, that as software engineers, we really need to have a fastidious focus on what our customer what a user wants to achieve. Otherwise, we just end up building the wrong thing. And we seem to see a time and time again, and we seem to continually get it wrong.

Jaime Lopez Jr: 38:40

Yeah, yeah, communication is hard. I think one of the things I've learned in my career is that no matter how fancy the technology has become, and has come a long way, since, you know, my time in university some 20 years ago. It ultimately comes down to people problems, people problems are by far the biggest thing you will encounter, the tech will solve itself, right? Like, eventually we'll be able to do just about anything we want in tech, but solving the people problem of communicating effectively with each other and working together and being in alignment. I will be surprised if 100 years from now, it's significantly different in any way I bet I could go into to cryogenic sleep and be woken up in the year 3000. And assuming there's still human beings around other recognisably human, will probably have the same exact problems that you know occurred 1000 years prior to in you know, the year 1022. Right. A lot of the same kinds of things are ultimately the the people problem is is almost something that I would want to tell you know, the college age version of myself that get good at that, at the technology pay attention. In class, that's all brilliant, but that is probably at best 50% of what will get you to be successful. It's the other 50% of knowing people and knowing how to work with people that ultimately will drive your career.

Steve Westgarth: 40:15

So if you go back to, you know, go through your career, and you obviously had some success and different places you go, you mentioned there a bit of advice you would maybe give your younger self, if there was one thing you could tell your younger self, or your an earlier version of you an earlier point in your career, about what it was going to be like when you became a manager? What's the one bit of advice you would give?

Jaime Lopez Jr: 40:40

I think it would give advice that you want to. So my case I have a Bachelor of Science degree in computer science sits in the School of Engineering for for my alma mater. And I remember as a younger gentleman, thinking, you know, I'm done with school in only a couple of years, if I could just literally focus on the classes and courses that are in my major, why do I need to do all this other stuff, I've been speaking English all my life, I don't think I need additional beyond, you know, high school classes on English, not going to become an English literature major history, it's pretty much the same thing that has always been since you know, I was in grade school. And there's not really that much more surprising that the college era, and all of the other humanities type things. As a younger person, I just thought, This is rubbish. It feels like a scam to create, you know, a four year programme out of something that could be two and a half years. And as I've gotten further in my career, I've realised more and more like, Well, being a well rounded individual wasn't just the scam that they were saying at the university, like it makes sense, it will be helpful for you, as a manager to understand other aspects, like for example, managers tend to do a lot more writing of pros than they do of code. And if you're sort of 100%, narrowly focused on on building your technical skills, if you want to move to the managerial track, you're going to struggle, you're going to have a difficult time, putting down into, into reasonably intelligent and concise words of this is why I want to rewrite this part of stack word. This is why I think we should move to the cloud and stick to staying on premise. And it'll hold you back. And so I almost feel like I would have liked to have paid a little bit more attention into what they were teaching then. Versus like, alright, yeah, I'm gonna get my grade point average up, I'll do enough to get the A but I'm not going to be invested in emotionally, I'm just going to go through the actions to pass the course, I would like to go back and really focus my attention on being fully engaged as an individual taking those courses.

Steve Westgarth: 43:08

Definitely, it's actually something I found recently. So I mean, I did my undergraduate course. And I did a master's. You know, I was what 1920 21, something like that. And then, just recently, over the last couple of years, I've actually went back and I've been studying an MBA, which is coming to an end of the end of this year. And you know, I've really found I've taken a really different perspective on learning, and and what it means to really go back and study. And I'm so pleased to have had the opportunity because when I look back to what I did in my undergrad, I was very focused on making sure that I got you know, I got the right grades. I got the qualifications, yes. But But I did enough, I didn't I didn't go the extra mile, I didn't really kind of you look at your What else could I learn around the subject? Where can I go, I just focused on what I needed to get the grades that I needed. And I think I've really understood over the last couple of years, your what it means to you to really embrace learning and to really embrace learning as a culture. And it's something that I try to talk to my teams about and talk to the work to be about. But I think it's so important that we're always looking for those opportunities to grow and develop and do new things. So we can broaden horizons.

Jaime Lopez Jr: 44:16

Yeah, and I think probably a perfect example would be when I went to school, there was no such thing as an iPhone, you literally couldn't learn how to build mobile apps, you had terrible rubbish apps. And what would not be recognisable as an app store for flip phones and what we would call you know, feature phones or dumb phones if we're being diminutive of it. And, you know, if you are unable to learn outside of a forced schooling environment, you're going to miss out on career opportunities like building for the iPhone, and and I don't know what's going to be next but they won't be teaching that in school either. Initially right? They won't necessarily be something where or, Oh, if I just go to MIT, and they've got this whole programme in, you know, web three machine learning for the metaverse, I could be wrong. Maybe MIT has that sort of stuff, maybe the bleeding edge, but it's going to be harder, it's gonna be very expensive, versus being able to take those, you know, hopefully, out of university in college, you learn how to learn, you're going to continue to need to use those skills, as you go through your career in software engineering, just, there's no way about it, you're you're not going to be, you know, stuck doing the same thing for, you know, 40 some years of your career. And if you are, you probably won't be considering yourself to be very fortunate or privileged, you probably are not having a good time. Right? As you as you, as you watch your your career prospects diminish, because you've not moved along and adapted to the new ways of doing things.

Steve Westgarth: 45:57

I think you're right. I mean, you're we're in an industry that literally does reinvent itself every few years. You think about, you know, iOS development. So I started, you're developing iOS apps, you're when the first iPhone came out, yeah, I was really proud when we got the App Store, I didn't quite make do one. But I had an app day on day two, or three, which was amazing with no Objective C, few years later, Swift comes about and suddenly you're literally reinventing your skill set, you're learning Swift, you're learning a whole different language, you think about your maybe web development, or you know, kind of where that kind of went, you'll react a brand new framework, you're literally you're five, six years ago, react didn't exist or wasn't a career. If you've wanted to go into that space, you've had to reinvent yourself and kind of learn that you'll learn that technology. Whereas other industries don't really have that you think about someone who goes and studies law, you're yes, there's gonna be new case law or things gonna have moved on. But you know, if you've studied law, the legal system has worked pretty much the same way for your many hundreds of years. You think about accountants in the same thing happens you think about your pretty much every other industry, there's, there's very few industries that reinvent themselves as often as we do. And actually, just because you've got the right skills now, doesn't mean you'll have the right skills tomorrow, or the skills that a company will need you in a year's time or two years time. So we really do have to embrace that learning culture. Otherwise, otherwise, we're all dead in the water. Right?

Jaime Lopez Jr: 47:22

Agreed. And it is an area where as an industry, I'd like to see us spend more of the company's time and money building up our people building up their skill sets. That's not necessarily something that people are willing to do. What's the common trope, everybody wants to hire senior engineers, there's not enough senior engineers to go around. You know, we're seeing junior engineers come from junior engineers, who put them on style evolve to the next level. And everybody wants somebody else to do the investment. I hope somebody else builds up this, you know, this set of junior engineers and I can then go pick from and have them be my seniors. I don't know how we got away from this, but you know, you, you listen to people from their careers. From very early on, they say, I started in the mailroom of this company, I pushed mail around from office to office learned enough about how whatever company they were working at, worked, got an opportunity. And then look, now I'm VP of such and such, really a lot harder to do that nowadays, everybody wants sort of the perfect unicorn candidate who fits all of checkboxes and somehow somehow isn't, you know, a million dollars a year salary, we want them as cheap as possible. So, I would love to see us as an industry get, you know, get out of the idea of, well, you yourself as an individual need to spend your off hours away from your time and family, you need to spend your own money to go to conferences, go to training, I would love to see us do more on providing regular stipends and regular hours of like, Guess what, every, every second Friday, that's your time, get some books, get some YouTube courses, you know, get some LinkedIn courses, whatever, go through that I think that will be healthier. And ultimately, in the industry's larger interests of needing good solid engineers who aren't going to they're not going to appear from trees, they're going to be people that we've built up over time.

Steve Westgarth: 49:26

I think so much of what you're talking about is linked to building a healthy technology culture. And, you know, particularly in companies that aren't solely focused on tech, right because you know, if if you think about your your Googles or your Amazons or your your Spotify is of the world, they've they've kind of your grown up around in this culture where they've recognised that people need to be continually learning, innovating and refreshing their skills, whereas many other companies have never really had that culture embedded within it before. And it's so difficult to change the culture within an organisation. So how do you think we can help yours? senior leaders and organisations to recognise the need to embrace this, this need for engineers to learn.

Jaime Lopez Jr: 50:08

There's some great quote out there and I apologise, I don't know how to give it attribution, I'm sure it's a Google search away. Somebody out there has a quote that says, they're discussing with their management team, you know, we would love to train people on this new skill set. And the management team says, But what if we train them up, and they leave kind of a cost centre idea of like, I'm going to spend this money to train them, and they're gonna go go with my competitor is gonna go out industry is gonna make a lot of money. I basically throw my money away. The response in this quote is, what if we don't train them up? And they stay? Meaning? What if they have, you know, rapidly diminishing skills that we're not building up and they ultimately become an anchor that hold us down, not through any fault of their own, but because we are not willing as a company to invest in them, because we think some small number of them will leave, I think that will always happen. Right. As a perfect example, right now, anything related to cryptocurrency blockchain, web three is really hot. And so I think if you have an internal School of stuff, I just assume you will lose some number of those people to a crazy, half$1,000,000.02 million dollars a year salary. That's true, nothing you're gonna be able to do to stop those people. But you want to be able to build enough of those. And hopefully, you have a good culture at your company that people want to stay and work with you. Not just because of the dollars and cents, but because they're very happy where they're at. And yeah, maybe they could work on the cool new web thing. But you know, what people have different needs and and you do need to make sure that money is not a concern for anybody on your team, because that's the way we feed ourselves. It's the way we keep our families, you know, healthy. But it's not the overriding concern for everybody. Some people are like, I really love. Like, in my case, financial services, technology, I really love healthcare, tech, I really love aerospace, they're perfectly happy to stay if you're willing to give them opportunities to build cool stuff, I think no matter what engineers are always going to want to build cool stuff. And if you can align the build cool stuff, with what your business is doing. I think that's a rock solid way to continue to to innovate and continue to stay relevant in the industry.

Steve Westgarth: 52:38

I think you're right, I mean, there is definitely something about making sure that your people have the right level of money. So they can they can cover their expenses and their bills. And but that kind of gets to a point where you don't need to earn any more money, you can even cover those basic needs. And actually going going back to my MBA, there's there's a thing called Maslow's hierarchy of needs. And it kind of starts off at your what those basic needs, what does everybody need, and you kind of go up this pyramid, and you end up at the top, which is self actualization. And that's all about, you know, well, how do you how do you really transcend that permit? And how do you get to a point, you're where somebody isn't just working, you're because they, you're there need to, it's because they want to they're really invested in your company culture, and what you're trying to achieve what you're trying to create. And I think your companies generally need to spend more time kind of focused on that saying, you know, what, what's our mission? What's our vision? How are we going to change the world? And, and I know maybe that sounds, you're, it's probably quite cliche that people talk about changing the world or, you know, you're kind of making a big difference. But actually, your tech is one of those industries, where if you're working for the right company, or you happen to be working for the right tech, anybody literally can change the world and have a measurable impact on on any number of people or organisations. You know, right from your tiny startup, it comes up with an idea. You're right due to a bit cold, but it really has kind of flip that idea on its head of how people can impact the other people around them and governments and countries, you've only got to look at some of the things which have come out of hackathons to kind of see your how much has been achieved. Your Microsoft Teams. I know we're talking to Microsoft, which was a big corporate, I learned this week that came out of a hackathon, which is you're being made up of your maybe your seven or eight individuals who came together to build new communications app. How amazing is it that a small number of people can impact the world in such a massive and amazing way?

Jaime Lopez Jr: 54:26

Yeah, I think, you know, a big thing that's been sort of key to my career since probably about 2013. So I didn't start off with this idea in mind coming fresh out of out of school. I was 100% focused on the technology coming out of school. And then I worked at a company a startup called offer up it's like a mobile Craigslist. For the Canadians. It's like Kijiji for the UK. I have no idea. I think Wallapop or Let go might have been sort of big in, in the Euro, Europe region. I learned there that the software that we were building, besides being cool stuff was actually helping people. So we got all of this sort of incoming, through our customer support channels, because people just didn't have a better way of reaching to say, Wow, thank you so much. I was going through a rough time, and I sold some old junk that I had in my garage, and was able to do interesting things with it, maybe, you know, pay medical bills, maybe, you know, take care of whatever financial troubles that they had. And I never consider that as part of sort of what I do. And so I've sort of tried to guide my career towards I want to continue to work on things where I can make people's lives better, in some way. So prior to joining Jack Henry, I used to work at a neobank challenger bank here in the US called simple if, if you're in the UK consider it to be the American equivalent of like a Monzo, Starling, and 26 revolute, sort of a digital bank, sort of idea. And there they were really keyed up on how can we make finances better for everyone and make it more inclusive, make it more available, I get something of carried on here. Here my career Jack Henry were a big reason why I want to do what I do as a developer relations professional of enabling developers to build cool stuff for Community Financial Institutions, is because I want the people who have accounts at those financial institutions to have better access to better technology. Of course, we want everything to be online and mobile and accessible when we want it. We want it to be a good user experience, we want to be able to bring together a much more complete financial life for somebody versus well over here, I've got this loan over there, I have, you know, this mortgage over there, I've got, you know, my joint savings account with my partner over here is, you know, the money that I use when I when I go on conferences, really tried to bring things together using technology. So it seems like kind of a roundabout way. And it seems like I'm sort of so further away, removed from that. But everything that I'm trying to do is focused on making people's lives better. Hopefully, that makes the world a better place, but at least it makes their lives better.

Steve Westgarth: 57:49

Yeah, 100%. And I mean, that's quite inspirational isn't that the you know, we as a community, you're literally can make people's lives better if we think about it that way. And this is not about, we're not building technology for ourselves. I mean, we might be, but you know, generally, if you're in a lot of companies, we're actually building software, that's going to have an impact, it's going to make a difference. And there are a few, there are a few career choices where you can really do that. And I guess I just want to go back to something you mentioned a little bit earlier on. So we talked a little bit about, you know, used to be an engineer, and then you decided that you wanted to kind of go down the the manager's path and your, I guess that that was a very, very different kind of your tack and engineer. So let's talk about you have to make that decision at times, you got to get to a certain point in your career where you did decide, Hey, am I going to continue down the technical path or am I going to switch and, and go down the management path and go that way, I just wonder if you might be able to share a little bit about your journey and why you decided to kind of take the you've taken your particularly from where you are now.

Jaime Lopez Jr: 58:53

You know, I've had multiple opportunities throughout my career to lead teams. So being a technical lead, development lead or an engineering lead. There's many different names throughout the industry and kind of depends on the company. But the basic idea is leading a group of individuals in a technical way. And that has given me opportunities throughout my career where I got to grow people to a certain extent. But without having any of the downsides of of being a manager and having a manager Todd like a perfect example would be, you know, building up as technical lead or development lead non manager, building up individuals. So having junior engineers start becoming, you know, on the path to senior engineers had that fun part or at least it's fun to me. But the difficult conversations around you know, I would like a raise or I would like to take, you know, a week off to go to Tahiti I used to always be able to say, well, that's okay with me, not my problem, that's the manager to decide that, right. So the manager had the the downsides of, it's totally fine for me as a technical lead, I can accommodate that in her schedule, it's up to the manager, decide where you get that raise, where you get that paid time off. And now, as a, as a manager, I decided to take this role, because I did want to say, you know, what, I want to step into a managerial role and have developing people not just be a cool thing that I can personally do and have purview to do, but have it be an actual explicit part of the job and explicit part of the way that I myself am evaluated as a contributor to the company.

Steve Westgarth: 1:00:50

It's a really important decision to make, I mean, I think about my own journey, in a very similar way, I came from an engineering background, and I also made the decision, you're at a certain point to say, hey, you know what, I'm gonna be on the management track. And then that's, that's where I want to be. And I think it's really interesting the parallels, because my rationale for doing that was also very people centric, and in wanting to really invest in people who want to help them grow and to learn. But I think even as a manager working with an engineering, it's so important to keep your technical skills, current, and to keep up with what's going on into you. Okay, so I don't code every day, I still have personal projects, that kind of UI I like to write, I still love to kind of dive into some of the code that my team is writing, just to kind of see what's going on. And make sure that you you can do that, you know, every now and again, although actually in my current company, I haven't done this yet. But at some point, I'm sure I will, you know, I'll randomly always a PR against the code base, and just kind of go in and contribute some code, just because I can and it's important to kind of to keep current and also give the team that opportunity to kind of to look at me and Ken to say, you know, hey, there's a better way to do that, Steve, we can teach you something. I think that's really important, too. But I think it's, it's equally important for companies to also make sure that the management tracks are not the only way that people can develop, because you, I've also had experience in companies where you've seen, you know, people that kind of got to a certain point in their career, and in order to progress, they're expected to take on a management responsibility. Whereas actually, you know, it's really important that as companies, we valued the technical skills at the same level, as we as we value the management skills. I don't know if you've experienced anything similar.

Jaime Lopez Jr: 1:02:31

Yeah, I am glad that the industry is changing somewhat and recognising that you don't want that problem, as you mentioned, okay. I'm superduper, senior engineer, but literally, the only way to increase responsibility or increase compensation or perks or whatever, is to switch to management. And it was viewed as a singular sort of career ladder where you come in, as you know, the most green summer intern, you become a junior engineer and keep going up. And eventually, you get so good at software development, that you remove all the software development responsibilities and become a manager as you can continue going up. That was the old way of doing things. There are still places that do that. I'm not going to say that they don't, I'm glad to see that the industry has said well, at least there are two tracks, right, where there should be equivalent peers between being some level of manager and some level of individual contributor, like the staff, and principle engineer type roles have have started to come up as parallels to those where yes, you'll never be CEO, software engineer, right like that necessarily as a managerial type role to it. But you should be able to get pretty high and quite often to something like a CTO CIO type level that has parallels to that. I think that this has manifested in things like the lead dev conference, right? So they have those in Europe, they have them in the United States. They have, gosh, it's just it's recent. It's like staff plus or something that's meant for you're not just lead dev in a I'm a manager. I'm a Director of Engineering VP of engineering, CTO weeds. I am Staff for senior staff or principal or Senior Principal Engineer at a tech company, individual contributor, how can I continue to grow? So I'm really excited about that. And I'm hoping once the industry realises that there is two parallel tracks that are healthy for to have individual contributor track and a managerial track. I'm a big fan of Patrick was approach that there's actually a trident and that there is a technical lead path that is kind of in the middle and is separate from either For the individual contributor route or the managerial route, like as an example, I have worked with some, some senior engineers who I, as a manager would never allow them to lead a team because they just do not have team leadership skills, they cannot be a tech lead. But I've also worked with some tech leads, I'd say, they're not really, like, Great as senior engineers, like individual contributors, but by golly, they can lead a team and they can get them to produce great things. So I'm a huge fan of the Trident model. But it's progress to recognise that there is at least the bifurcated model of manager is not a a promotion manager is a different kind of role.

Steve Westgarth: 1:05:45

And how does the industry evolve to that state? Because you know, and we think about kind of how new technology kind of comes about when you're generally somebody try something or create something or your company comes out with something and we start to adopt it? Can the same happened with organisation structures like that, do you think?

Jaime Lopez Jr: 1:06:02

I think so. I don't know how we should do it as a healthy way, if, if I figured it out, I should probably write a book. And we'd probably be, you know, a best seller and probably go in the conference storage just for that. But I can say, cynically, a negatively the way that I've seen organisational structures change throughout the industry, is because it becomes fashionable because somebody comes really, really successful doing something. So I think the evolution of staff and principal engineers and as separated manager and individual contributor track has come out of the success of the tech giants like Amazon, and Microsoft and Google. And so people look at them and say, well, if Google does that, maybe we should do that, too. I think that's a terrible reason to decide to change your company. But it does cause things to evolve. So perhaps someday, there will be a trident company that has an individual contributor track, a tech lead track, and a managerial track who become the next unicorn. And everybody will say, Wow, well, how, how did they go in five years from a company nobody had ever heard of, to this huge monster that, you know, the US and EU are getting mad at because they're too big? Oh, well, they have a trident model. Maybe we should do that, too. And then everybody will start doing it right, it becomes this weird sort of fashionable, that's the cynical way that I think it will evolve. I don't know how to move it to evolve, other than maybe coming on this sort of show and hoping that we can convince at a grassroots level people to do this sorts of stuff.

Steve Westgarth: 1:07:40

I think you're right about you're kind of learning from others and kind of seeing what works in other industries. I think we have also seen examples where that can go the wrong way. I mean, you think back to the famous Spotify blog about the Spotify model for software, engineering teams, and even Spotify would argue that they don't use the Spotify model. But yeah, that model has been copied by literally 1000s of organisations the world over. And people try to implement it, as they believe Spotify have done or your show could do. And it hasn't really worked for a lot of companies. I think that you know, the important thing for me is your as, as an organisation, looking at your context, looking at kind of where you are, yes, looking around to what everybody else is doing and taking best practice, but then really applying that in your context. And in order to apply it, it requires you to really understand what you're trying to achieve, and what you're trying to get to, in order to achieve that organisational, self actualization that that we're all trying to achieve.

Jaime Lopez Jr: 1:08:42

Yeah, yeah, I think context. And it depends. That sort of thinking will help you throughout your, your career to be more successful, where I'll give you a perfect example of where I didn't do that. Right. So I'm definitely a big believer that, like, Google's problems are not your problems. That used to be Yahoo's problems are not your problems, right. So as a very junior web engineer, and I'm talking about in the era where internet explorer six was the standard. And Mozilla the dinosaur, not the Fox was the hot new browser on the market. In that era, I remember when the oh my gosh, I should have it in front of me. It's an O'Reilly book. And it was about high performance websites from one of the big engineers at the time at Yahoo. And I remember we had a web application that when I ran all the different tools like Man, we should be getting an A and here we are at like a D or an F. We just aren't, you know, we just do not have a highperformance website. Well, looking back at this through a different lens is a much more experienced engineer and manager Mike We would never achieve the scale that Google or Yahoo will achieve. So those incremental, you know, kilobytes are not that big a deal, especially given the context that the larger problem we had for performance at the time was the lack of high speed internet, at maintenance Line stations out in the middle of nowhere airports, right? Lack of connectivity all together, is it problem not? Is this total page a megabyte? Or is it a megabyte, you know, point five, a little bit different than, say, like a modern Facebook or Google where they will take a very senior highly expensive engineer, and say, you have six months to shave five kilobytes of every YouTube video, I don't really care how you do it, I don't care if you create a whole new, a whole new codec protocol and work with the tech industry to make this a standard and a cure. If you find some configuration flags, on existing protocols, we just, it is worth 1000s and 10s of 1000s and 10s of millions of dollars, if you can just shave five kilobytes off of everything. So again, context will matter. If I was a Google engineer, I'd probably think about those sorts of things. Somebody's not a Google engineer, have a different set of contexts and a different set of problems that they don't have to deal with. And so bringing it back to the Spotify thing, you know, being almost envious or jealous of what other people are doing is probably not the right approach. The right approach is to say, what are the problems that they had to address? And do those problems apply? Or can they be adjusted in some way to apply to us will we benefit from following the same kinds of things that they did?

Steve Westgarth: 1:11:40

It reminds me of a story that I was told once by an engineer who worked at Facebook, and they have a thing at Facebook, where every every quarter, I think they've got to go into your meetings with their manager, where they have to demonstrate Well, what impact have you had in the last quarter and, you know, I think it's a really healthy thing, actually to say, you know, to make sure that we're not just achieving our objectives, or you're kind of just you're going through the middle way, we're actually having impact for the company and, and really achieving great things. And in this particular engineer, had done some work on one of the Facebook advert algorithms. And he managed to shave something like you're a 10th of a second or something off your how this particular type of advert loaded on a page. But he did the calculation to work out how many more billions of dollars that generated as a result of having shaved off, you know, that, that that load time of that particular advert of that particular image? And you're going into your performance review and kind of saying, Well, look, that's the impact I've had, I've generated your x billions of dollars for the company. But actually, as you say, you know, in the majority of companies, you know, if we shave off a few milliseconds off of an image load, is that really going to have the same impact? And are you better focusing your time somewhere else? It's all about focusing on your individual context? And what's going to make a difference to your company, depending on what you're doing and where you're working?

Jaime Lopez Jr: 1:12:55

Yeah, I think there's probably because of the things that you're talking about, for the larger tech companies, there's probably a big reason why it's, you know, the same groups of companies that tend to have like, Hey, here's this new, you know, this new UI framework we came up with, or this new build framework we came up with, because pick one, Apple can't handle our scale, Microsoft can't handle our scale, whatever. I'm sure it's totally valid there. But I I sort of suspect that a lot of it goes into somebody was looking for a way to show impact, because by golly, I need to go from this level to the next level plus one, and n here. And the only way I can do that is to have that happen. And I think you see this also manifest in the fun. Why do we have yet another chat application from the same company? Like that's, that's bonkers. How many do we need? Well, because nobody ever, you know, this is a silly quote. But like, nobody ever got promoted for maintaining and reducing costs for the existing thing. Everybody got promoted for building the new thing, or at least taking the old thing and completely changing the UI, and coming up with reasons why it's better than what we had before. Resume or or promotion driven development is a bad anti pattern that we as an industry need to get better at sort of self policing. And I think as managers, we need to start doing a better job of keeping our keeping the pulse on why are people doing what they're doing? Is it because they think that's the only way they can advance? Can we give them other ways to advance and to recognise their their accomplishments, I think that's helpful. One thing that I've, I've experimented with, on this both for myself as an individual when something I'm guiding my my direct reports on is keep a brag documents for what you do throughout the year. And when people wonder what that is and why. It's essentially if you've accomplished something that you think is notable, in the moment, go into the Google Doc or Word doc or whatever it is, you know, or notion or whatever and just put in Date, Month, whatever makes sense for you and what you did and enough context that if you came back to it a year later, you would understand what that was. Because in the moment, you'll recognise these things that are important. But if you did something, you know, in January, that was great. And you get all the way to December and his performance evaluation, you might just forget the cool stuff that you did, your manager will certainly forget about the stuff because they didn't do it, you did it. Right. If you're not going to remember, they're not going to necessarily remember. And I think if you keep a brag document, you'll be better positioned to have a narrative going into your performance evaluation of like, here's the ways in which I showed impact, it won't necessarily be, here's the flashy thing, I created a new chat app for this application, this company or I did some flashy thing. It could be Hey, you know, team was having a trouble with X, I refactored x and now it's no longer a problem. Look at all these features we've built upon this new thing or look at the people that I've mentored on the team here with these three junior engineers, they're now on their path. And some of them even been promoted to senior engineer, because of the ways I was able to mentor them. I think there's other things that we can be doing to recognise, recognise effectiveness beyond just the big, brilliant, flashy things.

Steve Westgarth: 1:16:23

So it will be wrong of me to let you go today without touching on how you value community. So I mean, you get out on suddenly pre pandemic, got out to a lot of conferences and did a lot of talking. You co host the more than just code podcast that you mentioned earlier today. You really value kind of getting out there and talking to engineers, and you're in, I guess, promoting your skills and sharing your knowledge. Why is that important to you?

Jaime Lopez Jr: 1:16:50

I think it's important to me, because I know how challenging things can be. I think I've been you know, okay. In my career, I think I've done all right, I've certainly been people who have helped me along the way. But I can think about how it is so challenging to, to get started and think about how can I achieve what I want. And I believe a good way to give back and make the world a better place is to help share your knowledge or share your experiences of how you got to where you're at. And it's partially, here's what I did, I shouldn't have done that. Here's what I would do instead is useful as a, you know, the difference between knowledge and wisdom is kind of like the scars you have on yourself, right. Wisdom is something that you get largely from experience and having experience that you can share with other people is great. As an example, I remember when my university used to be 100% Pascal programming language from like beginning to end curriculum. I came in just at the time at which my first couple of courses in computer science were based in Pascal, a structured programming language. And they were switching to what was then the new hotness, Java and object oriented programme, programming language. And at the time, the Internet was not quite what it was today, I couldn't go watch YouTube videos, I couldn't go see somebody live code on Twitch. I had to go to not Amazon because that wasn't that big. Then I went to Barnes and Noble, and found some Java books and said, Okay, I'm going to teach myself Java because I need to do really well in this course, and I can't have that be holding things up. And that was the best I had the time, I would not want anybody today to have to go into a bookstore and find materials, I'm really happy to see that there is a whole bunch of content that people are putting out there on blogs, tutorials, videos, live streams, podcast, whatever, to help other people level up quicker, right. I think if I were to start out as a fresh new engineer today, I'd be much further ahead by this point in my career because of a community of people helping me along the way. So I'm hoping to do the same thing for putting a ladder down behind me to help other people get up quicker so they don't have to do the difficult climb that I had to.

Steve Westgarth: 1:19:27

And will we get to see you at any conferences this year? Is that going to happen at all?

Jaime Lopez Jr: 1:19:32

In person stuff is interesting. There's at least a a customer conference that we have a January January Connect is is currently scheduled for the end of August, early September. That's where we bring in our our community banks and financial institution credit union customers come in we talk to them. We bring in vendors, we even bring in competitors and we all talk about what's new in the industry. Where are things going. I believe that will You know, fingers crossed pandemic times. Last year went virtual a year prior and went virtual. Hopefully it's in Brisbane this year. But for non professional conferences, I kind of wonder it's, it changes from day to day. And from week to week, I'm really hopeful that I can get out to a couple of conferences, at least as an attendee, in person. And even better if I can do some of them in person as a presenter, I don't know it very well could be virtual only this year, it really just depends on when it's up happening. But I am very excited for, you know, the light at the end of the tunnel in which it becomes just another way of doing things of like, oh, I can't make the trip, whatever, I'll watch the live stream, but also have the option of like, yeah, I really want to go see people. Let me go, you know, see my friends, see my colleagues meet new people. In person, I'd love to be able to do that, again, I miss, I miss stuff like code mobile, over and over in Chester. I missed Dev Rel con over in Tokyo. slightly bitter that the pandemic cheated me out of going to Australia to speak at at a conference there because that was scheduled for the fall of 2020, which clearly wasn't going to happen in person. So looking forward to seeing people and seeing their faces again, as more than just a two dimensional little postage stamp.

Steve Westgarth: 1:21:29

Well definitely hope we get to get you back here into the UK at some point. And to see you talking again, because I think some of the content you share is awesome. And actually talking today, it's been really inspirational. It's it's been cracking Kenny, you're getting some of your insight and knowledge. So So Thanks very much for sharing. And thanks so much for joining me on the engineering leader. Hi, May is one of those people that I could literally talk to all night. Such an engaging engineering leader with so much to offer the engineering community. We'll definitely invite them back on to the podcast later in the year. And don't forget if you want to hear more from him, check out the more than just code podcast. It's a brilliant show that discusses all things tech, particularly in the Apple ecosystem and it's well worth a listen. If you're enjoying the podcast, please continue to let me know by reaching out on Twitter at Steve Westgarth or by searching Steve Westgarth on LinkedIn. I love hearing feedback from folks who are listening. It massively helps me to develop the show and enables us to continue building the engineering leader community. My name is Steve Westgarth and this is the engineering leader