Tech Titans: Your Team Can't Trust You If They Can't Predict You with Noah Cantor

(Intro Narrator at 00:00:00) Today, we're talking to Francisco Trandade, vice president of software engineering at Braze, about his take on AI killing code review. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:17) Well, this is great. Where are you calling in from?

(Francisco Trandade at 00:00:20) I'm actually in Brazil. I'm in São Paulo this week. I'm usually based in New York, but I'm here visiting the office, and I have a conference tomorrow.

(Joel Beasley at 00:00:29) Are you speaking at the conference?

(Francisco Trandade at 00:00:31) I'm speaking at the conference, yes.

(Joel Beasley at 00:00:33) What are you talking about?

(Francisco Trandade at 00:00:34) Going a bit on my book. I think the big kind of frame of thinking here is that the role of engineering management is this role has evolved. It's kind of new and it's kind of evolved through time. I think we frame it as disjointed. We talk about people, technology, and process often, and we think about those things as disjointed or separate concerns. My perspective, and a perspective I think centered on my experience, is that the role becomes much more simple and effective if you look at your team as a system, as a group of people working together and trying to achieve a result. And you have different concerns around the product side of what you're building, the people side—are they effectively having a good experience?—and the technology side—how are you building that? But all of those are interconnected. For example, how you plan a project on the product side affects how engineers end up building it and the experience they have doing that. How you manage your people affects that. So the more you can think holistically about the role of management or leadership, I think the easier it becomes and the better you can focus and use your time.

(Joel Beasley at 00:01:50) Yeah. You had a pretty popular article on Medium about will humans still review code. What did you learn from writing that?

(Francisco Trandade at 00:01:58) Yeah, that was an interesting, instant experience as well, and I want to continue that article. But I think it was kind of also the result of—I mean, we've all been experiencing this shift in AI in this year. Models became much better, and I think we came back from the new year of thinking about, okay, realizing, okay, this can actually—this is actually moving faster than a lot of people expected. And I think I started experiencing at work, also talking to people and seeing kind of this discussion happening in the industry that's like, as AI became kind of the tool of choice to writing code and kind of is developing a lot of the code that's happening nowadays, the bottleneck has quickly shifted to code reviews. So I think a lot of companies experience the idea of, okay, now reviews are a problem and reviews are the thing that we need to optimize. And so that article was kind of really a summarization of these conversations and kind of getting this understanding of, okay, this seems to be—I talk about three versions of AI so far. I think V0 being last year when we all gave tools to engineers and all engineers had tools, and there was a lot of code being produced, but I don't think we've seen a lot of—a lot of companies haven't seen a lot of the productivity gains, to some extent they have or not meaningful. I think V1 now is what we're going through now, which is companies are trying to optimize processes around AI. Right? So there's, okay, code reviews are a bottleneck. So how do we deal with that? And if product or the planning is becoming a bottleneck, how do we kind of deal with that? And also tooling to kind of optimize specific things. So a lot of companies are deploying agent systems so that engineers can use that directly and do faster bug automation or kind of issue automation so that small things can be solved automatically. I think the big question for me is just can we get to a point—and the big question I think that companies are facing is can we get to a point where humans are out of the loop, at least out of the loop in the way they are right now, which is being kind of this—you need to have a code review to kind of get products out. And I mean, in some companies that is already kind of the situation. I think if you're starting a company now, if you're a startup and you have a small code base, I think everyone knows at this point, yeah, I can effectively do most of it and deliver pretty fast. I think some large companies are also experimenting with that, and I think everyone has heard the Claude CTO podcast saying about how coding is solved and kind of how that's not a problem anymore. But you still have this—in a lot of situations, I think—in a lot of companies like mine or different companies that I work with, that's still not a reality. Right? I think still code reviews are a meaningful part of guaranteeing quality and guaranteeing stability in the technology environment. So I think the question is if we get—and I think the prize at the end of this is meaningful. Right? I think if we get to a point where we can take humans out of the loop actually, and humans still participate in coding, but in a way that's more direct in agents, we're talking about five, 10X gains into how fast we can deliver. Right? But I think that is still, can we get there in a large complex, revenue-driving code base? I think that's the question that I think is interesting. And if we can, I think that'll be a meaningful productivity shift. But I think there's a world that we—and but also requires meaningful investment from companies to get there because I think there's a lot of, how do we actually structure that to structure code bases and structure process to achieve that? But if you don't do that and if you don't believe in it, but you don't invest in it and someone else does it, you're gonna have competitors kind of running much faster than you. And I think that's kind of the—it's an interesting kind of bifurcation, but I think it's a choice that I think companies are gonna start to have is how much they invest in this direction and what is the outcome if they do or they don't.

