Brooks Folk: Leading with Purpose - Building Teams and Software for Success

This transcription is AI-generated and may contain errors or inaccuracies.
‍

Matt

My name is Matt and I will be talking with Brooks Folk about the role of a global engineering leader, challenges of leading at scale and the importance of cross disciplinary collaboration. You work as a global engineering leader at nCino.

There are 18,000 people worldwide are post IPO. It's a quite kind of a big organization and I always have a challenge with understanding the position. So maybe you could tell a few words. What are your responsibilities on what do you do?

Brooks Folk

Yeah, it's funny that you would think that would be the easiest question but in fact this is one of the craziest ones, right? Because it's a title in the industry that you don't hear very often. It's also one that I've been in I guess now for almost actually I think tomorrow is my one year anniversary. So it's actually quite broad. So the global engineering leader position at Encino is a new position for the company as well. We focused on having what we call global process leaders and global discipline leaders. So we have underneath our chief product officer we've got our global engineering leader, our global design leader and our global product leader as well.

And we call those basically kind of the leaders of the triad which we all know are so important in terms of implementing and executing on delivering world class software to customers. But our organization underneath there is also set up differently. We don't have any direct reports. We kind of act as kind of experts in the field, consulting teams on the things that they're doing. There's so much breadth of at Encino of how we do development from different product domains within banking and fintech to different tech stacks as well. So certain principles apply and some others don't. So we try to really extract the fundamentals that we can share across not only the different domains in banking, whether it's loans or credit, et cetera, but also globally around the world in terms of regional discrepancies and technical differences as well.

So I told you it's not, it's not a one line easy answer. It's kind of a new thing. But I'm enjoying the ride.

Matt

So if you think about the challenges that you are having at your job or what kind of challenges you are solving for organization, this might be maybe a better question like what is your role about? What challenges is your role about?

Brooks Folk

I think on paper the way that that pans out is there are certain things that overlap across all of our disciplines that no one group is responsible for. So you know, whether it's quality like release quality and code quality in the release in terms of bugs in code or latency within the application. Right. Like that doesn't necessarily apply to any one of our 124 product and engineering teams. It applies to everyone across the globe. So that's one example of things that kind of overlap, whether also like upskilling, upskilling and mentoring our teams as well. You know, obviously they'll have their direct people leader who also serves as their technical leader.

But sometimes it's nice to get a fresh perspective on things and be able to speak with someone who's, who's had a different lens after some time. So there's a lot of things that tooling is another one. Right. Like in terms of what tools we're using across the organization, there's a lot of things that don't, don't apply to any one particular function, but they go across and span across the org.

Matt

So maybe for instance, if somebody wants to use an open source for the one of their product. Right. So I assume you influence this decision and they need to have some kind of acceptance because this could have an impact. Right?

Brooks Folk

Yeah. And something, you know, everything's about balance, like we're all about autonomy but at the same time it can't be the wild wild west. So you know, you can't have one team using C and the other teams decide that you want to use PHP this week and then, you know, so there's, there's a level of, of understanding to share. And again with someone in the global position you can say hey look, we've already tried this experiment before. We did this before and in our APAC area and this is what resulted from it. So maybe A we don't do it or B we can try it but let's not do it this way because we've done it that way before. Yeah, those sorts of things.

Definitely a lot of stuff with vendors as well. But try to stay out of like the, the admin operations side and focus more on like engineering principles, philosophies, practices, those sorts of things.

Matt

Makes sense. And what I understand you have like a huge impact on organization, let's say on the stuff behind the curtains. There are almost like 20,000 people in an organization.

So it's a huge scale I would say. So maybe you could tell me more about the stories of the successes already. Thing that didn't went successful so well as planned. Right. Regarding like on such a big scale.

Brooks Folk

Yeah, well, I would not say it's been a home run so far like at that scale. And it's not just scale, it's so Many different departments that all have to come together to ultimately make the right product. Right. I always talk about building software as a team sport. You've got product Design, QA Engineering. DevOps infrastructure is in there somewhere too. If you don't have it in DevOps.

