Brendan Humphreys | On Developing Your Engineering Career

Brendan Humphreys is the Head Of Engineering at Canva.

Read More
https://www.graduatetheory.com/45-Brendan-Humphreys

All links in one place
https://linktr.ee/graduatetheory

Direct Links
https://www.graduatetheory.com
https://www.graduatetheory.com/buzzsprout
https://www.graduatetheory.com/instagram
https://www.graduatetheory.com/youtube

Popular Episodes
Dan Brockwell | On Startups, Corporate and The Importance of Personal Branding
https://youtu.be/BRjk31I3Piw
https://www.graduatetheory.com/15-dan-brockwell/

On The Journey To Banking and Consulting Graduate Roles with Cheran Ketheesuran
https://youtu.be/P_BB_1Ysb0c
https://www.graduatetheory.com/35-cheran-ketheesuran/

On Finding and Thriving in Your Dream Graduate Role with Kerry Callenbach
https://youtu.be/pElG-nqkoFM
https://www.graduatetheory.com/27-kerry-callenbach/

Content
00:00 Intro
00:29 A Day in the Life
05:11 Designing a Promotion Structure
06:27 Did Brendan always want to be in management
08:51 Measuring engineering teams
12:51 What makes an effective manager
17:31 10x engineers
22:00 Skill improvement as an IC
25:15 Tips for Junior Engineers
34:58 Specialise vs Generalise
38:21 Engineering traits that are undervalued
43:01 Importance of startup journey
49:29 Failure that ended up being a success
51:45 Best investment of time or money
54:37 Advice for Graduates
57:25 Outro


QTNYlNWMKXs7CmOt9CAU

Transcript

Brendan Humphreys: 0:00

engineering is, and probably always will be a highly collaborative exercise. And so being able to see, uh, a problem from different viewpoints and to really, uh, to deeply build that skill of being able to do that is highly valuable in unlocking collaboration in teams.

James Fricker: 0:29

Okay. Let's get started. So we'd love to hear Brendan, what a day in the life of Brendan looks like in terms of, um, like what, what is your day like today, your week? Like, is it, do you have like meetings all day? Do you still do much, uh, like programming and during the day, or is it all just meetings and stuff interested to hear

Brendan Humphreys: 0:53

I do a fair few meetings, um, but I'm careful to defend my time. So, you know, one of the tricks you learn fairly early on, uh, is defensive calendaring where you kind of block out your calendar and you protect it so that, uh, people can't just invade, uh, your calendar and, and. block out town time. So if you create that space, uh, to do the deep thinking, that's important. And I use that to do mostly reading. Like I read a lot of documents, um, internal, I read a lot of stuff externally, but, but mostly internally, um, just reading and approving proposals. Um, but look, when I'm in meetings, I'm dealing with a whole bunch of, um, uh, different aspects of, of running a big company. So a lot of it is context sharing. I try to maintain a, a very broad view of what the hundreds of teams are doing. It's necessarily broad, cuz there's so many teams and there's so much activity, but in my travels, in talking to people, I can, uh, hopefully spot opportunities for, you know, team team, a to talk to team B, cuz you seem like you're doing something, uh, quite related. Um, also sharing context, uh, across teams. So, uh, teams can feel like they're not getting the resources they need to execute on their goals or their, their, their work is not being prioritized or it's, or they're blocked. Uh, I can provide context around priorities. I can help unblock. Uh, I can. So it's that kind of tactical work is quite important, but I, I. Try to focus also on some of the more strategic questions for Canver Canberra's been growing, uh, exponentially as a company. And, uh, so there's a lot of scale challenges that come with growing an org very, very quickly. We've been doubling our org every year, uh, year on year, uh, for at least seven years. And that means we have to kind of constantly evolve, um, the processes and the structures and figure out what what's working. What's not where are the gaps, um, and try to pragmatically put in place, uh, new processes and structures as we evolve and grow. Um, and try to think, you know, try to be future thinking in that, like where, where do we need to be in a year or in five years, and try to lay some tracks in those directions. Um, I spend a fair bit of time too, with escalations. So things that, that just, um, for there's competing opposing views on, on whatever proposal and it'll come to me and I I'll make a final call. Uh, I deal with a lot of approvals. So salary approvals, equity approvals, hiring plans, spending on tooling, and I spend a fair bit of time doing recruitment. So when we are trying to recruit top talent, uh, I will be involved, uh, to try and, um, sell, sell, uh, high profile candidates on, uh, the joys of working at Canada. The challenges that are before us. Uh, another thing that takes a lot of my time is, uh, performance management. Like thinking about, uh, our career framework, adapting our career framework, interpreting our career framework so that our managers, uh, understand how to set expectations. Uh, we have a system of promotions, so, or we don't call them promotions. We call them role changes at Canva. So we run a process that, um, at a regular cycle we accept applications to, to be promoted. And we look at evidence, uh, of an individual's, uh, output, uh, at see if it measures up for, for that promotion. And we put a lot of effort into that to make sure that we calibrate across the organization. So we are fair. Uh that's that's a lot of work.

James Fricker: 5:11

It's pretty cool. And when you think about like designing some of these things, like whether it's the sort of, um, the structure around promotions and like you, you mentioned that the engineering size has growing quite rapidly, where do you look to, or like, how does, how do you sort of think about creating those things? Like, cuz are there, do you kind of borrow from other organizations that are in a similar situation or is it kind of like, let's just think about this from first principles and try and design our own, like, or maybe it's both, it sounds like it's a kind of a tough thing, right? When things are growing that quickly,

Brendan Humphreys: 5:44