(Joel Beasley at 00:06:23) Yeah. So the human out of the loop, the code review agent, what do you think about that? You think there's gonna be agents that just do code review? Would that solve it?

(Francisco Trandade at 00:06:32) I think, I mean, and they exist already, and I think it's solved to a meaningful extent. I think, does—do I think it's gonna happen? I think the question is would you trust that if we are a company that has hundreds of thousands of engineers, right, would you then trust to have hundreds and thousands of agents running and committing code and doing code reviews or something at the same time and submitting that and taking that to production? I think that is the question. Right? So I think the code review agent, I think, solves this to some extent. Does it solve it in all cases or in most cases? And I think that that is kind of the more interesting question. Can we run an organization just with that? So kind of that makes a difference. Right?

(Joel Beasley at 00:07:20) Yeah. I think step one, the organic. Right? You just have the system that we had before AI, which is a lot of people. And then you get AI, which will start to make people more efficient, and you can kind of consolidate a little bit. Instead of needing 10 engineers, maybe you only need seven or five or three. But then that technology gets better, and it consolidates all the way down to one. Now you have one person doing the work of a hundred and then a thousand and then 10,000. And I think we're just on this path where everybody, when they're talking about it, they always imagine going from the old way to running a swarm of 10,000, it being completely solved. Whereas reality is it's a bunch of small incremental steps along the way.

(Francisco Trandade at 00:08:08) That is true. I mean, I completely agree. I think the interesting—there's two interesting aspects I would say there is one is the cognitive load of systems product that's always changing. Right? The technology is always changing because I think it's not only the job of the engineer or the builder, I guess. Maybe that includes product and design engineering, the people building products. It's not just executing on something and that something becomes stable forever. Right? It's executing on something and then new requirements show up and then new things happen. And then how do you incorporate that into the existing product in a cohesive way? Right? So, yes, you can probably have an engineer that maybe runs 10,000 agents, but how can they be—how do you guarantee coherence, I guess, as a product in 10,000 agents that are running? I think—and that's, I think, gonna be part of the work in engineering. It's defining harnesses and kind of structure to achieve that. The other aspect I think is interesting is just it's not how do you get there—how do you get from one to a hundred to 10,000 in a greenfield situation, but in a situation where you already have a brownfield code base that probably has, as many code bases are, not ideal and have its quirkiness and a lot of kind of debt in them. And how do you—what do you need to do with that code base with your tooling, with your process to get to the point where 10,000 agents are possible and how long it takes you to do that, I think. Because the path—I think there is a world where the path from where you are right now, which is a large sprawling code base that has a lot of problems to a situation where you have a code base that can support, or a code base and tooling and kind of structure that can support 10,000 agents, that might need humans to take it through. Right? Because the humans who have the comp—that are still the ones with the context right now. And if that's the case, that takes time. And if it takes time, then there is a question when do you start. Right? And when do you start doing that investment? I think that's maybe—I compare a bit in the—I think it's quite different, but because I think this is a more meaningful shift. But I think if you think about the microservices kind of changes that happened maybe 10 years ago, I think a lot of companies invested in microservices and put a lot of effort in achieving that and changing their structure to support this new paradigm of delivery. I mean, there's—we can talk about a lot of them failed. I don't think there's a lot of kind of—some success and failures there. But the gain that we're looking for there was probably, I don't know. In a best case scenario, talking about a 2X gain of your speed of maybe delivery, and that would be a very high success. I think the AI path might be similar to companies that invest to get there. You know, there might be tooling that supports 10,000 agents, but you might need to do something with your code base to achieve that. But the gain that you can get if you get there might be 10X instead of, or 20X instead of 2X. And I think that is—but if you don't start now and someone else does it before you, then someone else is moving 10X faster. I think that's the question. Right?