Matt

Right? Right.

Brooks Folk

But if any part of that process fails, the whole thing fails. So you can have the most amazing engineering team that produces bug free code and the best DevOps team that can deploy anything anywhere on any cloud in a matter of seconds. But none of that matters if you built the wrong thing. And none of that matters if you don't have the right technical documentation to support those things. Or you could do it the flip side. You could build the perfect thing, hit the, hit the right market timing, build it perfectly. But guess what?

You can't deploy it because DevOps can't scale. And your infrastructure is legacy and archaic and it all goes down once you hit 400 concurrent users. Like it is a team sport. And when you do that at scale across a large organization where there's not those three or four departments, it's really more like 12 departments that really come together to make this thing seamless. And it's built on top of other platforms that are dependencies, man, it gets really crazy really quickly. And then you factor in this global issue where Team A may do it this way in the United States and over in Europe, we're doing it another way, man.

It just gets exponentially more complex. So honestly Matt, it hasn't been a raging success because the scale is crazy. And I was, I was at Rocket Mortgage before it was a large company but not compared the, the number of people there were, were more but the complexity was, was way less. So that's been. My biggest challenge is, is working through the scale and to make sure that you're, you know, filtering down the things that are important while understanding. Like you're never going to get a consensus, Matt. Like there's too many people here and sometimes you just have to make a decision and go with it.

So long answer. But yeah, that one fired me up.

Matt

And like I assume there's a lot of organizations that are striving with similar things and have or could have similar roles. And after a while of being in that role, Brooks, probably you have some lessons learned or the things that are now obvious for you, but they were not so obvious back then in the past. So you know, like if somebody wants to start and like have a role such as your role, like what would you suggest the leaders to keep an eye on when rolling out changes on such a scale.

Brooks Folk

That's a great question. I think there are a lot of things. Number one, you know, coming into a large company as a leader, just straight up, you're going to have to deal with the situation where there's going to be a lot of other leaders and technologists that have been there a lot longer than you. And you have to be, you have to be confident, but you also have to be cautious in that. Man, you kind of need to sit down and shut up for a little while and really try to understand things before you go and try to, quote, unquote, fix things. Right. Everybody around you is smart.

They've made decisions in the past based on context that they had that you probably did not have. So coming in and kind of speculating or criticizing on things early is just not a great move, in my opinion. So that's one thing. Another thing that I found is that you are very rarely going to get 100% consensus on things. And there are times where you need to go with the consensus model. There are also times where you just need to make a call and get out of your own way. And being a really good leader, I think, is making those contextual decisions in the moment and understanding when you need to slow down and make sure that it's not about how fast you climb the mountain, it's whether or not you're climbing the right mountain at all.

And then there are other times when, you know, you just gotta make a move and go. And not belaboring silly things, whether it's, you know, documentation or how many interns to hire, whatever it is. Right. Like, so it's, it's, that's another thing that I have found.

Matt

And last time when we talk, you mentioned like a few interesting concepts that I think might be worth mentioning. So the first one, which I really like, like elephant carpaccio, could you tell more about it? What, what is it and how does it work for you?

Brooks Folk

Yeah, elephant carpaccio is a supremely interesting topic. It's one that, that I think can be applied not only to software, it's very applicable there, but kind of to other parts of our lives as well. So I'll do my best to describe it, but yeah, we can go super deep on this one. So carpaccio, elephant carpaccio, I think was a term coined by Alistair Coburn or some flavor of part of the Agile Manifesto group. And what they effectively are saying within elephant carpaccio is that, you know, we always talk about waterfall and we talk about being Agile in the those sorts of things, but this is taking it another layer. So on the surface, most, I think most software teams kind of, they, they come across a problem and maybe they'll start with, okay, all right, how are we going to build this fault tolerant multi region failover infrastructure? And I think what Alistair Coburn talks about is really thinly slicing.

