Once you've taken that step into leadership, what foundational skills and attitudes will carry you forward throughout your career?
Continuing our series on the career journey of an engineering leader, host Dan Lines once again welcomes Thiago Ghisi, Director of Engineering at Nubank.
In this second episode, they pivot the discussion from the initial steps of becoming an engineering manager to the more nuanced subject of building a robust foundation as a leader. The episode explores the essential skills, the dos and don'ts, and the philosophies that can guide engineering leaders to make an enduring impact on their teams and projects.
Tune in as we unravel the core principles and practices that underpin success.
Episode Highlights:
- (3:20) "A bad decision is better than no decision."
- (8:30) Continuous Escalation (CE)
- (12:30) 24-hour rule for decision-making
- (18:30) Handling stuck PRs
- (23:30) No more "That's not my job."
- (33:00) The 4Ps of leadership
- (39:00) Skills managers struggle with
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Dan Lines: Hey, what is up everyone? Welcome back to Dev Interrupted. I'm Dan Lines, LinearB cofounder and COO, and we're thrilled to continue our series on the career journey of an engineering leader with Thiago Ghisi, Director of Engineering at NuBank. Thiago, great to have you back on the show.
Thiago Ghisi: Thanks, Dan. Glad to be here, man. Appreciate it.
Dan Lines: 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 first episode, highly recommend it. Everyone 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 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 as leaders, I think we should always strive for that. So let's jump right in our first topic today. Actually, I love this title. The title of our first topic is when a bad decision. is better than no decision. Thiago, you've delivered, 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.
Thiago Ghisi: I remember once our CTO when I was at American Express, And he said a phrase that I talked to the heart, that was like, For 99% of things in life, a bad decision is better than no decision, right?
And 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 will 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 stay focused on research, doing POCs, all that. one idea that I started doing early in my career, especially when I became a director was to You start to time how long, it was taking to unblock those decisions and those projects, right?
Especially when there was like, 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 like they, they would usually get to, to 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 have seen so many projects, so many things slowing down, let's say deliver of large initiatives.
Because of those things that they just get stuck, right? And no one has the, has 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 make this project. Let's move on and 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 if you move forward, right? So I'm a really big fan of walking skeletons, right? Getting that shape of the project working end to end and then iterating on that over time.
But overall, I think like this process of trying to document the blocking point and trying to time. Okay. We have this time to make the best decision we can no matter what we're going to move forward is a process that work 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're not let's say actively managing the chain or don't have a good engineer manager there to take sides or to move things forward, those things tend to like to hold for days, weeks, if not months, right?
Dan Lines: Yeah, 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 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. Type. And all of a sudden, a few weeks have gone by and the project hasn't moved forward. I 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 gotta be perfect, right?
So 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, yeah, you can go on forever. Hey, we got 24 hours here. We got to make a decision. Have you seen that, that kind of like time block, change the behavior in a positive way?
Thiago Ghisi: Yeah, for sure. And I will often remind folks that's not usually my approach to everything, right? Especially if you do something, okay, we're planning the next next year and we're exploring like the next observability tool we're going to use, right? That is a big commitment that we can take weeks to decide, but if we have, let's say a delivery that like needs to happen, right? I'm gonna like on the first meetings of that particular project, I would kind of like try to bring to the table, folks, just so you know, we are on a really tight deadline or timeline here. We're going to use this decision making or escalation process, another topic that 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. And I think like a big part of the responsibility of engineering manager is to actually be playing that role, to be monitoring like where there is tension, where is there is like...
People stuck, right? And getting the team to get stuck. And sometimes that might be inside the squad or whatever. Sometimes it might be outside, especially if you work on large organizations, right? You have a lot of dependency. You depend on the platform team to deliver something. You depend on the infrastructure to do something, right?
And there, there is another term that... We coined it back at my time at Amex. That is that is the CI, CD, right? Continuous integration, continuous delivery. That is CE, Continuous Escalation. It's 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.
You need to learn that escalating 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.
Dan Lines: Yeah, I love that. CE. The thing with an escalation, you're really like identifying a bottleneck that needs to be resolved. And anytime that you're escalating, usually that's okay. It's even better if you're coming with a solution with your escalation of Hey, we have this bottleneck.
We're going back and forth. Here's one option or the two options. Can you help us move this forward even better?
Thiago Ghisi: That should always be the case then actually 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 I need you to pick one of the options. Those are the options. My recommendation is X, right? I was reading the other day, a book called Scalling Scars. Scaling people and Stripe, they actually, they, they change the name.
They don't call it escalation process. They call 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 like those decision making process and escalation are basically way to make progress, right?
To unblock things, to not let things sit idle.
Dan Lines: Yeah. Let's see if we can get that. That's at Stripe, like Stripe engineering. Yeah. Stripe. Yeah. But 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. Sometimes you're saying, okay, maybe multiple weeks.
Do you have, 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 like, how do you decide as a manager when to use like a 24 hour rule versus something that maybe is a little bit of a bigger decision?
Do you have anything there?
Thiago Ghisi: Yeah, I feel that okay, if it is something that was agreed, ahead of time okay, we're gonna need, we're gonna take one week, two weeks to do this. POC to do this, try to do this approach. I'm fine with whatever is the agreed on, right? 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 like 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 like the 24 hour window is a good forcing function to make progress.
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. It'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 thumb 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'm fine with a couple of weeks. Usually one week is a good rule of thumb for me for... Playing out with a new tool, trying to do something, but there are things that require a lot more time, but I think giving way too much time without having structure without having weekly checkpoints, at least on how we're moving a particular initiative is also a problem you might experience, right?
So you cannot, open up too much, right? I think you need to have a structure and structure. Where like progress can be checked, questions can be asked, and we can iterate quickly. I think that's the main thing.
Dan Lines: 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. Like the way that's 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 an, make a decision.
in 24 hours, so that we can clear up some of the unknowns. We'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.
And 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.
Thiago Ghisi: A hundred percent. I think like there are situations like, especially the, I think Amazon they call, there's the two way doors and one way doors, right?
Like things that are irreversible, right? Let's say you're going to damage your reputation if you're. Your customer, if he's gonna, affect the database, the data, 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?
That we should take more time and we should involve more people, right? You need some legal review, right? 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, you're 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, that 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, to play with, in the next couple of, Weeks, right?
But if it is something that is gonna affect something that's existing functionality or something that's gonna affect data, something you 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 too, right?
Dan Lines: But the context that I mentioned is the context of developing new features, Yeah. Just recognize that one way door versus the two way meeting. 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.
I 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 any anything that you want to say about there of how you're handling PRs?
Thiago Ghisi: I think the same applies, one of the main responsibilities of engineering manager is to be In my view, it's not someone that needs to know every single line that's being written, right?
It's the one that's reviewing every single PR, but it's the one that's actively monitoring anything that's getting stuck. And PRs are usually Slack threads is one, and PRs is another one that, especially if you have a really strong PR review culture where people really go in like in details about how things should be standardized is oftenlike super easy to get.
He's stuck on like some disagreements on someone wanting like a big refactor on something. engineers, sometimes they get passionate, like super passionate about things and they don't think about the way forward. So as engineer manager is 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? And going there and understand, okay, why this has not been merged. Like every time I see a PR that has like 20 comments plus, right? Back and forth open for more than two days for review is usually a bad sign of multiple things. I think another thing is like PR should be small and it should be like super quick to review.
And they should be like high throughput, right? Like you, you have like small batches of changes getting in and getting reviewed, fixed, approved, and moved on. If you have something that's appearing, if, or if you have someone that's opened 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 on the process and like on how often things are getting in the main branch. So I think then as an engineer manager, you need to understand, okay, why those engineers not actually breaking down the PRs, why they're not thinking about their strategy to making change, 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's, is, the same rule applies and is another data point that you can easily, that you should be monitoring actively as an engineering manager.
Dan Lines: You're honestly pre preaching to the choir here. Like a lot of what we're doing at LinearB is to ensure those PRs are getting merged. One of the metrics that we look at the most is merge rate. 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. You talked about dev experience, first of all, having, getting my PR merged is a great experience. Have waiting two days, three days a week. That's a horrible experience for a developer. So yeah, I think you nailed it when you say as a manager, make sure that you have a way. 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.
Thiago Ghisi: I feel that is another I think you should be monitoring the age, 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, either break 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 is usually a sign that you should break it down because if you let something that is already. Late and being super like, is low in the process, continuing on the process as it is a really bad recipe for disaster there.
Dan Lines: 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, So 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?
Thiago Ghisi: Yeah. So I feel that as a leader and like not only as a manager, you can also be like, I see that's a leader. You should, not be avoiding responsibility by that it's okay, someone complain about something.
Oh, we don't have such and such tool or like this process is. Problematic, right? It's super easy to get into a super defensive and like avoiding accountability and just okay. Yeah. Like really, I agree. This is a problem. Let 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. And I feel that the best leaders I 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 overwhelmed 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 be the one that needs everything to be perfect. Otherwise, you're going to just going to be passing through the problem, right? 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, right? It it is concerning in my view. And I think it's 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 like way too many things, but 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 team in a different state of mind to have someone that is there and is like really accountable. And also, 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 like extreme ownership, and I feel overall, the more senior you are, the more you need to do that. Of course there are limits, as I said, but overall, I think that's a really good mindset shift.
Dan Lines: I certainly think it's the right mentality. And I have found as I've progressed in my career, so I'm a founder now, and we even have this philosophy at LinearB, 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 solve a problem if you're seeing something there.
And especially if you're in a founder mode, I say that, okay. Everything is actually my job, but you brought up a good point that there's a scalability, aspect to this. And the point that I would make about that is, it doesn't mean that you personally have to solve every single problem.
That's 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 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. Maybe there's other companies I'm hearing that are paying more. I think we need to retain talent. Is there any, I want to make you aware. And is there anything I could do to help us be like more competitive? Great. At least you're not saying, ah that's someone else's problem.
No, you're like connecting the dots and on the engineering side, the same thing. Hey, I see, this part of the applications really slow or something, or like I, 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. Is there anything I can do to help? So that would be my recommendation in that situation.
Thiago Ghisi: Yeah, a hundred percent. And I feel it's like part of that phrase okay, you should not say that's not my job is a reminder. And I know he's a. It'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 if needed, is to be the one that is going to the other manager, to the other area that has problems, right? And saying, guys, this is something you should be doing.
This is impacting my team. And it's it's someone that's actually following through, right? And making sure that concern is getting addressed somewhere in the organization. It's not someone that's just passing through and it's okay, that's not mine. Of course there are problems that you have to avoid because there are things that maybe are not that impactful, or there are things that you're not gonna have the time to invest.
But for the huge majority of the things, especially if you're a team to have someone that's frustrated or complaining about that, even if it's not your core responsibility, you should do exactly what you said. Go to HR, go to talk to the other manager, go try to move that forward yourself before saying that.
And if you have that mentality, you're actually going to be more creative about things. Everything becomes easier if you have that mentality, right? So you you know what to do, you know who to talk to, and you usually have a path forward, right? You might not be able to solve every single problem.
But you become accountable for that and take at least one, two steps forward on that.
Dan Lines: I think it's really important if you're interested in career growth, as you go from a manager to a director of a, and then to like a VP or an SVP, what I've seen is the characteristic that you are describing is a common characteristic and folks that are getting promoted.
And I think the reason for it is twofold. One is let's not mistake ourselves when you go through a promotion process, especially as you're going into a director role, because now you're really getting up there and then into a VP role, it is not only your like direct boss who will be promoting you, they're going to ask your.
ecosystem of peers and they're going to remember, Hey, did this person solve problems or help solve problems outside of their immediate area or not? If you're someone that, no, this person is good at only the one like job type, like the only like things in their lane, they're good at that. That means that you're not ready to be promoted.
And your peers are going to get asked. And the other thing that I would say is it's not always the case because titles are weird, but one of the things that someone told me once, the difference between a director and a VP and how, you're getting ready for a VP role, a director is usually excellent at executing.
On the tasks that are, directly in their wheelhouse or in their lane. And that, yeah, okay. As a director, you should be able to do that, or even a manager, let's say. But when you get into a VP role, you have to not only execute on everything that's in your lane. But you have to understand the business or everything that's surrounding your lane so that you can also contribute to all areas of the business.
Those are the best VPs. And what you're saying here with the no more that's not my job thing is actually practice for that. You're like practicing to do that all the time. So I would just call it out. It's like an amazing advice for people that, are looking to get promoted.
Thiago Ghisi: And it's not easy and you have to watch out for burnout, but I think that's like your job is to make the organization more successful, right?
Whatever that means. And that means that you take the concerns very seriously and you try your best to talk to people, to navigate, to improve things, right? To escalate if needed, right? You're not someone that just. Passive, on the problems, right? I think that's the huge, and it's exactly what you mentioned is a VP or senior leader, someone is able to take responsibilities outside the direct area of ownership and make progress, like in connect the dots, fill the gaps, right?
Dan Lines: That's right. Great stuff. Coming into our last topic here. You have, I guess you would call it maybe like a framework. Let's call it a framework. that you built called the 4Ps of Engineering Leadership. can you outline what these 4Ps are? And let's just try, let's start with a high level overview first of the 4Ps.
Thiago Ghisi: 100%. So the main idea of the 4Ps, just so before I get into that, is that, Once, I tried to quantify, okay if I have to decide what areas of responsibility our engineering manager has, what are those? And then, a leader of mine came up with the six P's and then I turned into the four P's, but the four P's is a way to see everything that you need to be paying attention as a manager or as a leader, on your day to grow. And it can actually be applied since like you start as a junior engineer. even if you are a director, VP, you can use the same framework to organize your time, to see areas you need to focus more. But the main idea is that there are four main areas of forming pillars of growth in a career in tech.
The first one is platform. The second one is product. The third one is process. And the last one is people. And the idea is like platform. What I mean by platform is actually the discipline is actually engineering, but at the beginning of your career, your main focus is to be good at the platforms that you work with.
And it can mean learn the language. It can mean learn the stack that your company is using. But at the higher levels at the platform, it actually means being. Building building leverage through platforms to your company. Be paying attention. What is the next strategical architecture change or the tool that's going to help us to scale as a company, right?
The second P is Product, and that also goes into the business side, into the user behavior. It's actually understanding the business and how your product is being used by your users, right? how the organization makes big decisions. What are the top three priorities for the next three years, right?
And it involves also how you talk to your peers on other disciplines, right? Talk to your product manager, how you talk to your designers, like everything that's needed to deliver the projects and to improve the product. The third P is the process, and by process, here, I mean everything that you have, in order to make the work done, right?
It can be interviewing, it can be reviewing PRs, it can be, like, what is your process to, let's say, onboard someone, right? It's to think about how to scale yourself. Either as an IC or as a manager. At some point you're going to be a bottleneck and like having some kind of process is one way to scale the culture that you want to cultivate.
And the last one is people. People is basically everything that we know about soft skills, everything we know about mentoring, everything we know about feedback, performance managing, growing people, like mentoring them, about facilitating meetings, everything that deals with, the complexity on the people that you work with, right inside the organization and outside.
So if you combine those four things and you think about okay, let's see where I am in my career at this point, which one of the four P's that inside my organization at this stage in my career is the one that I will give more, they'll have more leverage, and at different stages, your career is going to be about moving from one to the other.
One thing that I mentioned on the article is that at the beginning of your career, you're going to be focused a lot on the first two pieces. That's like platform and product, because your goal is going to be proficient, to understand engineering, to understand. why certain things work in certain ways and to be able to deliver things quickly to understand, what is the pain points to the user?
What is the product manager asking? What will make the most impact with all the technological capabilities we have? And on the second half of your career, let's say if you become a manager or if you go beyond staff, right? What's going to give you more leverage is actually on the process and people side, right?
Not necessarily means that you should stop all your focus on the platform and product, but usually if you're not able to scale the culture that you want to cultivate, or if you don't have good soft skills to... Mentor people, inspire people, right? You're gonna, your impact is gonna be limited by what you can do yourself, right?
I think those are the people and process are the foundation to grow beyond, let's say, what you can do with your hands.
Dan Lines: That's a, yeah, that's a wonderful outline and I really like it because... One thing that I do to start my week at work every week is set intentions for, okay, what am I trying to accomplish?
What's important? And I think having a good framework, because you can say to yourself, okay, where do I need to be on platform? What do I need to think about for product? What do I need to think about for process? What do I think about for people? And it's not always going to be balanced, the amount of effort that you need to put in ones, but maybe if you're coming into the week and saying, okay, this kind of is how I balance and round out all of the areas.
So I'm not avoiding one of these or too much on the other. I highly recommend thinking about, that intention setting for each week. And I wanted to ask you, is there one of these that you see, managers or directors struggle with more than another.
Thiago Ghisi: I would say the platform side, if I had to pick one, I think everybody knows process, people and product, the business side, but not a lot of managers keep the eye on the platform. By platform here, both okay, the technology you're using, but also, be able to have a good understanding of actually how things work in reality, right? I think like at some point in your career, as you transition to manager, senior manager, folks lose track of Okay, how things are actually working, what are the architecture problems in reality, right? And they start to talk at a level that's way too abstract, And I feel that there are ways to keep that, let's say technical grounding, there, even as a manager, like for example, participating on whenever there's a post mortem of a incident you have, like reviewing big RFCs, going over the code base, taking a look on a few PRs here and there, reading and playing around with the tools you're using for your pet projects at home, right?
I think those are things that are really hard to maintain, like yourself, sharp to be able to contribute. At the director, manager, director level on the platform side. I feel that a lot of managers, they completely delegate that to their staff engineers. And they don't even have, let's say, the they skew or the ability to argue and to bring their points because they're way too, show off on that, that they they just trust and they depend that person or that group of people, To be there with them on every single meeting where they are not able to represent them.
I think that is a problem. And I think it's something we're seeing the industry kind of shifting to have more, engineering managers that are technical. But I feel a lot of times we also get that wrong and we go to another extreme of being technical means you're actually coding and managing.
No. Being technical is like you're able to navigate all the architecture, able to understand, okay, where is the problem? are some strategic investments and why, And you understand at high level how the infrastructure on AWS or your cloud works. There are a lot of areas on the platform that are not at the coding level.
And I think is something that folks usually get either too deep or too high level.
Dan Lines: I think it's one of those things that's easy to let slip away, because you're getting all these, there's three other P's, two of them are new for you, if you're going, if you're like a first time manager.
But yeah, I guess the only tip, and that happened to me too, and I had to, it's tough, you have to catch yourself. Whoa, wait, I don't think I really know how this works anymore. I didn't contribute well to that conversation that I used to. One tip that I do have is sometimes you can. Combine two of the piece together.
And what I mean by that is you could use people in platform together. So for example, let's say that, an engineer, maybe just a individual contributor developer, that's working in that area or built that piece of code that you don't know much on quick one on one with them, one, you're going to.
Boost on the people side. You're going to get to know them, see what's going on. Hey, could you explain to me what you did here? It seemed really interesting. I'm trying to catch up. You want to talk about it? And they'll love talking about what they built. It's like what they want to do. And I think that's a way that you can save time with like people and staying close and you talk to everybody.
So you really know, and they'll tell you the real problems in that area too. Once they, like the engineers, like the developers know where the weaknesses are.
Thiago Ghisi: Yeah, exactly. You should use your one on ones to actually get deep on those things. And also to ask different opinions, right?
Because you have different engineers that have different knowledge at different like levels of the code base. So if you ask one, they say, this is the worst problem that we have. We should fix it now. If you ask another one, No, there's not a big issue. There is actually another way to solve this, right?
And you start to build this picture in your head of what's actually going on. And you don't think of a single data point as. Okay, that is the view of how things are, right? But I feel is yeah, combining your one on ones to actually get deep on the platform is a great idea. Another thing is you should look at your calendar, and Semi like how much time you're spending each one of the four P's every week.
So you have a lot of project status meetings. You have a lot of one on ones, but you don't have a lot of, like a lot of time to either read docs , comment on things, right? Or even to do deep dives with your engineers on certain areas of the code base. That's a problem, right? You should balance that to at least have a couple of hours every week where you are investing proactively on those dimensions, right?
On the process, on the platform is often where I see a lot of, challenges to prioritize because those things are easy to ignore on the short term, right? Because you only need to deliver it and you only need to keep your people, let's say, growing and, I think career wise feedback, but on the platform and on the process where you're actually going to get the most leverage for the longrun.
Dan Lines: Amazing advice, Thiago. I'm going to get us out of here on time. So thank you so much for coming on the pod. It's been such a pleasure to have you on the show. We had you for two episodes and I still feel like we could probably do a third. Or fourth, and I want to make sure that we give you a little bit of a shout out.
You have your own podcast. Can you tell us a little bit about that and where we can listen?
Thiago Ghisi: Yeah. Thanks, Dan. It's been a pleasure and I would be more than humble to be here next for another episode. I think we have a lot to talk about. So my podcast is called Engineering Advicd You Didn’t Ask For. It is myself and four others.
Engineering leaders that together we have 50 plus years of experience in the industry. And we talk about a lot of contentious topics, such as how to get promoted, how to navigate the org, how to grow, to be a manager of managers, right? like side projects. Like we, we had a lot of a lot of topics we cover and we are just, we're actually releasing the last episode of the season this week.
So this is going to be our second season of the show, and we really proud of it.
Dan Lines: That's amazing. So everyone, please be sure to check out at least the second season of Thiago's Pod, Engineering Advice You Didn't Ask For. And before we go, don't forget to check out the Dev Interrupted Substack for more insights and discussions from our top.
Engineering leaders. And if you have found this episode valuable, please share it with your network. Thanks for listening everyone, and we'll see you next week with another installment in our series on the journey of an engineering leader. All right.
Thiago Ghisi: Thank you, Dan.