(Joel Beasley at 00:11:54) Yeah. We've seen a couple of these trends, microservices, agile, all these different—you know, it's funny that you brought up microservices because I was just thinking about it. You said there's some people that have success with it, some people fail with it. I think the people that I've met that failed with it the hardest are the people that just saw it was a cool thing happening, and they saw this was the direction things were blowing in, and then they just jumped on it. They're just like, well, that's what we're doing. We're gonna do microservices. Whereas the people who had success with it, they were having specific situations that required this microservice architecture. And I won't get into the millions of situations that could exist, but they were having these problems. Microservices were solutions to the problems, and therefore, they gained from using this new method. And then it's like the two pizza teams. Somebody will hear Amazon. Oh, we got two pizza. Let's change our whole org for two p—well, it's like maybe your org needs a different situation. And so I find that the people that look outside into the marketplace and just look at whatever is popular and adapt that, they have a higher failure rate, not 100%, but they have a higher failure rate than the people who focus inside. It's like, what does my company need? And that's where the innovation, I think, comes from.

(Francisco Trandade at 00:13:10) For sure. I completely agree. I think going back to the beginning, I think that's how I think that's why I think systems make—that's how I frame things in systems. It's just I think what you're describing for me is just there are companies and groups that would think about the problem and then adopt the principles that exist in, for example, in microservices. The principle is you reduce the code base. You reduce kind of the size of it so that it becomes simpler. You can move faster. But you apply that to a problem that you have, and you apply that with the principles in mind and tooling—principles first, tooling second. And that then leads often to a better result. Whereas if you—and that's thinking about the whole. It's just the whole is how fast you deliver value. Right? So how fast am I delivering value? What are the problems and how do we apply principles to solve it? Principles, tooling to solve it. I think if you just apply the tools, you just effectively—you are thinking about it in parts. Right? You're saying, oh, I have a technology problem, and I'm gonna apply microservices to solve it. And that becomes more often that tooling first, principle second approach that leads to more failures. Right? Because you're not—it's not clear what the problem you're solving. It's not clear for you what the goal is, and then you cannot optimize that approach to something that makes sense and improves things. It becomes a kind of a restrictive implementation. Right?

(Joel Beasley at 00:14:44) It's funny. It takes 20 years to see this.

(Francisco Trandade at 00:14:49) To see these—

(Joel Beasley at 00:14:50) To see these mistakes we make over and over implementing the wrong concept or, you know, what you just described. And then you look back at it, you're like, oh, it's so obvious that you don't do that. But if you go back 20 years in your career, it wasn't so obvious. It was like, oh, this is what we're doing. This is what needs to be done. This is the right thing to do. And so I was always so frustrated, Francisco. When I was younger in my career, I was like, why am I not at that higher level? Why am I not running this? And I realized as I got older and went through it that you have to have a huge network of relationships and experience.

(Joel Beasley at 00:15:23) And those relationships plus that experience is your reputation. And then that's why these people get picked for these great roles. And you know this better than anyone because you've been doing it almost twenty-two, twenty-five years or something like that. And you've gone through all these companies, and now you're at Braze.

(Joel Beasley at 00:15:41) And so can you tell me what Braze does?

(Francisco Trandade at 00:15:44) Yeah. So Braze is a customer engagement platform. So we help enable business to connect to their customers. So delivering personalized cross-channel messaging. Effectively, any company that is communicating with the customers in a digital fashion, I think Braze is the product that helps them do it.