Yeah, look, it's, it's a little from column a, a little from Colin B. We certainly go and look at prior art. Um, we study companies that are ahead of us on the growth curve. Um, we try to look at those companies kind of soberly. Um, and, uh, we use some as caution, retails and others as kind of exemplars that we might want to replicate. We always wanna put our spin on processes and structures though, to make them our own. So we, we invest a fair amount of effort into kind of understanding what's worked for other companies. And then distilling it into language that is familiar to, to Canva and feels very kind of Canva reque.

James Fricker: 6:27

Mm. Yeah. Nice. Have a question too, around like your role at the moment. You're obviously looking after lots of different engineering teams across the organization, but is that something that you always wanted to do? Like, did you always see yourself as someone that was like leading like lots of engineers or has it like perhaps been something more recently that you were kind of like, oh, this could be cool. Like, let's give it.

Brendan Humphreys: 6:54

It certainly wasn't a career ambition at all. I, uh, I've always enjoyed individual contribution and engineering management, but mostly individual contribution. And across my career, I've mostly just been an engineer, uh, and, and building things I have had stints at being a manager in other organizations. I think that the difference with Canver is I joined very early. So the level of commitment I have to to is probably uh, higher than, than at any time in my career. And, uh, I've always had this philosophy of just doing whatever. And I think a lot of the, a lot of the early employees had this, uh, very early on of just doing whatever is needed. And so, um, as we grew, you know, it became more and more apparent that we need engineering management, uh, as well as individual contribution. And I kind of found myself kind of stepping more and more into that role at Canva, but I enjoy it. Um, I think the challenges are, and the challenges and the rewards are very different, but the rewards are still there and they're still quite intellectual. It's Mm. it's not, um, it's not coding. I do get to do that occasionally, but very, very rarely. And it's always a bit sobering when you, when you try, try and try and get back on the tools and realize, oh, it's been a while. How does, how does, how does get work

James Fricker: 8:19

see. oh, that's funny. No, that's cool. That's interesting to hear that. Cuz I think, um, yeah, many people that are like senior and perhaps like even more senior than like the most senior people. Right. Have this clear thing without like from an early stage, I like I'm gonna pursue this a hundred percent. Uh, and then that's kind of their vision and then it's just a long time until they end up getting that. So that's interesting. I think it's interesting to hear different ways people approach that. Sure. Excellent. Well, what about, um, let's talk about like management and stuff there. You mentioned, um, how do you actually, when we talk about like an engineering team and the performance of those teams, I'm interested to hear how you think about the, like, measuring that performance, because it's some, it's, it's something that's perhaps hard to do. Like you could, there's kind of maybe bad metrics, like lines of code or something like that, where it's not really reflective of the actual work that's being done. Like how does, how does that process work, um, for yourself? Do you have any ways you think about, uh, tackling that.

Brendan Humphreys: 9:32

Yeah, it is a, it's a really tricky thing in engineering. The ultimate measure is are teams delivering on their goals? Are they setting good goals? And are they able to break those goals down into milestones? And then are they able to deliver on those milestones, uh, in a, in a timely fashion? So we, we really try to look at the output of teams and individuals. Um, we don't want that, that output to come at a personal cost though, for those teams. So we, we, we kind of talk about sustainable urgency. We want teams to go fast, but only as fast as, uh, they can while maintaining healthy work life balance and, you know, a sustainable work culture for the long term, you gave that example of measuring. Various development metrics. And that is a really, um, dangerous road to go down. Um, we, we talk about good heart's law at, at Canver quite a bit. Uh, we are striving to be a data driven company, but in, in being a data driven company, we want to always be mindful of good heart's law, which is basically saying that as soon as you start measuring something via a particular metric, that metric tends to tends to lose its value is a good way of measuring anything. It's also really important to remember that. If you are totally focused on metrics, then there's a risk of focusing on things that you can easily measure. And there's a whole lot of really important things that are not easy to measure. Uh, so we just have to keep that in mind when we're, when we are kind of constructing, uh, success measures for teams and ultimately it's about delivery and that sustainable delivery. So we look for that track record of delivery at individuals and teams, and we look for the health and wellbeing of the team to make sure that the team is, is happy in, in delivering.

James Fricker: 11:30

Hmm.

Brendan Humphreys: 11:30

Um, yeah. That's it's look, we could talk

James Fricker: 11:33

Yeah.

Brendan Humphreys: 11:34

on that. You know, your example of measuring commits, I've literally seen. I've seen, I've seen teams that are, that, you know, there's a leaderboard of, you know, the, the top committers and it, and it, it drives perverse behaviors. You know, people figure out how to create commits or how to break their changes into smaller commits. So they write up the leaderboard and, you know, we, so you've really gotta be careful. Uh, it also sends a message when you, when you focused on those, um, uh, code oriented metrics, whatever they are, that all of the other activities that are essential in running a team, aren't as important. You know, we've got for engineering managers, there's a lot of work that goes into expectation management of the team, running the cadences of the team, uh, discussing and reviewing technical approaches and all of that's much harder to measure. So if you're focused on these hard kind of code oriented metrics, you can actually send the message that this other vital work isn't as important. And that's, that's very dangerous.

James Fricker: 12:35

Yeah, no, it's, it's an interesting take there. I liked the, um, you know, the urgency consistent urgency, I think, um, something like that, but I think that's a great way of doing it. Right. Um,

Brendan Humphreys: 12:47

Yeah, sustainable urgency

James Fricker: 12:49

that's right. Gotcha.

Brendan Humphreys: 12:50

yeah. The time that we

