Tech Titans: Rethinking Career Five-Year Plans with Francisco Trindade, VP of Software Engineering

(Francisco at 00:00:00) The big question I think that companies are facing is, can we get to a point where humans are out of the loop in the way they are right now, which is being kind of this need to have a code review with humans to kind of get products out themselves?

(Joel Beasley at 00:00:11) Now you have one person doing the work of a hundred and then a thousand and then ten thousand. What did you learn from writing that?

(Francisco at 00:00:31) Yeah, that was an interesting experience as well, and I want to continue that article. But I think it was kind of also the result of—I mean, we all been experiencing the shift in AI this year. All the models became much better, and people came back from the new year thinking about, okay, realizing, okay, this can actually—this is actually moving faster than a lot of people expected. And I think I started, you know, experiencing at work, also talking to people and seeing kind of this discussion happening in the industry. I mean, it's really interesting. I mean, we're going through a big shift, right, of what's happening with software engineering. And I do think that 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, I think, 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 that article was kind of really a summarization of these conversations and kind of getting this understanding of, okay, this seems to be—yeah, I talk about three versions of AI so far. I think v0 being last year when we all gave tools to engineers and no engineers had tools. And there was a lot of code being produced, but I don't think we've seen a lot of companies—I haven't seen a lot of the productivity gains. To some extent they have, but 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 faster, or bug automation or kind of issue automation so that small things can be solved automatically.

(Francisco at 00:02:18) 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 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 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 that AI 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, you know, how code you solve and kind of how that's not a problem anymore. But you still have this—you know, a lot of situations are saying that hasn't been—you know, 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?

(Francisco at 00:03:27) 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, ten x 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 that's a world that 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, I think, running much faster than you. And I think that's kind of the—it's an interesting kind of 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:04:26) Yeah. I think step one is 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 ten engineers, maybe you only need seven or five or three. But then that technology gets better and consolidates all the way down to one. Now you have one person doing the work of a hundred and then a thousand and then ten thousand. 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 ten thousand, like it being completely solved. Whereas reality is it's a bunch of small incremental steps along the way.

(Francisco at 00:05:13) That is true. I mean, I completely agree. I think 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 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 is 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 ten thousand agents, but how can they be—how do you guarantee coherence, I guess, as a product in ten thousand agents that are running it? I think that's gonna be part of the work in engineering. It's defining harnesses and kind of structure to achieve that.

(Francisco at 00:06:06) The other aspect, I think, is interesting is just—is not how do you get there—how do you get from one to a hundred to ten thousand 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 a demo and have its quirkinesses and then a lot of kind of depth 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 ten thousand 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 sub code base and tooling and kind of structure that can support ten thousand agents might need humans to take it through, right? Because the humans who have the context are still the ones in 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, and 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 ten years ago. I think a lot of companies invested in microservices, and they 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, in a best case scenario, talking about a two x gain of your speed of, like, maybe delivery, and that would be a very high success.

(Francisco at 00:07:53) I think the AI path might be similar—the company that you invest to get there. You know, there might be tooling that supports ten thousand agents, but you might need to do something with your code base to achieve that. But again, if you get there, it might be ten x instead of, or twenty x instead of two x, I think. But if you don't start now and someone else does it before you, then someone else is moving ten x faster.

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

(Francisco at 00:08:20) Yeah, for sure. I think maybe I'll start just from the beginning. I think the effect, the kind of storyline of what leadership for me has been, is this idea of thinking in systems. But I think maybe just going back to an exact story here is—I started the company when I was in college effectively. I was doing my masters. So after college, I didn't know much about software. It was a software delivery company. I had learned, you 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 you kind of—that was what I had learned in college about, this is how you deliver software. So I started doing that, which was kind of what I had to—we had this partnership with a client, and I spent three months doing that and just—and it was drawing diagrams and going to meetings. And after three months, it was just—I was like, 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 go—I remember this is a vivid memory of going to a meeting with this client and say, we cannot do this anymore. We are running out of money. We have nothing yet. This is not working. And I was supposed to be the expert in how to, you know, build software because it was my company. And this client saying, you're failing us. This is disappointing.

(Francisco at 00:09:44) 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 was the process, everything that's around it, and kind of just how you deliver value end to end. And that then was kind of how I got into—that was at the beginning, 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 has been what has continued to kind of, in my experience, continue to be valuable. 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 code, 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 storyline of the whole idea of thinking in systems. I'm at the final stages of doing that.

(Francisco at 00:11:14) So, yeah. So I think as part of just to explain a bit more about the book, I think this approach of just thinking holistically about a team, I think, has been very useful for me. And I think it's—and it's something that I haven't found to be very common in the industry. But, also, I think a lot of the engineering material, the engineering leadership material that's out there, it's very focused. So it's focused on the people aspects of that or the technology aspects of that or the process aspect of that. And I wanted to create a more practical, holistic perspective of 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—hope that's to be released definitely this year, hopefully in the next month.

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

(Francisco at 00:12:14) I think there's two. One is actually related to this story, kind of at this company. I think the same—as we're going through this kind of—as I'm going through a lot of these challenges and I'm seeing things are working, things are not working, the same colleague which gave me the advice about, you're trying to do too much—it's not something that really stuck with me, but he's 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. And that is such a—I think the reason why that's 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 a polished version of it of saying, oh, I did this. I did that. Success, you know? You should do that as well. When 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. 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 only make sense looking backwards. And I think that's—I received the advice in the moment I was trying to figure out what I was gonna do with my career and kind of have the idea of, what's gonna be my five-year plan? And I always struggle with a five-year plan.

(Francisco at 00:13:54) 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 like, you need to do what you really want to do now, just do it very well. And then your career and you're going to be unique because your career is going to be a set of decisions you made to tackle certain problems and gain knowledge with that. And that's going to shape you, and that's going to be—and when you look backwards, you're going to be like, yeah, obviously I'm in this role because I did all these things in the past. But you couldn't have planned that way. I think that's something that happens more organically.

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

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

(Joel Beasley at 00:14:32) 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'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected].

(Joel Beasley at 00:14:50) Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.