So Carpaccio is like thinly sliced deli meats, or meats, if you will. And the idea is if you're going to eat an elephant, right, you do it one bite at a time. But taking that an extra step is what that means in software historically has just been we slice things up into little stories and we put them in sprints. But what he's saying is take that a step further and like everything that you do needs to actually be deliverable to the end user and add some type of value, even if it's small, as you can imagine, like a button that doesn't even work. He wants you to build in a thin vertical slice. This is kind of a concept where some people talk, it's kind of confusing, but I'll explain it just so people can get their head around it. But it means from the very bottom infrastructure to the top being the ui.

So not just, hey, we're going to do infrastructure this Sprint and then we'll build out the API and then we'll build in the UI and then we'll do testing after that. Talking about four sprints. No, he's like, bro, let's add a button. We don't need any infrastructure for it. We're going to not even make an API call. But it's got to be a real button and it's got to go to the user and you got to ship it. What that does though is really interesting.

It allows some of the other principles of Carpaccio to come into play, which is obtain feedback early and iterate. If, think about it, if you do that, if you put a button up there, if you're working on some ui, let's call it an online banking thing, and you do the Garpachi approach and you're just going to put a button up there, everybody, all the developers are going to say, brother button doesn't do anything, what's going to happen? Yeah, yeah. What you can do from that though is if you just had like some counter on the back end that says how many people click the button. You get so much feedback from that. Like you can say, wow, we released this to 5,000 people and only five even click the button. So from that you already learned some things.

Like, hey, either what we're saying on the button, nobody actually cares about what happens next, or we could say, wow, we know people care about it because of these other things, but apparently they can't see it because nobody's clicking on it. Right? And then the next iteration of that thing might be clicking the button and say, what do you expect to see here? And the feed, there's just a little comment level where people can give you information back. It allows you to capture feedback very, very early, as opposed to building out what you think this button should do and how it should act. And everything is that waterfall approach where you've built something for six months and then you get to market. It turns out your customers never even wanted it anyway.

Or you built it for six months and something called Chat GPT comes around like you have no idea where the market is going to go. And by delivering that or but delivering very thin vertical slices and then getting that feedback, you will not miss. Like, if you have the right mechanisms in place, you won't miss because you're literally getting it out to the customer base bit by bit as you go. And then the third principle of, of Carpaccio is generating early revenue. So we use this example in a few of the presentations I've done on this about, like, we've got a client that says they want a way to get goods to their customers faster. And right now they're walking and it's in the middle of the summer and it's hot and they can only take so much. Your brain, like, automatically will go to, okay, they need a van, right?

Yeah, okay, we'll build a van. But building a van is going to take two years. If instead of building a van, you slice this thing down, you could build a bike in two weeks and you give them the bike and they're like, wow, you know, it was better. I got there faster. I was able to take some stuff, but it rained and I'm really tired after pelling that long. So this is okay, but like, give me something else, right? But you got some feedback.

Like two weeks in, you're giving them something that helped a little bit, didn't solve all the problems, but. And then you take that feedback and you add a motor to the bike. So now it's a bike with a motor. It took you another two weeks to do that. But now they don't have to pedal. You give it to them, they're like, oh, this is better. Like, you're better.

But like, I still can't take a lot of stuff. And it rained on me. Okay, cool. Got it. Two weeks later, you put a shelter on top where nothing can get on them. They're like, oh, yo, we're getting really, really close here. It didn't, the, the weather didn't impact me.

I still can't take as much and it's still kind of hot outside, but I'm not sweating like I was because the motor was working. And it turns out I love it when the wind blows in my face. It keeps our products cool. Then they're like, hey, please keep doing this. But I like this so much that instead of walking, I'm willing to pay for what you've given me right now. And it may not be the full ticket, but I'm willing to pay you for what you can give me right now because you've already improved everything about it. I'm getting there faster.

My, my, my goods are, are dry. Like, everything's good. So they'll start paying you early for that thing, which self funds your own project so that you can continue to work on the roadmap. But you don't have to keep borrowing money from VC or spending your own budget like you're getting it from your customers. So that's a super long one. And those are a few principles of Carpaccio. But if you take that approach to, I think software, I think that it becomes fun.