(Francisco Trandade at 00:16:05) And we do that at high scale. So we send billions of messages a day, and so our systems have to be, of course, high scale and reliable and performant. And then I manage a part of the product engineering organization. So effectively, from different areas, from ingestion of data to processing of data and to also part of message sending. So a lot of this high scale, high performance part of the product is under my organization.

(Joel Beasley at 00:16:41) That's very cool. And then you grew your org from 15 people to 100 engineers. And through that, did you meet—I know we got connected through Steven over at Span—but is that how you found Span when you were doing that scale up?

(Francisco Trandade at 00:16:56) Yeah, it was. Actually, Span, we found Span a few years ago, and it was at the beginning of their journey. So they got introduced to us through a relationship, and I was always interested in engineering metrics and how to better frame engineering. I think, across—so with metrics and with data, my usually interesting kind of take is that if you ask an engineering leader where they spend, where they invest on, last year, a lot of them, it's a hard question.

(Francisco Trandade at 00:17:34) A lot of them and us will be like, well, I know we delivered a bunch of features, but I cannot tell you exactly how we spent, how we invested, where it failed or where it succeeded. So I think this idea of using metrics to manage teams is something I've been thinking about for a while. So we were introduced to Span, and Span was earlier in the journey, and we became design partners with them and have been using them and also working with them to just evolve the tooling, which I think has been very useful for us.

(Joel Beasley at 00:18:07) Very cool. And then so what—tell me, like, exactly what they do, like, how you use them within your company.

(Francisco Trandade at 00:18:14) Yeah, definitely. So Span is an engineering data engineering tooling. So they provide—they get data from different sources and they provide you, effectively, insights about that. So we use it at different levels, I think, from the basic engineering metrics.

(Francisco Trandade at 00:18:33) Which is thinking about PRs and code delivery and how fast code is delivered, how fast PRs are reviewed, and how engineers are doing on that. And we use that to—we talk about being a data-informed organization, more data driven, so we use that to kind of inform conversations and inform the thinking around how we manage engineering. We also have then started using them with higher-level perspectives. So one of them is also, with this data they collect, you can track investment, which means, where is your engineering time being spent effectively. So you can look at that and see what you invested on, and that's something we're using in leadership to kind of align effectively, align plans with practice and make sure that we are doing what we expect to be doing.

(Francisco Trandade at 00:19:26) And then also in this, specifically in this AI transition, they've been quite helpful in the sense of, they also, through data, manage, look at AI insights or usage and spend and things that they're informing our strategy there. But also, as these bottlenecks have been moving into different areas of delivery, we're using Span to think about cycle time of issues and PRs and analyze that and actually take action within teams to improve that. So it provides many insights in different areas that I think have been useful for us to manage engineering.

(Joel Beasley at 00:20:06) Mm-hmm. And then you've got this systems thinking as a leadership framework concept. Can you share that with me?

(Francisco Trandade at 00:20:13) Yeah, for sure. I think maybe we'll start just from the beginning. I think the kind of thorough line of what leadership for me has been is this idea of thinking in systems. But I think, maybe just going back to a story here is, I started a company when I was in college effectively. I was doing a master. So after college, I didn't know much about software. It was a software delivery company. But I had learned, you know, I don't know if you remember that, but the rational process of just, that was kind of how you build the UML diagrams and you build the functional diagrams and, that was what I had learned in college about this is how you deliver software. And so I started doing that, which was kind of what I had—we had this partnership with a client, and I spent three months doing that and just, it was drawing diagrams and going to meetings.

(Francisco Trandade at 00:21:14) And after three months, it just, I was like, though, we have no code written yet. We just, we've been discussing over and over these requirements. We cannot seem to agree to the point that we had to cancel this. We had to—I remember this is, like, vivid memory of going to a meeting with this client and say, we cannot do this anymore. We are running out of money, and we have nothing yet. This is not working. And I was supposed to be the expert in how to build software because it was my company. And this client saying, you're failing us. This is disappointing.