James Fricker: 12:52

no, very good. Um, what do you think, like a lot of, lot of talk there about like engineering managers and, and things, what do you think are some traits that make effective managers in your experience?

Brendan Humphreys: 13:04

mm-hmm look our best frontline managers, uh, tend to be those who have some recent lived experience on the tools. In other words, there've been individual contributors in the recent past, and they've kind of stepped into engineering management. I think that gives them, uh, a high degree of empathy with the engineers that they are. Managing, we do expect our engineering managers to be technical contributors. Um, usually that's through technical direction through reviewing and vetting technical designs. Sometimes it's through direct technical contribution, but engineering managers, uh, are gonna be time pause so that that's, um, I guess the exception, not the norm. Um, it actually cuts both ways too, that, you know, it's great for, even if you're on the build or what we call the build track, uh, the individual contribution track in your career. It's quite useful. I think to spend some time being an engineering manager and understand it's very easy when you're an individual contributor to have your headphones on and to think of the manager, you know, the pointy headed boss, um, Somewhat dismissively. But when you, when you step into that pilot seat, uh, you get a real appreciation for the pressures there under, uh, for the challenges that they face, which are quite intellectual challenges often. And that rounds you out as an individual contributor, you might end up back on the individual contribution track. And at Canberra, we allow you to kind of pendulum back and forth, uh, quite deliberately, uh, but it gives you that, that appreciation. So, so you, you mentioned, I, I kind of went off on a philosophical tangent there, but you mentioned like, what are the skills we look for? Um, certainly it's that technical pros. Like we wanna see, um, people who have technical competency in, in engineering management, but we, we wanna see some other, um, organizational skills. So the ability to understand a, a bigger goal, be able to break it down into milestones and tasks and then guide a team. And you. Basically leader team through the execution of those milestones and tasks. And that's, that could be quite a challenging, uh, skill to learn. It is a skill though that you can learn it. Um, and then finally, uh, I guess engineering managers need to be able to set clear expectations. They need to be able to communicate explicitly to, to teams, what is expected of them, and then be able to hold those teams and individuals accountable to those expectations, which again is, that's a skill that you can learn. It's not, um, it's something that I think a lot of engineers struggle with because, uh, uh, they're not, it can be, it can, it can feel like a, quite a Frank and uncomfortable conversation, but, um, it's actually a skill that you can learn.

James Fricker: 15:55

Mm. How like, is that something that you had to learn and, and like, how did you go about like, if, sorry, how did you

Brendan Humphreys: 16:02

Oh, absolutely. I, I think that, um, uh, you know, a mistake that, um, that first time engineering managers make, uh, is, and, and, and it often gets touted as a, kind of a, uh, a leadership principle of kind of leading by example. But leading by example has real limitations. You know, do, as I do, uh, only works to some extent, uh, and it can a actually be an anti for an engineering manager, particularly one who's kind of transitioned from individual contribution to engineering management, where they end up just doing a lot of work. And it's not really, uh, clear to, uh, the team that, that they there's an example being set. So you've gotta kind of step outside of that a little bit. And, um, instead of kind of implicitly setting expectations by working really hard and expecting other people to follow, um, you've really gotta be explicit to say, okay, let's talk about the expectations of the role you, you have this set of tasks. Um, I'm here to. Uh, and, and really laying out what your expectations are quite explicitly. And that gives actually your direct reports, a lot of psychological safety. If they understand what's expected of them, then that's half the battle in them, uh, meeting the, the performance requirements of the job.

James Fricker: 17:32

Yeah, no, that's interesting. I think the, the psychological safety in building that into teams is, is obviously like quite a, an important thing to have, um, make sure that people are kind of, sort of comfortable and able. Think and say things that they are thinking you know, and, you know, being, being comfortable and able to say them very important. Um, perhaps we can switch from like management now to like an individual contributor or an engineer. Um, there's this phrase of a 10 X engineer, uh, someone that is able to do more and contribute like 10 times more than sort of a standard engineer. I wonder if you've seen people like that. And if so, what kind of things that they tend to do better than, um, perhaps have not, not a 10 X engineer.

Brendan Humphreys: 18:26

Yeah, look it's that phrase is, um, I think it got its origin from some research. I, I don't quote me, but I, I think it was an IBM, uh, research project from the, maybe even from the, from the 1980s. Um, look, it's undoubtedly true that there are individuals, you know, there's a wide degree of output in, in individuals, in teams and you do see, uh, the odd engineer who is capable of, you know, an order of magnitude more output than a, than a competent engineer. Um, It's actually a really, really difficult thing to manage on a team though. Uh, it can set up all sorts of really unhealthy dynamics. If that individual is screaming ahead of the team, uh, it, it, it, it destabilizes the team because if it's not managed well, because that individual they're so far ahead of the team, they tend to be, uh, producing a lot of work that the, the rest of the team has to comprehend to be able to, to build on top of, or to work with. Uh, and so that, that creates this kind of review burden for the rest of the team, uh, that they have, they're constantly playing catch up to the sheer quantity of work that this individual is producing. And, um, As a consequence work work tends to back up behind these individuals. Um, because they're the only people who know how the system works, they built most of it. And, uh, that's that's really can, can lead to some quite toxic situations. So, uh, we actually think that's a bit of a pathology at Canberra. We, we do recognize these high output individuals, but what we value in, in, in that high output is someone who can uplift people around them. It's so it's not the they're still individual contributors, but they take teams or groups of people along for the journey. So they're not only, uh, brilliant. Individual contributors, but they're also excellent at mentoring, at educating, at directing others at quickly unblocking teams. And these, these people are worth their wedding gold. Uh, they're the people who bring their, their teams along. They lift everyone around them, uh, to, to a higher level of execution through that technical communication through technical teaching. And they're the ones that we really try to select for and, and try to, um, reward at Canberra rather than that first category of the, kind of like the person with the headphones on that's just out at there's just smashing code out. Uh, cuz that's, that's quite a dangerous, um, that's a very hard thing for a team to manage in the long term.