You can get everybody involved, pays for itself and engineers, which we all hate, is like building something that never comes to fruition. Well, that will not happen here if we're, you know, getting the feedback and iterating on that feedback. So sorry for the long answer there, Matt, but that one also gets me fired up.

Matt

No, I think absolutely this is like such an important concept to be like a client centric, to be business oriented. And this is like really simple and visual explanation. And I think especially for engineers, there is something that is needed so it's like really easy to remember. Right. So I absolutely love that.

Brooks Folk

Yeah, you said something there that I also think is a really good point. This, this is super simple and super common sense. It's easy to understand. It's very hard to implement because our brains, our patterns in our brains are like, okay, we're going to go build this car. It seems so obvious. And then we set out for two years to build it. You have to be very intentional and deliberate about your next thin vertical slice and how it will bring value and allow you to get feedback and then where to go from there.

But our brains Just go to that too. One more like super quick non technical example is if like your leader, your boss ask you to deliver some 10 page report on X, Y, Z. If you sit down, Matt, and you say, all right, page one, that you spend 14 hours trying to write a 10 page paper, right? Opposed to like a carpaccio approach on that would be something like, okay, I got to write 10 pages on this thing. I'm just going to like, let me do some like sections here.

Intro, I'm going to talk about xyz. Page one, I'm going to back up my argument in the introduction. Page two, I'm going to start to get into like instead of that it's more like just titles of each page, right? If you spent 10 hours and you show it to your boss, he's like, yo, this is trash. This is not at all what I wanted. You're, you're gone from the 10 hours. You spent 10 minutes putting a sentence on each page and showed to him like, yep, great start.

Or no, that's not the right way. I wanted you to go this other angle. But that same approach and then you could put in one sentence of each paragraph. Like you get the opportunity to catch so much stuff so early instead of building the wrong thing and waterfalling it.

Matt

Great example. I really like it. Speaking of you before mentioned that not always you can get all the stakeholders to make when you are making a decision that has a big impact because you have so many of the stakeholders. So you have to do tough decisions and maybe do you recall any of those decisions that was really tough, especially for the engineering, but you have to do the decision and it's turned out right or maybe wrong and you've got some lessons learned out of it.

Brooks Folk

Pretty much every single one of those decisions, right? I mean everything's about I'm a big, big balance guy and context is king. Right? Like so every single time you make a decision like there's not necessarily a right or wrong decision, there's just trade offs with every single one. And so off the cuff you're going to have people that are not agreeing with the, the direction every single time. The challenge will become those people who were not on board. Can you get them on board enough to like see whether or not it succeeds or fails?

The direction that we set off in, I mean to answer your question specifically is like, is there one? I mean honestly, I can spend a few minutes here and thinking about it and yeah, there's, there's a ton. You know, whether it's what I Mean we, we just got finished with our hackathon and whether, I mean, you know, our engineer hackathon, which was a wild success, but during the planning phases and everything else, like you would have thought the world was coming to an end. What do you mean we can only have four people on a team? And what do you mean it's got to be, you know, submitted by this time. So even admin things like that versus way more technical things like hey, are we API first?

You know, our blah, blah, blah. Right. But I just think that when you get to a group that is, you know, large and smart, you are not going to ever get consensus across the board. And I think it's up to the leader to understand again like to understand both sides of the arguments and be very objective about it. Sometimes you have to make a call, sometimes it's so important that you do need full consensus, you know, across the board. And sometimes the challenge will be, I know this is going to be a 50, 50 split, I'm going to make the best call that I can. And then my job becomes I have to get these other leaders on board and marching to the same tune.

Because if they intentionally want to sabotage or whatever, then no, but we're not going to learn. Because even, even if you were wrong and people go all in, at least you can walk away with that and say, wow, we gave this a legitimate shot and I legitimately was wrong. And here's what I can learn from that.

Matt

