Career Journey 2: Essential Skills & Key Attributes | Thiago Ghisi

0:00Anything becomes easier if you have that mentality, right? You know what to do. You know who to talk to. And you usually have a path forward. You might not be able to solve every single problem, but you become accountable for that and you take at least one, two steps forward on that. I think it's really important if you're interested in career growth as you go from a manager to a director and then to like a VP or an SVP. What I've seen is the characteristic that you are describing is a common characteristic in folks that are getting promoted.

0:54a virtual event for engineering leaders, attendees will be among the first in the world to explore the landmark data. This year's report analyzed 3.6 million branches from over 2 ,000 dev teams across 32 countries. Deep dive into the data by team, size, geolocation, and industry. Plus, see how elite teams perform against Dorometrics and get acquainted with brand new benchmarks like Investment Profile introduced this year. The best part? Just for registering, you'll receive a free pre-release copy of the 2023 Software Engineering Benchmarks Report. Don't miss out. Be at the forefront of engineering excellence.

1:29Register today at linearb.io slash events or use the link in the show notes. Hey, what is up, everyone? Welcome back to Dev Interrupted. I'm Dan Lines, Linear B co-founder and COO, and we're thrilled to continue our series on the career journey of an engineering leader with Chiago Giese, Director of Engineering at New Bank. Chiago, great to have you back on the show. Thanks, Dan. Glad to be here, man. Appreciate it. Awesome to have you again. So this is our second installment in our series of Engineering Leadership. So if you all haven't listened to Chiago's first episode, highly recommend it.

2:15Everyone in the audience, definitely go and check it out. There's a lot of great advice in there. Definitely don't want you to miss it. So to kind of dive in here, last week, we discussed the beginnings of an engineering manager's career journey. But today, we're going to go even a little further, digging into what it takes to lay a strong foundation as a leader and how to learn the skills that will make you successful throughout your career, as well as make you a good person, both at home, but especially to work for. And, you know, as leaders, I think we should always strive for that. So let's jump right in our first topic today.

2:58Actually, I love this title. The title of our first topic is when a bad decision is better than no decision. So, Chiago, you've delivered, you know, hundreds of large features during your career as an engineering manager, a director. You have a lot of lessons that you've learned along the way. One lesson that really stands out is that a bad decision is often better than no decision at all. So what does that mean? Walk us through. I remember once our CTO, when I was at America Express, and he said a phrase that I kind of talked to the heart. that was like for 99 % of things in life, a bad decision is better than no decision, right?

3:47And what that means in reality, especially in engineering, when you are trying to deliver big things is remind everyone, remind yourself, remind your managers, remind your engineers that sometimes like a really small decision that is holding, let's say, the deliver of a thing, to be better off if you just move forward with whatever you feel is the best option at the time and then iterate if needed, then try to kind of like stay focused on research, doing POCs, all that, right? One idea that I started doing early in my career, especially when I became a director, was to start to time how long it was taking to unblock those decisions and those projects, right?

4:35Especially when there was, let's say, conflicts between two engineers, one staff engineer and one principal engineer, they could not agree on a topic, right? And I would often jump in and say, okay, guys, let me document the decision point here and I'm going to give you 24 hours to make the best decision you can and then we're going to move on. And that's how you have, 24 hours. And sometimes they would usually get to an option before that. But if there was no decision after 24 hours, we then will do a meeting and then like align on the next steps. I feel that, I mean, I have seen so many projects, so many things slowing down, let's say, deliver off large initiatives because of those things that they just get stuck.

5:22Right. And no one has the has like, I don't know if it's the process or the courage to actually go and say, guys, this is not the thing that's going to break or or make this project. Let's move on and let's let's see how reality is actually going to treat us. Right. Because a lot of times what is going to cause problems is not that particular point is other things that we have not seen that we're only going to see if we make progress and we should move forward. Right. So I'm a really big fan of like walking skeletons. Right. Like getting that shape of the project working end to end and then like iterating on that over time.