James Fricker: 21:12

Yeah. Wow. That's a pretty good answer, I think. Yeah, definitely. Um, yeah, it's a great point. I don't feel I can see that happening. Um, but it's, it's I agree. It's, that's the sort of person that you want in the team is someone that's gonna like bring the team up with them rather than just like, almost bring the team down, probably if they're just going, going, um, one direction by themselves. Mm.

Brendan Humphreys: 21:38

Yeah. Now our, our career track, you know, we have an individual contribution career track, and it's very much, uh, it's very explicit in that, that as you rise in that track, the expectation is that you are spending more and more time sharing your knowledge and being a multiplier. So being a force multiplier, rather than being the individual who is just smashing out the, the code.

James Fricker: 22:00

Yeah, definitely. Well, you were an, an individual contributor for a while. Like you mentioned, how does, like, I have a question about sort of upskilling and, and education. Cause I think there's a lot of education now around like going from someone that doesn't know any code to like knows are a little bit or know some, but then once you kind of get to the, the point where you are senior engineer, perhaps then the sort of learning, it's not like you can just take a course and really, and then become, like, you know, someone that's really specialized in and really good. So I wonder if yourself, how do, how have you thought about sort of upskilling. And if you are going down, the individual contributed track, like getting to the, going from sort of senior to then like really sort of almost pushing the field forward, perhaps in some ways, um, like how do you think about that?

Brendan Humphreys: 22:53

There's I, yeah, look, it's it, it depends on your individual learning style. For me, I learn through, through doing like it's, I can read a textbook, um, but, um, uh, it stays fairly theoretical for me until I'm kind of, you know, got my hands dirty with the, with the technology. So, you know, I like to be, I like to be hands on in learning other people can, uh, absorb a lot, uh, directly from theory and then apply it. Um, there's no shortcuts here in getting to that, uh, those upper echelons, you know, becoming an, you know, the ultimate is, you know, some kind of industry expert you've really just gotta put the hours and hours and hours of, of practice in and, you know, it helps to, to really enjoy what you're doing to get, um, a lot of energy out of doing it. Um, I think it's a. It's also good in an individual contribution career to mix up the problem spaces to, because, you know, we have engineers who interview with us that, you know, that they've got senior engineer in their title. They've been, uh, you know, that maybe they have, you know, five, seven years experience, but when you get them into an interview setting, what you discover is they've been solving the same problem over and over again for a long time. Uh, and so they haven't been able to broaden their, their technical thinking. They haven't been able to bra, um, they haven't been able to, uh, build real depth because they haven't been challenged. They've been in a kind of a comfort zone solving that same, same kind of problem domain over and over again. So varying the problem domains, um, uh, finding, finding the ways to go deep. Um, I think that they're the keys and, and just spending the hours doing it. So you kind of wanna, you hope that you, you love

James Fricker: 24:51

Yeah.

Brendan Humphreys: 24:51

You just doing the work to, to, to

James Fricker: 24:56

yeah, no, no, of course. I think it's a great point. Um, and an interesting one as well, cause yeah, I think like, I think at the top of every field nearly like, it's, you'd be surprised if someone's there and it doesn't really really love what they do. I think, uh, like. To sort of get to that stage. You can't need that's. When was a pre prerequisite, I think, um, love to sort of specialize our chat around engineering it down into sort of the junior level, um, and junior engineers. Um, I wonder what, um, say there's a bunch of new engineers joining Canada, they're all juniors. What are some mistakes that you've seen junior engineers make, uh, int like perhaps they join the company and they're like super keen to like go and do a whole bunch of stuff, learn heaps. Um, but perhaps they make a couple of mistakes and perhaps they don't really get as far as they otherwise should have. I wonder if there's any mistakes that you've seen junior engineers make.

Brendan Humphreys: 25:57

Hmm. Um, look, I think the, the biggest mistake I see is, uh, um, people forgetting, um, the, the people not taking a first principle's approach to, to learning and a little bit being a little bit too technology focused. So they come in they've they've learned maybe on the side, they've learned. Some cool tools or technologies they wanna apply them. And, uh, there's a bit of a, kind of a shiny bubble effect of kind of like, oh, I learn, react. And, um, and I, I really wanna build, build stuff in react, uh, or I've learned some other shiny tool technique process, whatever it is. Um, one of the, one of the things we really drum into our, our grad engineers is taking the time to build context, like deeply understand the context of the systems that you're building on top of, try to break that understanding down into first principles and then be able to reason about. Whatever proposal you have from first principles, uh, and then test that idea carefully. Um, first, first yourself, do some second order thinking around what you are, the, the solution that you're proposing, uh, rather than just kind of, uh, having that blinkered vision of like I have, I, I know tool X and therefore I will apply it to problem domain, um, taking the time to really break the problem down, to understand the context of the system, uh, to build that domain knowledge, uh, and then being really kind of hyper rational about, well, what's the best solution, uh, that puts you in good stead. That's a, that's a hard skill to learn though, cuz people just want to code, right. They want to just build stuff. Uh, but it's a bit of an anti patent in an engineering or to kind of, uh, To be in that kind of mode of unconstrained ideation where you're just kind of like, oh, what if we did this? And what if we did that? And my answer is always, well, you tell me what, what if we did that? Like, you'd spend the time to figure it out. Don't be burdening the senior engineers around you in answering those questions for you. You've got the, the ability to reason about this yourself. And if you can demonstrate building the understanding of the, and the context of the system that you're working with and to answer those questions, uh, then that's really valuable for, for your team, that you are able to do that discipline thinking.