Speaking of the leaders, especially in tech, I'm just wondering what is your opinion on the topic that could you be a good leader on engineering? Let's in an engineering field without the engineering hands on experience, do you think possible or maybe it's like, you know, some kind of advantage that you don't know so many concepts and you think outside of the box. I don't know like what is your opinion here?

Brooks Folk

I think it changes a lot, but my current opinion is like the farther you are from hands on keyboard contribution, I think, I think it's okay to not have been technical recently. I do think that like you get a lot of respect from engineering organizations when you have had that engineering hat on. I think when you were hands on keyboard at some point there, there's just a bit of kudos that comes with that. But, but it also just helps you so much, right? Like you can remember the day to day of what it was like to get a badger a ticket or a design that didn't make sense or whatever. So I think it really helps you connect and resonate with those that you lead. I do think it is an advantage, I guess in this world.

I don't say things are hard and fast and always true anymore. But I would say that for the most part I think it helps both the leader from a leadership standpoint and connecting and people wanting to follow them because they've been in those, in those same shoes. But it's not an absolute necessity. And by the way, I'll say this too, this is something else I think is interesting is when we talk about different levels of leaders and the teams and this, it's also important to realize that the leader that you need is contextual to the team that you have. Right. Like if you have a group of senior API engineers, you don't need some super technical API leader. What you may need is someone who's got really high EQ and can kind of break through the walls and facilitate an awesome team culture and take away a lot of the admin stuff, those sorts of things you need whatever is going to be the best multiplier for that team.

On the flip side, if you've got a team of junior engineers, you are going to need someone more technical because they need more technical guidance on those PR reviews or whatever. So again, I mean I'm a context is keen guy and like it is the leader you need is contextual to the team that you have.

Matt

Another question that I have, it's a bit of a cliche, I would say it's about the work.

Brooks Folk

I like cloud, I love cliches.

Matt

So I really want to hear your take here because like you know what, I see you wake up probably earlier than 5am so you already have your kind of routine and a system that you are working on. And recently I had really interesting talk with a head of engineering from the upwork like Snapchat and Pinterest and he, he, he's an Italian guy and I asked him like the one question like what the US leaders, tech leaders could learn from European leaders and what he mentioned, it's like to take some package, to take some time off. So, and I mean like I think in our job, in our job as a leaders, you can work 247 all the time. So like how do you approach the work balance in your case, how do you do it?

Brooks Folk

Yeah, you know, it's one of my favorite questions. I, I mean I'm like you said up at 5 right now. So like my opinions, I try to live them out but I would say matters to what you want to be. I mean when I was an engineer. I was bad. Like went straight out of college. Like your boy had zero talent, like none.

I couldn't put in a regular eight hours and become who I wanted to become. For me to be who I wanted to be, it was taking me 12 to 16, six days a week. And nobody told me to do that. Nobody pressured me to do that. I expected that of myself because of who I wanted to become. I think his name was Trevor Moad. Wrote a book called It Takes what It Takes.

So whatever it takes for you individually to get wherever you want to go, that's what it takes. So if it takes you six hours, some people are super smart and they just get it. That's awesome. For me, I have to get up at 5am and grind through the entire day because a lot of things don't come natural to me. But because I want to be great, I'm willing to put in the time. Gary Vee says, if you want to be an anomaly, you got to act like one. So I'm not expecting to wake up at 9am in the morning and roll out of bed, yawn and hit it, and then roll out at 4 and to be anything special.

And that's fine, by the way. I'm not saying that that's wrong. One of my best friends I envy very much loves video games and he's a great engineer. He's one of those people that just kind of get it. But he's, he's in at 8 and he's out at 4:30. But I mean that's exactly what he should be doing because that's what he loves. He wants to clock out and be with the boys online. And that's great.

Like that's where you get the joy. The joy for me personally becomes like being a good technologist, being a good leader of technical people. And that's where I want to be. So I'm going to put in the time on that instead of, you know, Mario Kart. But like, I totally think it's an individual decision. The problem is when you try to talk about work life balance and apply it across the masses. The same thing with consensus.