6:03But overall, I think like this process of trying to document the blocking point and trying to time. OK, we have this time to make the best decision we can. No matter what, we're going to move forward is a process that worked really well and avoided a lot of frustrations. Because I also noticed that a lot of times what drives engineers to be super frustrated is that they cannot move forward because there is some decision that needs to be made. And often if you are not, let's say, actively managing the team or you don't have a good engineer manager there to take sides or to move things forward, those things tend to hold for days, weeks, if not months, right?

6:46Yeah. I love the concept here. There's a lot to unpack. So let's try to do it one by one. The first thing is, I do think that there, because I remember being in this situation, there's something about being an engineer. And maybe when you're like getting into the details and you're kind of thinking about your job and you're trying to make the best decision possible, maybe you don't want to mess it up. Maybe it's like that engineering DNA that you think it needs to be perfect. So you start researching, you're trying out all these different like POCs and prototype and all of a sudden a few weeks have gone by and the project hasn't moved forward.

7:26I can understand that feeling. So it's almost like you have to break that natural. I was referring to like DNA or that natural thing in your brain that says I got to be perfect. Right. So I think I think that's one concept. But the way that you did it is you put on a limitation, which I really like, or a criteria. You said, we need to make a decision within 24 hours. I'm starting the clock. And what I love about that, especially with engineering teams, is it's a constraint. And when things get constrained, I think creativity comes out. I think better, actually better decision-making. If you have every single option in the world, unlimited resources, unlimited time, unlimited budget.

8:15Yeah, you can go on forever. Hey, we got 24 hours here. We got to make a decision. Have you seen that kind of like time block change the behavior in a positive way? Yeah, for sure. And I will often remind folks that that's not usually my approach to everything, right? Especially if it is something, okay, we were planning the next year and we are exploring the next observability tool we're going to use, right? It's a big commitment. That we can take weeks to decide. But if we have, let's say, a delivery that needs to happen, right? I'm going to, on the first meetings of that particular project, I would kind of try to bring to the table, folks, just so you know, we are on a really tight deadline or timeline here.

9:04We're going to use this decision-making or escalation process is another topic we can get into, right? That's going to be really important for us to move things forward. And then whenever the time comes, whenever I see a Slack thread that goes back and forth, a hundred replies, right? I jump in and say, okay, what's going on? Let's start the clock and make a decision, right? And I think a big part of the responsibility of engineering manager is to actually be playing that role, to be moon-trained where there is tension, whereas there is like people stuck, right? And getting the chain to get stuck.

9:41And sometimes that might be inside the squad or whatever. Sometimes might be outside, especially if you work on large organizations, right? You have a lot of dependents. You depend on the platform to deliver something. You depend on the infrastructure to do something, right? And there, there is another term that we coined back at my time at Amex, That is the CI, CG, right? Continuous integration, continuous delivery. That is CE, continuous escalation. That's another thing you need to do to get things moving. And escalating is not a bad thing, right? It is something that's needed. And I think, of course, you should not overuse it, but it's not a failure.

10:25You need to learn that escalating and in order to make progress is the thing that's needed, right? Of course, you should try to do things before escalating for every single small disagreement. But that goes a long way with a really strong decision-making process. Especially, again, if you are on a timeline, you have a big customer delivery to reach, right? I think that is a few things that I learned that work really well. Yeah, I love that CE. I mean, the thing with an escalation, you're really identifying a bottleneck that needs to be resolved. and any time that you're escalating, usually that's okay.

11:04It's even better if you're coming with a solution with your escalation of like, hey, we have this bottleneck. We're going back and forth. Here's like one option or the two options. Can you help us move this forward even better? That should always be the case then actually. Like you should not escalate without a recommendation, right? I think good managers always provide, okay, here's my take of what we can do to move forward, right? Here are the trade-offs. but this is like, I need you to pick one of the options. Those are the options. My recommendation is X. I was reading the other day a book called Scaling People, and Stripe, they actually, they change the name.