James Fricker: 28:37

Yeah. That's that's interesting.

Brendan Humphreys: 28:39

The other thing I'd add is that, you know, it's a little bit more of the same, but the shiny bubble syndrome is

James Fricker: 28:44

Mm, Mmm.

Brendan Humphreys: 28:45

in that, uh, every, every few years along comes some particular technology, which is presented either by industry thought leaders or by vendors, masquerading as industry thought leaders as, as the, the silver bullet. Um, and you know, it's, it's really easy for grads to be, um, to become enamored, uh, with that to, to kind of almost worship at the alter of the technology, rather than kind of taking a bit more of a clear eye view of like, well, how does this technology, what's the value of this technology? How does it compare to its um, To its, uh, to prior art. And how is it, how is it actually directly applicable to the problem domain? I have, you know, the one that's thankfully it seems to be losing its luster a little bit, but blockchain is something we hear a lot about at the moment. But if you, if you really think hard about blockchain, it's, it's kind of hard to find practical applications for the technology. It's a very cool tech. It's very, it's very exciting when you think about it's a great intellectual exercise to think about it, but it's practical applications that are somewhat limited.

James Fricker: 30:00

Yeah, I agree. I think it's, it, it probably in the last, maybe even this year or, or perhaps longer, I think it's definitely lost a lit little bit of the shine that it perhaps had maybe four, three or four years ago. like, like,

Brendan Humphreys: 30:16

I mean, like it's not just, I'm not singling out blockchain because before it, there were, you know, there were other trends in technology that. You know, it used to be no SQL and, and, and people rushed into no SQL without really understanding the, the trade offs, uh, that need to be taken before that it was XML, XML was gonna solve everything. And, um, you know, I remember the group think that is that that can emerge around these, uh, shiny fashionable technologies is very, very dangerous and, but very hard to resist

James Fricker: 30:49

Yeah, definitely. Well, how do you think about like when a new tool, like, like something like blockchain or new SQL or whatever comes along, is there a way that you think about differentiating? What is like a new shiny thing versus something that is actually a genuine breakthrough and like, perhaps we should consider adopting this cuz like it is actually quite cool. Like, is there any way you sort of think about those.

Brendan Humphreys: 31:13

Yeah, look, it's, it's a tough, that's a really tough one because obviously, um, in amongst all of the, the new shiny fluffy ideas, there's some really good ones that, that, um, you know, three years down the track, if you had hindsight, you would've adopted early. So how do you pick those winners? Well, look, we try to create space for engineers to tinker and to play with new technologies. Um, that's, there's a, there's a balancing act there because we can't have them in production. So we, we have, you know, I'm a big fan of the, um, the boring technology club, you know, mature technologies, uh, they have wards, but the, those wart are well understood. We understand the performance profiles and the deficiencies of those technologies. And we can engineer around them, um, bleeding edge tech, You know, it's called bleeding edge for a reason you bleed when, when you adopt it. So what we tend to do, we have a fairly high bar for, for technology adoption at Canberra. Um, we wanna see, uh, a clear eye rationale for why a particular technology is a net benefit to us. We also want to try always to not, uh, unnecessarily expand the surface area of technologies that we're using. We try to keep the set of technologies we're using relatively small, uh, that aids in mobility of engineers within the organization, because there's not a huge diversity in technology that's used across the org. It helps even. In the day to day, uh, engineering, uh, comprehension, you know, the cognitive cost to engineers is lower. If you have a, a, a smaller set of technologies you're using, uh, and you have familiar patterns that are being used across, uh, to, to solve problems in a similar way, the engineers can encounter, uh, different components in the, in the system and recognize and quickly understand how they work because they're in a familiar technology using familiar patterns. Um, so in cer in, in service of that kind of keeping the set of technology small, if you've got some new, uh, technology that you think will uplift us, we certainly want to hear about it. Uh, but the burden of proof is high. So we want to understand. What is the total cost of adoption. And in saying that we, we really want to try and aim for a step change where we, we are not kind of forking our technology solution. We don't end up with an old way and a new way we end up with just one way and that one way maybe the new way. Um, but. We wanna see that total cost of adoption be factored in, uh, because you know, if you fork and you end up with two ways of solving a particular problem, then in a year's time, there may be a, yet another new way. And then you fork again, and now you've got four ways or three, you know, you, you keep expanding and then you end up with this explosion of, uh, complexity as combinatorial, explosion of different technologies and, and solutions. And that's, that's very D that's a very dangerous, it's a, that's an emergent complexity that becomes very, very difficult to manage and is a real impediment to, uh, maintaining an evolving and building on top of the systems that, that, uh, that you're building.

James Fricker: 34:43

Yeah, that's really interesting. That's really interesting to hear that. Um, I, I like that point about like keeping the set of tech that you use, uh, to a minimum. And then that means like engineers can kind of move around more easily. I think that's a great point. Um, but what do you, what do you think about, um, Like specialization and like generalization, um, is there, like, what would you say to someone perhaps that is like, like starting their career even is I guess at any stage, um, is there like a preference that you'd have for either of those in terms of learning a whole bunch of things, perhaps it's like some new and then old stuff or specializing into certain things. Um, like, like, and perhaps like when would you consider doing either of those? If there, if there was a difference.