(Francisco Trandade at 00:21:45) And I came out of that with this real kind of strong understanding of, actually, writing code is often not the problem of getting software done. It is the process, everything that's around it and kind of just how you deliver value end to end. And that then was kind of—it was not the beginning, but it was kind of still early agile revolution days of, we're moving into these agile methodologies. So I started reading about that and it's like, oh, there's a different way that made more sense and started thinking of that. But then and that one has been what has continued to, in my experience, continue to be valuable.

(Francisco Trandade at 00:22:27) The idea of thinking about software and software development or product development as from a systemic perspective was, actually thinking about, not just I'm an engineering leader and I have to help my engineers write the right code, but I need to understand from idea to production, what is the work that's being done there and what's influencing what's happening, what's influencing that positively and negatively, and how can I help align everyone to make sure that—including engineering, of course, but also more broadly—so that we get to results faster? And I think that's kind of been really the thorough line of the whole idea of thinking systems.

(Joel Beasley at 00:23:16) And then you're writing a book or it's already written? Where are you at with that?

(Francisco Trandade at 00:23:19) I'm at the final stages of doing that. So yeah. So I think as part of, just to explain a bit more about the book, I think this approach of kind of just thinking holistically about a team, I think, has been very useful for me. And I think it's something that I haven't found to be very common in the industry. But also, a lot of the engineering, I think a lot of the engineering leadership material that's out there, it's very focused.

(Francisco Trandade at 00:23:50) So it's focused on the people aspects of that or the technology aspects of that or the process aspects of that. So I wanted to create a more practical, holistic perspective on how to lead a team effectively. And so I've been writing this book for the past year. I'm in the final stages at this point, so I hope to be—I hope that to be released, definitely this year, hopefully in the next month, I think.

(Joel Beasley at 00:24:17) Awesome. Well, ping me when you have it out, and we'll let people know about it.

(Francisco Trandade at 00:24:19) I will do. I'll do for sure.

(Joel Beasley at 00:24:23) So whatever happened with that client you said that you were talking about, I just want to wrap that part of the story up. They were upset. You run out of money. You're failing them. What happened?

(Francisco Trandade at 00:24:34) I mean, that was, we just broke—there was a partnership that we had to build a software together and sell it, and we effectively didn't do it. We just, because the challenge for us, because that was a partnership, we weren't effectively having revenue out of that, but we had a hope to achieve to make money in the future. And at the point, my business partners were just like, we're not delivering anything. And there's no revenue coming in. So we need to find some clients that are paying us.

(Francisco Trandade at 00:25:03) So we had to go to them and say, look, we're not going to do this, which also was a personal relationship. This partner, I had brought that relationship into the company. So for me, it was just this disappointing ending overall. And then we eventually found someone that would actually pay for our services, which was how we kind of kept alive for a few years.

(Joel Beasley at 00:25:22) Yeah. And when they're paying for it, they don't waste as much time either.

(Francisco Trandade at 00:25:25) Exactly.

(Joel Beasley at 00:25:26) That's what I have found. If it's partnership and we're just building a dream thing and there's no money here, then you can just talk about it forever. But if there is a budget and a—and if there's an outcome you have to achieve and a dollar associated with that outcome, you cut all the scope, you cut all the fat, and you focus on just doing the least amount of things necessary to achieve the outcome, and then you've got version one.

(Francisco Trandade at 00:25:49) Yeah. And that's, effectively, I think I went from that. So that was my first work experience having this company where I knew not much about what to do. So then that company lasted for a few years, and then I eventually started consulting with this company called ThoughtWorks, which, first, they were the people I met. I started reading these books about Agile, and ThoughtWorks was the company that was writing a lot of the books at that time.