11:44They don't call it escalation process. They call it the unblocking process so that engineers feel more welcome to do things. And they have a template of document disagreement, document the approach, when to bring in managers. And I think that's exactly, Those decision-making processes and escalation are basically a way to make progress, to unblock things, to not let things idle. Yeah, let's see if we can get that. That's at Stripe, like Stripe Engineering? Yeah, Stripe Engineering. We'll see that we can include that in our links. That's really cool. You mentioned that you don't use the 24-hour criteria all the time.

12:23Sometimes you're saying, okay, maybe multiple weeks. I know it's probably tough, but do you have anything where you think it's, okay, let's make a decision in 24 hours and iterate versus a decision that takes maybe multiple weeks? Is it different architecture decisions? Or how do you decide as a manager when to use a 24-hour rule versus something that maybe is a little bit of a bigger decision? Do you have anything there? I feel that like, okay, if you do something that was agreed ahead of time, like, okay, we're going to need, we're going to take one week, two weeks to do this, POC to do this, try to do this approach.

13:05I'm fine with whatever is the agreed on, right? Like, and whatever has been baked in the process, right? The thing for the 24 hours, especially when you have a defined project, you are on a timeline and you already have pretty much the tools, the platforms, everything is already consolidated. You already have a way of making things happen, right? You already have a stack that you use, right? In those cases, I think the 24-hour window is a good forcing function to make progress. And to remind folks that it's not like that if their option was not the one that was, let's say, selected, that it had failed.

13:46It's just that we might actually get back to that option if we actually find the problem with this contention point. But the rule of tabby is more like if it is something that is unplanned, then I would say the 24 hour, right? If it is something that's planned, something that's strategic, something that we need to be more careful, then I'm fine with whatever. I mean, I'm fine with a couple of weeks. Usually one week is a good time for me for playing out with a new tool, trying to do something. But I mean, there are things that require a lot more time. But I think giving way too much time without having structure, right?

14:24Without having weekly checkpoints at least, right? On how we're moving a particular initiative is also a problem in my experience, right? So you cannot open up too much. I think you need to have a structure where progress can be checked, questions can be asked, and we can iterate quickly. I think that's the main thing. The other thing to keep in mind before I move us on is remember that you can iterate. I think that's the other key point here. The way that most software is built today, you can make a decision and rapidly iterate on that decision. And when you have an unknown, meaning I don't know what the best decision is and I have multiple options, that's where it really comes into play of, okay, let's make a decision in 24 hours so that we can clear up some of the unknowns.

15:16We'll learn something from this decision and it will actually put us on the path to the right decision, which we don't know what that is yet. And it moves us closer. So I think that's the other key. Now, one funny thing that I was thinking about, because you said 99 % of the time, this is the right move. And I was thinking when I saw that question, when would this not be the right move? And last night, this is the weirdest thing. I had an urge. I don't know why this hit me. I had to look up what were the fastest planes, so airplanes, built in the history of the world. So I looked up an article that was like the top 10 fastest planes all the way up to the fastest plane, which is apparently, if I remember right, it goes 4 ,500 miles per hour.

16:10And I was saying to myself, maybe if I was doing the design for this plane, I would take more than 24 hours, something like that. But most of the time we're working with software where it's not like life and death situation. we can iterate to get to the right results. I mean, 100%. I think there are situations, especially the, I think Amazon, they call there's the two-way doors and one-way doors, right? Like things that are irreversible, right? Like, let's say you're going to damage your reputation with your customer, if it's going to affect the database, the data, I mean, like if it is a legal thing, if it is, I think there are a lot of situations, even if you don't work on a critical domain, such as airspace, right?

17:01That we should take more time and we should involve more people, right? You need some legal review, right? I mean, there are things, but if you are, let's say, building a new feature, right? Like you're doing a new flow, you have not launched, right? You're working on, still on finalizing some working solution. It's not something you're putting in production and you're making a huge change in 24 hours, right? It's something that's being built to be tested, to be then rolled out. Then I would say that 24 hours is a really good rule of thumb because you're going to have a lot to play with in the next couple of weeks, right?