Like you're going to get everybody be like, whoa, who? So whether you say everybody you need everybody, work 16 hours or everybody, you guys need to take a three hour lunch today, like it's never going to work.

It's all individualized. Context is king. Like do what you have to do in order to be the person that you want to be. And so I think work life balances trash. I think You, I don't, I don't think you can apply. Only you can, only you can figure out the right work life balance for you based on where you want to go and what you enjoy. And there's no right or wrong answer.

Matt

Well said. I would say like it depends on like in my case, when I think about it depends on the time of your life, right? So it's not always all the time work. Sometimes it's more of a life, right? You got, I don't know, you got interested in some kind of sport, so you put out all the, a lot of, of your mind there. But like in the end when you look about the sum of the experiences probably if you are so passionate about work, you focus on work a lot, right? So I thought you get it.

Brooks Folk

I had to say that's a really, it's a really good point. And by the way, you'll be able to get after it more in your 20s for, for most people, right, Once you get married. I just had my third little girl, she's like four weeks old today. Like once you get after it like that, like you, your, your priorities are going to shift. It's got to be like, you know what, I'm 39 years old now, my daughter just turned 4, I'm rolling out of here at 5 and guess what? That's the right decision to make. But when I was 20, I wanted to be the person that had the ability to take off at four with a family of four.

So in order to get there, I had to grind my ass off and I don't regret it at all. Hell, I wish I'd gone even harder. So that's a great point, Matt. Like it depends on where you are within your life. And you may be the, on the work hard life balance thing, you may be super duper, work hard for the twenties and then you may go down from there and that's great. I think it will fluctuate as your life changes. That's a great point.

Matt

And Brooks, when you think about your career, so you are for quite a while in tech and like there are some experiences that we have and that shaped us and I think those are usually the hardest things that we have done in our career. So now from the perspective, maybe it doesn't sounds so like difficult, but I think it stick in your head. Do you recall like the hardest things, the hardest thing that you have ever done in your career and how this shaped you?

Brooks Folk

Man, so many hard things, I mean so many hard things from like back when I was a team Leader of a software team. I mean, we'd have three week sprints. @ the end of the sprint, we did a retro or we'd have a Sprint demo. More often than not, Matt, those things, you know, those, those Thursdays before the Friday sprint review would be, I mean, sometimes 20 hour days.

And that was really hard physically, mentally, emotionally. But the joy that our team was able to have from showing off the work that we had done across all 10 of us or whatever for those three weeks was so much worth it, especially as like an early startup. It was at a smaller company, I guess I'm telling you that one because it was super hard, but also super worth.

It wouldn't change a thing. Other hard things, and from a leadership perspective of like, man, every, every conversation that you have with your team members, that is not, hey, you're doing great.

Here comes your 8% bump. Those are hard.

And what I've found, Matt, is that, you know, it's. Here comes a cliche for you. Like, doing the hard things in the moment results in an easy life over time. But like, there's all these small moments that are going to happen for leaders every single day, every single week, every single month that will never stick out as the hardest thing you ever did. But having that conversation with the engineer on their team early on, which says, hey, I want you to know that you're starting to build a reputation of someone who doesn't finish their work and is letting their teammates down. And I'm coming to you and I'm having this hard conversation because I care about you and I want to see you succeed. And here are three things that I want to help you do to get you there.

Those smaller hard moments are never easy. But man, you'll get so much gratitude from that person when you connect with them and they see you because they understand it would have been way easier to just go about your day, kind of brush it under the rug, not talk about it until they're on a performance improvement plan. Like, there's all these small moments every single day where leaders get a chance to build trust. And the hard thing, the hardest thing is making sure we're taking advantage of those small moments. So those are a couple that I talk about.

Matt

And how about now? What kind of challenges do you have on your plate? What do you type in Google? What do you Type in the ChatGPT to help yourself to educate on the matters that are challenging right now?

Brooks Folk

Engineering strategy at scale is really tough. It's extremely tough. We talk about buzz, we, we say all the buzzwords, just like every, every company in the world does. Like, we want AI and intelligence everywhere. That sounds great, but, like, how do we do that? Like, what can we tell our individual software teams that that can. They can actually manifest our words into reality?