(Francisco Trandade at 00:26:15) So I was like, oh, this is really interesting. I should try to work with this company that's effectively where I'm learning from anyway and see if I can learn from them more directly. But that was consulting. And then, to your point, the thing that completely changes the game because you're talking about, okay, there's a client paying for it.

(Francisco Trandade at 00:26:33) And if you overestimate, you're going to be incurring losses because now you're, as a company, you're probably doing much more. If you don't deliver what's expected, the client's disappointed. So there's a lot of complexity that you need to just summarize, streamline and align pretty quickly because you don't get a second chance. Right? There's not going to be a v2 if v1 is not something that pleased everyone.

(Francisco Trandade at 00:27:02) I think that's kind of—so that really helped me kind of think about the idea of, okay, the value is delivery. The value is, what's the customer value here? What is the goal that we're trying to achieve?

(Joel Beasley at 00:27:17) Was ThoughtWorks the first time that you had a real boss?

(Francisco Trandade at 00:27:20) It wasn't because, so that's the interesting part. So I had, you know, a company when I decided college. I went to ThoughtWorks. ThoughtWorks, you had, of course, a structure, but we didn't have managers. So effectively, you had this person who was a sponsor who kind of just helped you with your career.

(Francisco Trandade at 00:27:42) So they would be the person that you meet, and they kind of just give you some advice, but they're not really responsible for your performance in any way. And then you'd go into projects where projects had teams, and teams had some hierarchy of, there's the most senior person, or there was the project manager, or there was someone that's leading the account. That person is not your boss either. They're just, they're leading this team. And so as a consultant throughout this first part of my career, I didn't have someone that I reported to.

(Francisco Trandade at 00:28:12) Of course, you got a lot of feedback and I learned a lot in that period, but not through a specific manager. Then I left that and I started my own company again, and that was another six years where, effectively, I was the founder of the company. So I was leading. I didn't have a manager either. So then if you go from the beginning, I'm fifteen years of my career and I joined this company for the first time.

(Francisco Trandade at 00:28:42) And that was the first time I had a boss. Someone that I reported to, and it really took me a while to kind of understand that concept. The thing, I, of course, I understood in practice or in theory, but I kind of remember the first six months or a year of the job of thinking, okay, now there's this person here that I need to actually—I'm here to do, to kind of follow their direction and to kind of execute their plan.

(Francisco Trandade at 00:29:13) And I think that is something that, yeah, took me a while to adjust.

(Joel Beasley at 00:29:20) Tell me about the burnout that you got when you were 35 and you got your first boss.

(Francisco Trandade at 00:29:29) Yeah. So I think it was kind of related, I think, because, so, you know, in this company, I have a manager now. And first, there is the idea of, okay, I need to understand this relationship, and I understand that I'm here to support this person and deliver on their plan.

(Francisco Trandade at 00:29:47) And I think that's, you know, just in any company, that's true. And while I have—and I always, because I think I had done this job, this part for fifteen years, I was very opinionated about how things had to be done and stuff. So I kind of have to manage that. Oh, I have my perspectives, and I want to do things a certain way, but I need to align with this person. And that's really important.

(Francisco Trandade at 00:30:10) And that's something it took me a while to discuss. And I think that's something that I actually take—we're gonna talk later, but I still take today in how I manage people. But then I think the other thing that happened is that, as joining this company, I kinda solved some problems really quickly. I think we talked about the systems thinking part of it, but there were teams. I joined a team, and the team was not performing.

(Francisco Trandade at 00:30:43) And I made changes. It was by looking at the team and making some changes, things improved. And I was like, okay. So it was really successful. Right? So it's a point that my manager was like, oh, this is great. You know? You've been here for a month and things are better.

(Francisco Trandade at 00:30:56) And then I did that again in some other area. And then it became—it kind of became just like, oh, let's get Francisco to fix this other problem and this other problem. And I was just eager to—again, I think maybe I was eager to please and eager to make an effort and provide impact and provide value.