17:38But if it is something that is going to affect something that's existing functionality or something that's going to affect data and something might have legal or security or privacy implications, I think you need to be more careful and it's just not moving quickly, right? It's moving safely through, right? But the context that I mentioned is the context of developing new features. Yeah, just recognize that one-way door versus the two-way, meaning is this a situation that I cannot walk back from? I cannot iterate on it because it's putting me in a legal situation, a customer situation. That makes sense.

18:16I actually have a note here. I didn't even see this. It's something we talk on this pod a lot. But that's around stuck PRs, stuck pull requests, bottlenecks. Do you have anything that you want to say about there of how you're handling PRs? I mean, I think the same applies. One of the main responsibilities of engineering manager is to be, in my view, is not someone that needs to know every single line that's being written, right? The one is reviewing every single PR, but is the one that's actively monitoring anything that's getting stuck. And PRs are usually like, is one, and PRs is another one that, especially if you have a really strong PR review culture, right?

18:59Where people really go in like in details about how things should be standardized is often like super easy to get stuck on like some disagreements on someone wanting like a big refactor or something. And engineers, sometimes they get super passionate about things, and they don't think about the way forward. So as an engineer manager, it's part of your responsibility to be, like, if the engineers are not able to sort it out quickly. Like, whenever there is a PR that's stuck in review for more than, I would say, two days, like one day, ideally, the engineer manager should have almost alarm going off, right?

19:40And going there and understanding, okay, why this has not been merged. Every time I see a PR that has 20 comments plus, back and forth, open for more than two days for review, is usually a bad sign of multiple things. I think another thing is PR should be small and it should be super quick to review and it should be high throughput. You have small batches of changes getting in and getting reviewed, fixed, approved, and moved on. If you have someone that's open up PR, let's say, once a week or once every two weeks with a massive change, and then you have, let's say, reviewers taking days to review and weeks to actually get that to a measurable state, that's a problem in the process.

20:34and on how often things are getting in the main branch. So I think then, as an engineer manager, you need to understand, okay, why are those engineers not actually breaking down the PRs? Why they're not thinking about their strategy to making chains, breaking down tasks so the PRs are going to be super easy to validate? And there is an overarching architecture of how you're planning to get the whole thing done, right? They don't need to do all changes in one PR. So I think that is the same rule applies and is another data point that you can easily, I mean, that you should be monitoring actively as engineering manager.

21:11I mean, you're honestly preaching to the choir here, like a lot of what we're doing at Linear B is to ensure those PRs are getting merged. I mean, one of the metrics that we look at the most is merge rates. So what's your frequency of PR merges? And then you talked about the timeframe. You definitely want to have it below 24 hours. And then the elite teams that are great at this it's only a few hours because that PR, I mean, you talked about dev experience, first of all. Getting my PR emerged is a great experience. Have waiting two days, three days, a week. That's a horrible experience for a developer.

21:50So yeah, I think you nailed it when you say like, as a manager, make sure that you have a, it doesn't mean that you have to review every PR. It means that you're monitoring the process so that these are not bottlenecks. And that's what's very important. So I'm really happy that you brought that one up. I feel that is another, like, I think you should be monitoring the aging, right? How long, like, for tickets, for PRs, for conversations in general, right? Whenever you see something getting stuck for more than one or two days, usually something you should be actively monitoring and actively trying to unblock.

22:28Either to break it down, right, in smaller chunks. Maybe something that we only realize now is too big. Maybe it was a problem on the process and how the engineer approached that problem, right? They found more complexity than they were seeing before. But I think it's usually a sign that you should break it down because if you let something that is already late and being super slow in the process, continuing on the process as it is, is a really bad recipe for a disaster there. Totally makes sense. If I have to move us on so that we stay on time, I'm looking at one of your most popular Twitter threads, and it's our number two topic today.