Brendan Humphreys: 35:34

Yeah, we look, we like our engineers to specialize. Um, but in saying that we subscribe to, you probably have heard the term a T-shaped engineer. So we like engineers to have a specialty where they, where they spend, you know, potentially years honing craft and building deep knowledge in a particular specialty. But while they're doing that, we want them to be, uh, aware and building knowledge of adjacent, um, uh, technologies, uh, adjacent skill sets, uh, and then hopefully building some depth in those. So that's, that's where the T shape comes in. You kind of broad, you get, you build out this broad knowledge base, but then you go deep on one or two, uh, specialties, um, in a career that's, you know, might span 30 years. You can probably expect to go deep on, on several. Um, but it. To, to the, the point I made previously going deep, um, usually requires a lot of execution, like a lot of, a lot of time. And so, you know, you've gotta, you've gotta choose carefully on what you go deep on. And again, to my point, you know, the shiny, shiny stuff, uh, sometimes it's, it's not the, the shiny, shiny fashionable technology, uh, that I would choose you, try and try and pick, uh, something that's a little bit more stable, has the evidence of execution and, and success around it. Um, you know, I'd be very worried, uh, as an engineer, um, you know, doing a, doing a degree in blockchain that would, that would scare me right now. Cause I'm not sure that that's gonna be particularly particularly applicable

James Fricker: 37:21

Yeah, definitely. I feel like, yeah, with the specialization, like you said, you've gotta be perhaps a little bit careful that you don't specialize in a, in a trend rather than something that's gonna be around for the long term.

Brendan Humphreys: 37:32

Yeah, so you gotta try and pick the more fundamental technologies. Um, and you, you know, you've gotta be looking at where the industry's going and, you know, look at companies like, like, like Canva, like Google, like Facebook and see what technology stacks they're building on. Uh, and you know, that's, they, they're probably a pretty good sign that those technology stacks are, are in it for the long haul. And, you know, some of those technology stacks are gonna be pretty boring. Like we, we love Java cos you know, Java's not exactly a fashionable language these days, but most of our back ends are built in Java. And uh, so I still think it's a good language to get a grounding in.

James Fricker: 38:13

Yeah, definitely. Oh, that's, that's pretty cool. I, I think that's, it's an interesting, um, thing to think about. Definitely appreciate your insights there. Um, what, what do you, when you're looking to sort of bring engineers into the organization, um, what, what are, or perhaps amongst engineers generally when they go and do well at can, let's say, um, what do you think are some traits that are undervalued by the marketplace or things that you think, um, you personally value, but are undervalued or like the market kind of doesn't appreciate as much as you think they should.

Brendan Humphreys: 38:52

Well, we mentioned critical thinking before, and I, I do think that's an undervalued skill. Uh, you know, we see a lot of grads coming in, very technological, uh, a very technological focus. They're very excited about their technical skills and the knowledge that they have, but I wanna see critical thinking applied, uh, Real engineering is, is problem solving. So if you get good at problem solving, if you develop your critical thinking techniques, uh, you know, if you, if you develop your skills in how to reason about problems from first principles, uh, how to do higher order thinking, understanding logical, fallacies, et cetera. I think they're, they're great skills to have, and they're pretty, pretty undervalued. Um, another, another one I'd list is, is more on the, what, what is traditionally thought of as soft skills, which is, you know, empathy in engineering is a, is a really important and underrated skill. And it's a, when you mention the word empathy, people often think of kind of like a warm, fuzzy, emotional, uh, uh, innate trait, but really it it's. It's not that at all, it's actually a skill that you can hone. And it, it's just a skill of seeing, uh, seeing the world from, from other other's perspectives and deeply understanding other people's perspectives. And, you know, engineering is, and probably always will be a highly collaborative exercise. And so being able to see, uh, a problem from different viewpoints and to really, uh, to deeply build that skill of being able to do that is highly valuable in unlocking collaboration in teams. And there's, you know, there's really practical things that you can practice to, to achieve that. One of the great, um, Uh, techniques that, that I try and champion in, in young engineers is the unfortunately named, uh, steel Manning technique, which I, I'm not sure if you've, you've heard of, but it, you know, it's the opposite of straw Manning, straw Manning be where you replace, you see in a technical discussion or any discussion, um, you see the discussion as an argument to be won. You interpret someone else's argument, uh, in an inferior form, and then you shoot that inferior form down that straw Maning. But steel Manning is doing the exact opposite where you see any technical discussion for what it is. People bringing diverse perspectives and viewpoints into that kind of collaborative problem solving space. And you're able to take a step back from your own position. Really deeply understand someone else's position, uh, and then understand it to the point where you can argue it for them and what you find when you can do that. Uh, one of two things can, one of many things can happen, but what, what can often happen is by really stepping into someone else's shoes, arguing their point for them, and you have to do that genuinely. You can actually change your mind. You can change your position. You can, you can, uh, convince yourself of their position. And that can be a really powerful way, um, of unblocking teams, where there are competing views of how to solve a particular problem. Uh, you can also, you know, uh, even if you think you are still right, you can be. By demonstrating that empathy with, uh, with people who disagree with you. That's a very disarming way to collaborate that disarms your, the people who, uh, you're collaborating with. And it creates that constructive environment where you can move forward.

James Fricker: 42:43