(Francisco Trandade at 00:31:24) I was new to the country. So it was kinda like I was getting to the American industry in tech. And so I think that was a lot of different things. So I was just saying, yes. Yes. I wanna do this. I wanna take this challenge. I wanna take this challenge. And, funny enough, I had this older colleague who was a peer. I was a director, and he was a director.

(Francisco Trandade at 00:31:48) And he told me—at some point in the meeting, he said, look. You're trying to solve this problem that everyone tried before, and no one could. So just be mindful that you might fail. This is not simple. Right? You're not the first one to try it. But I had energy, and I was here to do it. Eventually, I think I tried to do a bunch of stuff. And while I succeeded in some of them, I had also many failures.

(Francisco Trandade at 00:32:13) And I think that was also a lesson because I think in leadership, a lot of your reports and people that you are leading are trusting that you are pointing them in the right direction that's gonna be successful. And successful means, you know, it's gonna work and that work can also gonna help their careers and it's gonna help them move forward. So extending myself, kinda having things that I failed at the thing. I eventually actually burned out on that role. So I just lost the energy of doing all of that role because it was—I was just stretched thin, and it was something that I definitely take now.

(Francisco Trandade at 00:32:59) I take nowadays and I think understanding also that it helped me to understand the idea of authority and influence, right, of saying, okay. In any role, you're gonna have authority to decide on some items, but you're gonna have influence in others, and there's a difference. That should really frame what you're trying to do because if you're trying to influence something, it's gonna take much more energy than something that you can decide. And if you try to do too many things at the same time, you end up spending a lot of that energy and not being effective—or being ineffective either.

(Joel Beasley at 00:33:36) Of all the leadership advice that you've received in your career, what's the one that you've kept? Someone's shared it with you. You're like, I'm gonna try it. It worked, and you've kept it.

(Francisco Trandade at 00:33:47) I think there's two. One is actually related to this story, at this company. I think the same—as we're going through this, as I'm going through a lot of these challenges and I think things are working, things are not working. The same colleague which gave me the advice about, you're trying to do too much. He said something that really stuck with me, but he was saying, you know, leadership is, if things are incrementally improving, that's the best you can hope for. You cannot get everything to be right, but you just have to try to make things a bit better every time.

(Francisco Trandade at 00:34:24) And that is such a—I think the reason why that stuck with me, I think, is that it's such a—I think when you talk about leadership and I think if you read about leadership and if you go to conferences and you listen to people talking about it, a lot is like a polished version of it of saying, oh, I did this. I did that. Success. You know, yes, you should do that as well. What the reality of leadership in practice is that there's a lot of things going on. You're trying to do a lot. Some things work, some things don't. But you just have to keep pushing in the right direction. And I think if you have a vision and you keep pushing and things are improving, that's a good path. I think that's something it just feels more chaotic that I think the book tells you, and it feels more messy than the book tells you. So that was, I think, something that stuck with me.

(Francisco Trandade at 00:35:21) And then the second advice that I would say that was really interesting for me was someone that said that careers don't make sense looking forward. They would make sense looking backwards. And I think that's—I received the advice in a moment that I was trying to figure out what I was gonna do with my career and kinda have the idea of, like, what's gonna be my five year plan. And I always struggle with a five year plan. And hearing that, I was just like, oh, yeah. Maybe I don't need a five year plan. Maybe I just—and the advice this person gave was just, you need to do what you wanna do now, just do it very well. And then your career and you're gonna be unique because your career is gonna be a set of decisions you made to tackle certain problems and gain knowledge with that. And that's gonna shape you, and that's gonna be—and when you look backwards, you're gonna be like, yeah. Obviously, I'm in this role because I did all these things in the past.

(Francisco Trandade at 00:36:20) But you couldn't have planned that way. I think that's something that happens more organically.

(Joel Beasley at 00:36:26) Absolutely. Well, Francisco, we made a podcast. How do you feel?

(Francisco Trandade at 00:36:30) I feel great. Thank you. Thank you.

(Joel Beasley at 00:36:33) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you would like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.