23:14So the switch gears into that mindset, I think you wrote something like, the more senior you become, there's no more, that's not my job. Now, I love that mentality, but what does that mean to you? Yeah. So I feel that like as a leader and I mean, like not only as a manager, right? You can also be like, I see it as a leader. You should not be avoiding responsibility. By that, I mean, it's like, okay, someone complain about something. Oh, we don't have such and such, such tool. Like this process is problematic, right? It's super easy to get into a super defensive and avoiding accountability and just like, okay, yeah, really, I agree this is a problem.

24:06Let me talk to the person or whatever. But I think at some point, someone has to take ownership and responsibility for that and say, okay, that's my problem. Let me see what I can do, right? And I feel that the best leaders I had, had some degree of that mentality. Of course, you cannot be a hero and solve every single problem, right? And there is a limit to that. And also, there's a limit of how much overwhelm you can get if you actually are the one that's taking responsibility of every single problem, everything that's going on. But there is a huge shift versus like, be the one that needs everything to be perfect.

24:47Otherwise, they're just going to be passing through the problem. So I think that the context there is, I think as a senior engineer, as a mid-level engineer, you can say, okay, that's not my job. This is beyond the expectations of my level. But I think once you get to manager, senior manager, to staff, principal, it is concerning in my view, and I think it's like, if I see, let's say someone that's a senior leader saying that, oh, that's not my job, right? That's someone else's problem. Of course, there are things that are outside of your control. You don't have control of the compensation policy of the company, of way too many things.

25:31But how you message that to your team and how you take accountability, okay, I hear you, let me take this forward. I'm responsible for this. I feel that I'm part of this problem is a huge shift. And I think it also puts your chain in a different state of mind to have someone that is there and is really accountable. And also, I mean, over time, folks are going to see you doing that and getting a lot of things done, solving a lot of problems versus just passing it through, right? And they're going to start to do that themselves. So it's the whole idea of extreme ownership. And I feel overall, the more senior you are, the more you need to do that.

26:13Of course, there are limits, as I said, but overall, I think that's a really good mindset shift. Well, I certainly think it's the right mentality. And I have found like as I've progressed in my career, so I'm a founder now, and we even have this philosophy at Linear B, kind of that philosophy of nothing is beneath you or there's nothing that you should say, that's not my job, that's someone else's. There's nothing beneath you to like solve a problem if you're seeing something there. And especially if you're in a founder mode, I kind of say that, okay, everything is actually my job. But you brought up a good point that there's a scalability aspect to this.

26:55And the point that I would make about that is it doesn't mean that you personally have to solve every single problem. That's kind of like a hero mode thing that will actually crush you and your team probably. But even more so, if you identify that there's an issue, even if let's take like the compensation example, which is kind of way out there. But what does a senior leadership do? At least if you're seeing a compensation problem, you go and you have a conversation with HR and you say, I know I can't solve this problem, but I want to make you aware that this is a problem with our culture. Here's what I'm hearing compensation wise.

27:39Maybe there's other companies I'm hearing that are paying more. I think we need to retain talent. I want to make you aware. And is there anything I could do to help us be more competitive? Great. At least you're not saying, oh, that's someone else's problem. No, you're connecting the dots. And on the engineering side, the same thing. Hey, I see this part of the application is really slow or something, but I don't own it. I'm going to at least go have a conversation with that senior manager and see, hey, what's going on here? Are you noticing this too? I just want to make sure that we're on top of it.

28:15Is there anything I can do to help? So that would be my recommendation in that situation. Yeah, 100%. And I feel it's like part of that phrase, like, okay, you should not say that's not my job, is a reminder. And I know he's a really strong message, right? That you should not be saying that, not even internally, right? Because your job as a leader is to be filling the gap, is to be talking to people. And I mean, if needed, is to be the one that is going to the other manager, to the other area that has problems, right? And saying, I mean, guys, this is something you should be doing. This is impacting my team.