Yeah, that's cool. I like that a lot. Yeah. I think that's super important. It's a, it's a much, it's, it's much nicer to deal with someone that is like, can see the way that you are thinking about it and like is, is coming at it in a constructive way. Uh, versus someone that's looking to sort of shoot the way shoot down the way that you are looking at solving it. Um, definitely. I think that's, that's super cool. Um, I like that a lot, um, for yourself, I wanna sort of ask a couple of questions more generally about yourself and, and your career. Um, so when, when you, uh, uh, you'd worked a few software jobs and you, um, Founded co-founded the startup, seko uh, and you had a couple of guys there that you sort of co-founded that with, um, how, like how formative was that experience, um, yourself and in terms of like creating a, a product, um, you know, going out and doing things and, uh, without the sort of you almost like joining a startup in some sense, um, like, yeah. How formative was that experience for yourself in your engineering journey?

Brendan Humphreys: 43:54

Uh, very formative. Um, it, you know, having your own company, uh, it, it, it definitely removes the safety net. You know, there's no, there's no one to do the thing, but you, you know, there's a company with four of us. Uh, there's, there's lots of work to be done and it's not all coding. Um, so you get an appreciation for, for many aspects of running a business, not just, not just the engineering, uh, and. The level of personal commitment is huge, right? You just have to commit, uh, if you don't put the work in, if you don't do the work, no one else is gonna do it. And so you've gotta be very committed. We were very, very driven. Uh, we called ourselves a lifestyle company, um, in that we kind of told ourselves that we could, you know, we could take time off and we can go at leisurely pace. But of course, that, that doesn't really happen. You tend to, to live and breathe, uh, company. Uh, and it's it. You, I guess that's a trap as well. You've gotta be careful, but it no very, very formative, uh, experience, very eyeopening, uh, in all aspects of, of software delivery, you know, not just the writing.

James Fricker: 45:08

Yeah. Is there like what, what parts. That journey would you say have been most beneficial and perhaps most relevant into what you do today? Is there anything that you still like, anything that still has been really, uh, really like useful or, or a useful experience perhaps to go through, um, in, in that startup situation?

Brendan Humphreys: 45:34

Um, I it's it's I think it's, it was useful in understanding what it means to be an owner, like what it means, like you've really got skin in the game. So if you, if you, it gives you agency and your, and underst. You understand what it means to have agency and to create agency. And yes, one of the things that in any organization is a struggle. You know, the bystander effect that you kind of think, well, you come in, you're doing the thing. Uh, if you don't do it right, someone else has got it. Or if there's a decision to be made, you put it off because someone else will make the decision. And, um, when you own your own company and there's no safety net, it gives you that agency. And that focus that you've got this, and if you don't have this, then no one else does. And I think if you can carry that forward into particularly smaller companies, but you know, even larger ones, that sense of agency is really important. You know, the, the. The ability to kind of grab hold of something and own it entirely. And that's not necessarily a system or a component could be a process, could be decision making around, uh, a structure or whatever. Uh, if you can show that you can grab hold of something and then drive it to completion, uh, with that agency, then that's really, really powerful.

James Fricker: 46:57

Yeah. I, I like that a lot. It's the, uh, extreme ownership perhaps, uh, responsive taking responsibility, those kinds of things. I think that's a, a good trait. Like, um, no matter where you are in the organization, too, whether you are someone that's more senior and does kind of have the responsibility by default, or if you, even, if you are more junior and taking responsibility of your little piece of the puzzle, I think, I think that's a, a good, great mindset to have definitely, um,

Brendan Humphreys: 47:30

Um,

James Fricker: 47:30

perhaps thinking about yourself, um, as well, if we think about folks that are perhaps early in their career and want and, and have look at someone like yourself and say, man, I really wanna be the CTO, or I want to be the head of engineering. Um, is there anything that you would say that they like any advice, perhaps common advice that you think they should ignore when it comes to, uh, careers and things that are commonly, like commonly told to, to people at that stage?

Brendan Humphreys: 48:05

Well, I mean, I, I think that, uh, you know, for me, I'll talk about personally, what's been my career philosophy. Uh, I've always tried to work at companies with technology at their, at their center. Um, and that's, that's been important for me. Uh, I've also always tried to stay as technical as possible for as long as possible. Uh, just to build that, that deep technical expertise. I didn't have a career destination in mind. I don't fault those people that do, but for me, it was just kind of like just doing what I enjoyed. Uh, and, you know, as I said, I've been quite lucky in, in where I've ended up. Um, but you know, the, the side effect of staying technical for a long time is that you do see, you get exposed to a wide variety of team cultures, a wide variety of problem domains and a wide variety of solutions. And so that, that technical depth, uh, gives you a good grounding to go into engineering management at some point, if you, if you so choose, we do have, uh, and I have great friends who, you know, are 25, 30 years as, as technical contributors, as individual contributors. And that's a, a valid career path as well. Um, but yeah, look, that's, that's worked for me, uh, survivor bias, uh,

James Fricker: 49:29

Yeah. Nice. Well, I'd love to perhaps talk about a time. Uh, If there are any that you were maybe something more unlucky. And, and my question is, has there been a time in your career that you failed at something or something didn't go to plan? Uh, but at, at the time it felt like it was sort of going wrong, but it later turned out to work out well. And perhaps later on it was something that was, yeah, it worked out well. Is there anything there that, that comes to mind?

Brendan Humphreys: 50:06