Like, are there some filters? I'm big on this. This thing that I heard from one of the other leaders at Encino, Ryan, which was we have to, like, have these first principle things of, like, when we say that, here's what we mean from an engineering standpoint, when you do X, Y and Z, whether, like, data is indexable and those sorts of things from a design standpoint, hey, we're going to have this. Make sure that every single UI has a little X, Y, Z icon so they know that there's intelligence. Like, there are these. There are these first principles underneath this buzzword umbrella that people can actually filter their everyday decisions through. And getting down to that level of granularity will help these grand visions come into fruition.

So that's a big, challenging engineering strategy at scale globally is a humongous challenge. That's something that we're working to get right right now.

Matt

And the last question that I ask all of my guests, when you think about the, about some books, maybe conferences, podcasts, I don't know, like, the personalities that have been especially helpful to you as a leader, would you recommend some of those things? Like, some titles, you know, I'll take.

Brooks Folk

A completely different tech because of two people I'm going to give you are like, absolute opposites. So Simon said that from, like an EQ leadership standpoint, I think he hits on so many things. Like, he helped me so, so much early in my leadership journey to have the right foundation. And then on the flip side, Elon Musk, like, just an absolute, just driver. Like, and I know he's very polarizing. It's hard to deny his incredible resume. But he's so focused on getting results and he's just straight up about it.

Like, we're gonna do this, it's gonna be hard. Yada, yada.

Matt

Like.

Brooks Folk

I think another amazing thing that he had in his book, by the way, sorry, this little tangent was about automating too early. He talks about, like, people want all this automation and stuff, right? But, like, be careful not to automate too early because you haven't gone through the process, you haven't worked out the kink. So you're gonna automate it wrong and do it wrong, you know, scripted, and it's going to batch out wrong. And then you got to unwind it, figure out what went wrong. Oh, and then you can change it and then you're going to mess it up again. He's like, no, that was wrong.

We should have done it manually, nailed the process down, found the kinks, worked them out and then automated it. But Elon's one. I mean, you just have to respect what he's done in and out of this world.

So I would. I would say his autobiography, his most recent one was amazing. And then Simon Sinek Leaders Eat Last is a super good one.

Matt

Awesome. I think the Alan is really interesting. I don't hear that really often from the engineering leaders, but I 100 agree with you. He is really. Some of those things are controversial, but when you think about it and you think about the impact and how this result, that, what kind of output it gave, it's. I think it's brilliant. And he's acting so fast and those companies are so huge and they're acting so fast and delivering like so fast.

So I think we should take some lessons out of it. So I 100% agree. Really influence.

Brooks Folk

And you think about what Elon's done. Everybody knows Space X every. Everybody knows Tesla, right? Everybody probably knows Twitter at this point, but there's so many other things, bro, that he's doing that like people don't even realize or appreciate. I mean, look at Starlink. I mean, Starlink has provided Internet to millions of people.

Like in West. I'm in North Carolina and in western North Carolina, like, he's deployed those bad boys and now suddenly people have Internet. You cannot imagine how many lives that has saved. And I mean, again, whether you believe he's controversial or not, like the fact that he has built satellite Internet that can be deployed, deployed remotely, and boom, you're good. You're up. Like, it's incredible. I mean, it's absolutely incredible.

And the boring company, the tr. The. The underground tunnels, like, it's all crazy.

I mean, he's. It's. It's incredible.

Matt

And those are only the side projects, right? The narrowing side projects over the weekend.

Brooks Folk

Right? So exactly. Yeah. That's his 5 to 6am hour. That's. That's what he's doing.

Matt

Awesome. Brooks, thank you so much for the conversation. Thank you so much for today.

Have a great start today. I hope you help you a bit with this conversation that we had to wake you up. So thanks.

Brooks Folk

It fired me up. Matt, thanks for having me. Honored to be here and wish you the best. Thanks again. Follow Matt and Leshek on LinkedIn.

‍