Well, I, I graduated from uni in 1997 and the, the first tech bubble was just forming. And, you know, I did a, an honors thesis in distributed, uh, web indexing, um, before Google existed. And I still have regrets to this day. Um, not kind of. Uh, per grab, grabbing that opportunity in, in 97 when I graduated and kind of going and, and maybe taking a pun and moving to the valley and, and joining, uh, joining in on, on some of that action, uh, as the, as the.com bubble, uh, formed, you know, there's a, obviously a lot of horror stories with companies that crashed and burned, but then there were also companies like Google that emerged at that time and are now household names. And if I was, you know, looking back, I would've, I would've pushed myself a little bit more to kind of step outside my comfort zone and, you know, I'd built up some, some pretty at the time, reasonably unique knowledge in thinking about how you index the web and in a distributed way. And, and, uh, that was all very novel and, and pretty hot, um, hot topic. And, uh, and I just. Went into a much more safe, uh, uh, safe engineering job at a telecommunications company. And maybe I, I should have, uh, pushed myself a bit harder to, to, to go and, uh, you know, try my luck at, at Silicon valley. No, don't have too many regrets in that regard, obviously, cuz it's kind of things have

James Fricker: 51:45

Yeah, definitely, well, that's definitely something that perhaps didn't go, uh, so well at the time, but has ended up working out quite well. I would say, um, I wonder like when it comes to sort of engineering and, and your career as well, what has been, uh, saying that you, um, like has been your most worthwhile investment? Uh, whether it's an in. Of time, like maybe it's a course you did or something that you participated in or, um, or whether it's something that you invested with money or like maybe it's a, something that you purchased or a thing that you attended that you paid for. Um, is there anything there that you think has was, was perhaps like really crucial in, in getting you to where you are today?

Brendan Humphreys: 52:35

Uh, so look, I've always enjoyed building software on the side. So I I've invested in, in doing that for myself, just, just to, and, and I haven't approached it as a chore. It's just a passion. Um, I, I don't think I could do it if I, if I felt like it was a, a chore to brown to, to broaden my, my skillset. But, um, I've just enjoyed tinking tinkering with, with software and, and hardware. Um, and I think that's been enormously valuable, you know, the company Sanur. Um, got its first income from a side project that I was just working on, uh, that we then turned into commercial product. Um, so that's that worked really, really well for me and I, and I, I also really, and maybe I, I go overboard on this, but I really try to focus on having the discipline to see those projects through, to completion. It's very easy to kind of start side projects, but it's much harder to see them through, to some logical, uh, conclusion. And in saying that, you know, I, I fail more often than not, you know, I've got, I've got hundreds of, of projects that, you know, have progressed very little. Uh, but it's still something that I really try to do. Um, in saying that I don't want to, you know, there's a, I, I wanna acknowledge that. Not everyone has that opportunity. Um, For whatever reason, their own personal circumstances means it's difficult. So I don't wanna set that up as a kind of a prerequisite, um, you know, certainly, you know, grads or, or engineers that come to us. Uh, they have all sorts of different life experiences and we don't expect to see that kind of tinkering or, or, or side projects or, you know, open source contribution. Uh, it's great when we do, but it's certainly not a prerequisite.

James Fricker: 54:23

Yeah, that's cool. I think, uh, yeah, it's interesting. Like the side projects, I think there's many a story of those. someone working on something on the side that ends up becoming something quite cool. So, um, that's really exciting. Um, I've got one more question for you, Brendan. Uh, and that's the question I ask all the guests that come on the show, and that is, um, advice for young people that have just graduated university, perhaps young engineers. In this case, like what advice would you give someone that's fresh out of university and wants to become a great engineer?

Brendan Humphreys: 55:04

Uh, wow. Okay. Well look, I, I think it's, uh, it's definitely the case that you want to find, um, uh, mature engineering orgs to join, where you can learn from exceptional individuals. So you, you wanna find that the engineering cultures, uh, in, in the mature engineering teams, uh, where you've got these, um, uh, mentors, uh, informal or otherwise that can teach you, uh, the art of, of software engineering and you, you can, you can learn from so, and, you know, we certainly deliberately. Set out to create a culture like that at Canva. Um, but you know, like the, a lot of the big companies like Google, Amazon, uh, Microsoft, apple, they will all have that. And I think that's, you know, that's something to definitely aim for. I think that there is a, a risk for grads in, um, and I'm not saying it's, don't do it, but I think there's just some risks in, in maybe joining smaller outfits where, uh, you can very quickly be, uh, the most knowledgeable and experienced person in the room. And, and that can be dangerous if you, if you just fresh outta uni, you know, it can work. It's just a risk. Um, I, I personally think that it's better to join somewhere where you've got those mentors, uh, that, that help you see what great looks like and can help you get there.

James Fricker: 56:33

Yeah, join a company like Canva I think. Yeah. yeah, amazing. Yeah. Yeah. Well, thanks so much for coming on the show today, Brendan. I wonder if people are listening and they wanna find out more about yourself or perhaps connect with you. Is there any, um, place that they should go and find out more

Brendan Humphreys: 56:56

Uh, I am on Twitter. I tweet very, very infrequently. Um, but if people wanted to find me I'm Brenda, H B R E N D a N H on Twitter. I'm also on LinkedIn. Uh, although I get a lot of LinkedIn requests, so I may not be, um, uh, I may not reply, but, uh, but

James Fricker: 57:15

fantastic? Well, yeah. Thanks so much for coming on the show today. Appreciate you having along.

Brendan Humphreys: 57:23

No worries, James. I've enjoyed the chat.

James: 57:32

thanks for listening to this episode I hope you enjoyed it as much as I did. If you want to get my takeaways, the things that I learned from this episode, please go to graduate theory.com/subscribe, where you can get my takeaways and all the information about each episode, straight to your inbox. Thanks so much for listening again today, and we're looking forward to seeing you next week.