How do you become an engineering leader? Is it the right fit for your career? And if you do, how do you become a good one? 

In this multi-part series on the career journey of an engineering leader, Dev Interrupted answers these questions and many more by inviting expert guests from the software industry to share their experiences, lessons, failures and triumphs as leaders. Whether you started your career today - or 20 years ago - this series has something for everyone. 

In our first episode, host Dan Lines is joined by Thiago Ghisi, Director of Engineering at Nubank. Together, they explore the nuances of beginning a career as an engineering manager: from acing the interview process and securing a promotion to confidently navigating your first 3 weeks on the job. 

Join us for a series of real-world lessons and insights from top engineering leaders.

Episode Highlights:

  • (3:45) "I think I'm ready to be a manager."
  • (11:30) Retaining your technical skills as a manager
  • (16:30) Misconceptions: moving from IC to manager
  • (23:00) Interviewing: tips, tricks & ways to stand out
  • (34:30) Your first 3 weeks on the job
  • (40:30) Signals you're on the right track

Episode Transcript:

(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)

Dan Lines: Hey, what's up everyone? Welcome to Dev Interrupted. I'm your host, Dan Lines, LinearB co-founder and COO. And today we're joined by Thiago Ghisi, Director of Engineering at Nubank. Thiago, welcome to the show.

Thiago Ghisi: Thank you, Dan. It's a pleasure to be here. Thanks for the invite.

Dan Lines: Yeah, of course. It's awesome to have you with us today, and I'm gonna give a little bit of a background about you.

You've worked for startups in Brazil and the us I think you've been, as we were talking before the show, you're 10 years in New York City now. Almost there a lot almost there, almost at 10 years now. A lot of major companies that we've all heard of. Places like Apple, American Express, ThoughtWorks, so some big time companies.

And through your time at those companies, both big and small, you've done it all. So you've been a software engineer, you've been in qa, a project manager. I have a note here about SRE even and now today, engineering manager, and I think you're a director now, so even more management. And you've really made it your mission to help engineers, managers, help teams grow, which is why you are the perfect guest.

To kick off Dev Interrupted series on the career journey of an engineering manager. So this is gonna be a multi-part series. It's more of a collection of stories. It's about learning, it's about experiences, lessons, failures, triumphs. From leaders just like you. So in this first episode now, we'll be discussing how to get your start as an engineering manager, how to stand out in the interview process, what it means to be a manager, and how to take your first steps once you become one.

So we have a packed show today.

Thiago, let's kick it off. I think the best place to start is when an engineer comes to you. So an engineer's coming to you and they say, Hey, I think I'm ready to try out being a manager. What's your first thought?

Thiago Ghisi: That's great. I have had that happen to me like a bunch of times and I think It would depend a lot on the profile of that engineer and my previous history working with them.

But in general, I would expect that person was really doing some kind of leadership job, even an IC, so if it is someone that's just coding all day long. Hate meetings does not have any soft skills. It's not like communicating. Usually I, I have concerns about that, but if it is someone that I see that is already taking some additional responsibility, that's already communicating across not only engineering, but also talking to designers, talking to the product manager, talking to dependence that we have on the project, right?

Someone is already doing a little bit of work across. I would say that's more like a time of okay, how can we make that happen? Because I, I'm usually really comfortable with people transitioning to management and trying it out, right? The other thing is I have, I would say, a strong opinion about.

How, let's say if that person is more like a generalist or more like a specialist, because I tend to feel that managers are more successful when they have a more diverse and a a little bit more. Fullish generalist background because a lot of management is about navigating on different domains, connecting the dots, connecting people, right?

And not only the one that knows the most about a particular platform or the one that has spent years on a particular domain, a particular language, or some, someone that is really, has only seen and has only done. A small part of this tech. So that concerns me a lot a little bit. So I would say those two things okay, what was the background what different language frameworks, what different parts of this stack they have worked on?

And are they already doing some kind of leadership? Are they already seeing as a leader by the other, more junior ics? I would say those are really good things that you should watch for before. You start to transition someone to management, because those could be red flag. But even with those true things, I would say not everybody's gonna and not everybody's gonna be successful as a manager because Yeah, for different reasons.

But those are good, really good indications.

Dan Lines: I'll steal something from you. So you've made a lot of, I think, great LinkedIn posts. I think you have some articles and stuff like that, and I read a few of them before. One of the things, it's actually a tip from you. If someone comes to you and says, Hey, I wanna be, a manager now the first thing that you can respond with is why.

And in my career, so I've had a lot of people come to me with this, and I think when you start out with why, first of all, you can weed people out that it's not the right track for, so I'll give an example. So if someone comes to you and says, I wanna be a manager, you ask them why and they say I really wanna grow my career.

I need more money. I'm like stuck being like a individual contributor. I don't think there's like a good career path for me. That's a red flag. And actually what that means, and this is something that we're focused on a lot at LinearB with our, people management, person, Jess. Sometimes it means there's not a good individual track and that's not expressed.

Meaning, yes, there's junior engineer, there's engineer, there's senior engineer, there's staff engineer, there's prestigious, you're elite. So sometimes it means that they can see a clear path for career growth on the individual contributor track, and you wanna hit that right away and say, Hey, I don't think you really wanna be a manager.

I think you want career growth and let me talk to you about an individual contributor track. So that's one thing. Now, on the other side, I really like what you're saying if they're coming to you and saying, I really wanna make people better. I wanna make sure our projects hit on time. I wanna make sure that, engineering's work gets out there to the customers and it's really great.

I love hearing those kinds of things and one of the things that I found in terms of a good sign you mentioned a lot of good ones, but the one that I would add, usually they care about like quality and they care about support. And they're like listening, oh, this feature, we can't get out to production or it's having issues.

They're connected with their local, I call it like their local ecosystem. So it's like quality SRE support. Yep. And then af after that very tight-knit with product, then into marketing and all of that. But I think that's a good, I always found if they cared about quality and they wanna get the feature out there and they care about support, that's a very good sign.

What do you think about that?

Thiago Ghisi: Yeah. No, I love that. And the why question is, yeah it's is the first thing you should ask. And I think if you are working with someone for a while you already know the why. But I think it's worthwhile asking, like either way. And the other thing I would say is another bad answer is the on the why is oh, because I don't want to be technical anymore.

Oh, because I only wanna do the people side. So that's also a red flag on the other side because engineering managers, co engineer, and we're expected to stay technical and to be able to give feedback to look at the architecture. But of course, you're looking at the more higher level vision.

But the point you said about, for example, if they are already doing some of the job and if they are like, oh, I want more money. I don't see how I grow beyond this point is a big red flag for the company and like the company should fix that and make the career ladder. Crystal clear.

the other thing you said, I think that's a really good, I would say green flag. A really good sign is that if someone wants to do that, because they're seeing problems that are really hard to solve as an IC, right? Either public championship problems or either pain points on the customer experience, and they know that.

An IC, they're gonna have a much smaller scope. They're gonna be looking at one or two things at the moment, and as a manager, they can have a a little bit more broader impact and talk to more people influence in some other places, right? Because they're not gonna be only in developing on the different piece of the code base.

So I think that is, that was actually the reason why I transitioned to management because. I was seeing those problems. I was already acting as a manager doing a lot of that during my day to day, but trying to balance, to do the IC work at the same time, and that was impossible. And you see a lot of people getting burned out on that, right?

Yeah. Trying to do both jobs for a while is good is a good experience to, to not formally have the role but been doing the job. But after a while, it is exhausting and impossible.

Dan Lines: Yeah you touched on so many good things there. One thing that you said was you have to stay technical. One of the best engineering managers that I've ever seen is actually my co-founder, Ori, who's our CEO now, Ori Keren.

He stayed super technical, but also had all of the skills around management that I think we're gonna touch on. That you need to be successful, making people better, seeing the big picture talking. And I do wanna just point out that if you get too far away from the technical side, which is maybe one of the misconceptions, we'll get into misconceptions.

then you lose like the ability to actually make good decisions and know where to spend your time and make people better. So you do gotta stay technical. One, thing that I will point on and then we're gonna go into misconceptions of management. You said something I think if someone came to you and said, yeah, I don't wanna stay like super technical.

One thing that I will point out, since we're talking about careers, High demand right now for people that come from an engineering background that move into a product manager role. So you started as a software engineer. Now, every company now is like a, mostly a software company and a, there's a lot of amazing technical products out there.

And if you have an engineering skillset and then you transition into a product manager, oh my God. That's a, now you have the double threat, you know how engineering works. You can relate well to engineers, then you learn how the customer works. So just pointing that out, if you do hear that maybe product management track for that person.

Thiago Ghisi: Yeah. And you stay super technical is here, right? Even as a pm you can. Keep like looking at the code, keep looking at architecture. But you're of course gonna be looking at different perspectives. It's a different angle, I used to say, I like to say that the being technical as an engineering manager is different than being technical.

Technical as I see right as the engineer because, the way that I look into that, if you look into the C4 model, I dunno if you're familiar with that. The c4. The c4, c4. No. Tell us So C4 is a way to, basically design assistant architecture basically to, to draw out how your architecture is broken down and C4 stands from the four layers.

So it's Context con containers, components and codes, right? So you see okay, what is the context around, what is the system context around this, this architecture, right? Okay. This talks to external system, has a database. Then you get into the containers that are the deployables.

Then you get into the components, right? And then you get into code. So as engineering manager and also as a product, a technical product manager. You have to look into, especially the top three levels, right? And but not much in details on the components and on the code side. But you have to understand exactly okay, who used this?

What are the bottleneck? At the container level, and of course get deeper on the components so what are the different models you have on your system that are causing troubles? What are the responsibilities? If someone is doing a big refactor or a big thing, you know exactly what's moving, what connects with what you are able to be on the on call, right?

If something is breaking, you're able to, okay, I need to restart this. I need to do this. The database is running out of space, whatever it is. you have that context and that allows you navigate, allows you to talk to engineers to estimate projects, right? Because that's the only way you're gonna be effective, right.

As a leader. And also to have some respect and a shared language to. To continue to be engineer in some sense. Yeah. So that's the difference is like, why are the engineers looking at the micro level, the engineering managers looking at the more macro level in terms of the architecture.

Dan Lines: Yeah. That's probably the biggest difference. So the, you just came up with the four Cs or the four Cs paradigm there? The last time that I heard about the four Cs, it's when I bought a diamond. Ever buy a diamond? Cut. Oh, clarity, yeah. Color. And Carrot. Yes. I had to look it up. Yeah. A fortune. Yeah.

Thiago Ghisi: C4 model is actually is not my invention. C4 model com is is a guy named Steven, I believe. But I have to check. 

Dan Lines: Let's jump to misconceptions. Are there any top misconceptions that we didn't, hit on that you'd wanna put out there for people?

Thiago Ghisi: I feel that, maybe a misconception or something that people undermine or don't actually know how much effort it is around aligning people and around, I would say managing people, but more on the performance management side. Performance review, performance cycles, all that.

I have seen a few managers stepping sideways back to IC after experience, like a year of like performance reviews and have to go to that cycle as a manager. So on the alignment side, I think people undermine how much effort it is to try to convince a bunch of people a bunch of different.

Squads or to go on a single goal, end to end, right? And there will be people with strong opinions everywhere. And your job as a manager, is gonna be cut through the noise, right? And to get those people to be okay with paths that they are not super happy about, right? So especially if you want to have high performing teams, right?

You need. That ability to go on, understand the architecture and to align people. Because if you just let the gravity happens, let's say the standard is people are gonna be blocked, people are not gonna make decisions, right? So y your job is gonna be to be a facilitator, but more importantly, to be working the background to align people and to make sure that they're able to converge, right?

So that takes a lot of effort. And on the people management side, I think. Giving feedback, especially when it's not well received, right? And having to present promotions or like on calibrations, have to defend a particular case, right? For high performance. All that, getting pushback from other managers, not being familiar with that is a super scary area and is a completely different skillset than you will use as an engineer.

So I think those things are things you should be aware of before. And of course there will be with that a lot more meanings, a lot more. And I think there is a limit of how much you can optimize because you're gonna be doing one-on-ones and, but I think like the things that are gonna be consuming a lot of our energy around alignment and.

People management, career management is hard. It's hard to give feedback and especially when people are not really open to that. And you need to sustain that for a while to then get a little bit more comfortable. Because if you just stop on the first time, you get a pushback, you're not gonna last.

Dan Lines: I think you, you nailed it. I can comment on each, so the role, there's a lot of talking, there's a lot of communicating, there's a lot of translating, so you're gonna go from isolated time on the keyboard, headphones on, diving into the zone to meetings, communication, translating what things mean to different people.

you can tell if someone's gonna be good at that. So yeah, of course. A few tips. Is this person a good order or communicator? Can this person translate from engineer to engineer, but also engineer to the business? Who's the business product, c e o, marketing, that type of stuff.

in my career, like I can usually tell who would be good at that. And again, some of those indicators before already working with the internal ecosystem. I think it's the second one that you said that trips the most people up, which is the people management. because that is a whole other thing, you're gonna have people.

And I don't wanna discourage I was an engineering manager. It was awesome. It launched my career to be honest. But yeah, people are gonna come to you, Hey Dan, I'm not happy. I am having trouble with this person. Or people aren't performing well. You gotta let people go. You gotta hire people. People are people, they have all different types of problems.

Problems will come your way. Could be a Friday afternoon, you think everything's clear. Hey, I'm really unhappy work, working here. I gotta, we gotta talk. Okay. So you gotta be on and you gotta be, it's just a next level of, emotional intelligence working with people. Yes. And that's the one that I, that's the part that I've seen people go from, Being a manager back to IC more than any, anything else.

Thiago Ghisi: Yeah. Yeah. Yeah. I fully agree. And, you remind me of, additional two things actually. One is it's super hard to be managing at first time, and especially hard to be managing someone that used to be your peer. And if you're gonna be a first time manager, a lot of times that might involve managing people that used to be your.

Your peer in the company. That's, and the second thing that I think is a good indicator if someone is gonna be successful as a manager and might be controversial, is how much heat can you handle? When you have a really tough meeting with C level or VP level, like saying that the project's not going well, or that whatever you're presenting is not that good, right?

How does this person handle or have, has handled this in the past, right? Can they stay calm? Can they put a plan together? Are they humble to admit that? Or are they more the explosive kind of like people that are not able to stay calm, stay in control when those stuff situations happen? Because your job as a manager is gonna be to calm down, to put a path forward. And if you're not, If you have a history of not being able to handle those situations right, and having your manager to be the one calming you down and putting you on track, you're gonna be by yourself.

Dan Lines: Yeah. A lot of that is conflict resolution. Some of it can be taught, but honestly I think it's like a DNA thing. I think you either have it or you don't. So yeah, I mean that, I think that's something to identify within yourself before deciding. I will move us on because the next one is very interesting.

We had this topic titled How to Stand Out in Your Interview. So how can someone shine in the interview process? What do you look for?

Thiago Ghisi: That's a tough one. So just as a context, so I. I had spent a lot of time trying to get better at interviewing throughout my career, and that was the shame that got me a job abroad and allowed me to move from Brazil to the us and, one of my goals, like couple of years back was to help more engineers to move abroad to get better high in paying jobs. Because I remember

Dan Lines: Are you saying from Brazil?

Thiago Ghisi: From Brazil. Brazil from Brazil. Yeah, I would say more developing countries. Yeah, because I think Brazil is just one of many,

Dan Lines: Brazil's got like an amazing startup thing going on.

Amazing talent, awesome, amazing people, awesome stuff.

Thiago Ghisi: Engineering wise is, yeah, is incredible. And I'm working mostly with Brazil these days. Nice. The majority of my team is based in Brazil and I'm super glad on that. But okay. On my interview, so I would say there are a couple of things, right? That is they like interviewing as ic. That's one thing. Interviewing as a staff engineer, that's your ic, but the expectations are different. And that is the other thing, interviewing as an engineering manager, right? There are a few things that I can say about the technical aspects, right?

So when you're going on both sides, like the code interview system design, right? I think like on, on those things like. There is no easy tip or thing that I can say is it's gonna be a mix of experience and practice, right? Like, how much have you been trying out those things? And it is gonna be really hard to, Be a great interviewee.

if you ha if you don't have experience or if you have not done those kind of exercises before, because those are different things than you do on the day to day, that is a relationship, but at most, you have to prepare for that. But I think that the thing that I emphasize the most, Is about the behavior interviews and especially for manager.

I think that's what is what break most people on the interview process because they don't know, they either don't have a structure or framework on how to answer those questions. They don't have an inventory of things that they have done to showcase on those when they get those questions right.

Or they talk about, the we and not about the I, right? They don't talk about their specific contributions, right? They don't sell themselves. I think that's another problem. So I would say on the system design and coding side, I think the best thing I can say is do a lot of peer programming, a lot of mock interviews, and.

And that's the only way to go and design a lot of systems. Like I think that's where you're gonna be more successful. On the behavior side, the thing you should do is every job you have you should at least have like top three to five stories, top three to five accomplishments, challenge you had.

And then whenever you get those questions right, oh, tell me about a time you had a conflict with a peer of yours. Tell me about a time you had to manage a low performer, right? Those like maybe top 20, top 30 questions that like people ask in behavior interviews. You have a story behind it or you have a framework, right?

Every single behavior interview question you, you're gonna answer using the star methods, right? That's the situation, task, my action, and the results, right? And of course you should not spend 10 minutes on that, or you're gonna answer as a framework, because that is where especially manager and staff engineers struggle the most, is that they get a question like, oh, tell me what you look for when you are, let's say, designing a new system.

That's a framework question. They don't want to look on histories, right? They don't want you to tell the last time you designed a, his assistant and what you did. They want to see how you think. And if you don't have a framework on how you operate, it's gonna be really hard to convey.

You're gonna be like waving hands and running circles. and the final thing is write it down how your answer to those like well-known questions and have Friends of yours or mentors reviewing and commenting on that, right? What looks good, what's that's a little bit shady.

That's not a good example. Yeah, because once, and the fact that you are not gonna be using the script, but the fact that you wrote before and it took the time to like nail down the bullet points on how you would answer, I guarantee that your performance on the interview, how you're gonna convey is gonna be much, much better.

So I think those are the things that I would say.

Dan Lines: Super smart stuff. A lot was going through my mind while you were giving those great answers. And I'm gonna try to summarize. So first and foremost, the difference between a good interview in a manager and a bad interview. A bad interview is everything that you say is really vague.

A good interview as you're coming with specific examples. Of here's the situation that I was in, here's how I handled it, here's what I did, and here's what the team did. So here's what I did, here's what the team did, and here was the end result specifically. And yeah, if you think about the perfect answer, I'll try to give like a perfect answer cuz you're gonna, what the interviewer wants you to do is give specific answers of what happened.

So the perfect answer if someone asks you like hey, we're in a situation right now where we're like changing our agile methodology and how to set up a team. How have you set up a team before? How do you view the team that you manage? Here's I'll try to make up a perfect answer on the fly, but of course, First and foremost, I believe in the Spotify model.

That's a framework, the Spotify model. So I believe in squads, guilds, and chapters. That's what I like the most. Now, what we did specifically, cuz I've been through this, is I set up my squad and I, it was a group of engineers who had all the skills. I had ui, I had F full stack, I had backend. We were able to deliver.

But what we did is instead of using chapters in the Spotify framework, we actually did X, Y, and Z. Perfect. And what happened when I rolled out this framework was this and that. So I can't, say exactly on the fly, but there I came with a framework. I said how I rolled it out and adapted it.

And then the outcome was, hey, it went really well. But if I would've done it again, I would've changed this other thing. That's a really dope answer. Now you have to have that answer for every single question and you'll probably get the job.

Thiago Ghisi: One thing I would say is there, there's additional thing, but let me try to summarize. So whenever you are on the behavior interview and you got a question. There are two things you need to ask. Is one, is it, star method answer, or is a framework answer, right? Because in the example you gave is clearly a framework, right?

They're not looking, oh, tell me about last time you set up, I don't know, a squad, right? They're asking a broader scope, right? Tell me your philosophy around that. What do you look for and. When you answer that, you need to be specific about and answering, oh, I use this Spotify five model, and stopping there is bad.

It's pretty bad because like the reality is really different than theory, right? We know that people that are in the industry know that. And the second thing that I forgot to mention is at what level I'm interviewing for, right? So if you are interviewing for a senior engineer position, Whenever you're answering both the framework or the the historical like story, right?

You look, okay, let me show how I have performed. As a senior before, if you're interviewing for a staff or for a director position, you don't wanna hit hear, answers that that are like either five, 10 years old or that. Give the impression that you have a much smaller scope than you had, or you're working on issues that you should not be working on because they're not at the level of your level of competence.

So those two things are really important. And if you miss one of them, you're gonna be like off on a tangent. And there is, the last aspect is you should also not be speaking for five minutes and telling stories and you wanna give just Small appetizers to get the interviewer like interested and actually asking you more and going deeper and like just unlocking new things.

Unlocking more insights. And you you almost, you wanna leave things unsaid for the interviewer to ask for you to then knock it down. That's the perfect answer. You get into things, you say something and they get curious and you say something more deeper and oh wow.

That's the impression you wanna leave.

Dan Lines: Great point. So I think we gave like some amazing tips here and then I'll finish it off on one. One thing that you said, if you're interviewing for a manager position and you've only ever been an individual contributor before, I highly recommend going from individual contributor to manager in the same company that you're in because one, you get all of that benefit of knowing the technical.

Details behind the scenes cuz you've already, and also, it's very low chance that I'm gonna hire a manager who's never been a manager before, not from my own company. So promoting from within is the way to go. And then after that you can look at other companies to be like your second manager job or director or something like that.

So I think that's a make sure, yeah. Promote within for your first one.

Thiago Ghisi: There is one thing there like transition into management is already a pretty difficult thing to do. Doing that on a context on where you have zero knowledge of the product, the people, the process, is even more like I think possible mission, right? Is and that's the reason why so many companies are superior skeptical about someone transitioning from the IC to management, like on an interview, right? Like you have to transition. Extracts inside a company already have context. Yeah. Because that's the way you're gonna be able to see, that's the way you're gonna be if you have some like low points and why not?

You have some credit or some goodwill that you conquer before in the company, right? So you get that motivation and you also get people to support you if you are not that great at the beginning. But joining a new job if you have never done before as a manager. Impossible.

Dan Lines: Yeah. Yeah.

Impossible. Okay, let's move to our last topic. Again, this is gonna be a multi-part series. So the last one for today, let's go on how to onboard yourself as an engineering manager. So this is around how do you get a successful start? You've interviewed you, you've become a manager. What are some tips, maybe first 30 days, 60 day, 90 days to get started off on the right foot.

Thiago Ghisi: I love that. I remember I posted on LinkedIn last year on a post that went viral and it was it was not idea from me, actually. It was idea from Dave Anderson that has amazing newsletter on management. And So usually people talk about the 90 days, right? That okay, three months onboarding.

Right? And David had this thing that I love that was like, you should be able to onboard yourself and get up to spending three weeks. Here's how. But I think like he, he focused on things that I like a lot. But I would say in general, right? I think you wanna understand three big aspects, right?

One is the people aspect, right? Especially if you're talking about onboarding as a manager. The other is the product or the problem space, right? You understand who are the users, what are the pain points, right? All that. And the last one is the systems or the architecture gonna be operating under, right?

What you have running in production, like what does what system is integrated with what, and getting into that picture in three weeks is definitely possible. And, I think I like to start with the people aspect, getting deeper there and then start to understand the product. And then only after getting deep.

Into the ecosystem, into the engineering, doing deep dives and all that. But I think like there are ways to build a three week plan that you're gonna get at the end fully up to speed. And if you feel about those three big areas that you need to know and you need to be aware of, like who are the people, like what they're doing, what are they concerned about?

Who are the people that are able to, let's say, help on one particular area? Who are the people that are able to help? And inside people there is who are the partners, right? Who are the people inside the organization? Especially if you work on a big org if you work on startup, I would say that's more external PA partners, right?

But who are the people that can help you? Who are the people that depend on you, right? Who are the people that, are gonna be asking you for stuff, right? So I think those is really interesting to create a map, not only on the team topology, but also on the external dependence. And of course talking to each one of those people asking then, okay, who else do you feel I should talk next?

That would help me to navigate as a manager's director. And on the systems engineering side, I feel is getting a couple of the. The ICS is a good opportunity for them to connect with you and doing some whiteboarding is a great thing. And mapping also the playing field, I would say.

And on the product side is a great opportunity to talk to customer service to. Talk to your product product leads, right? Understand the roadmap. Understand okay, the dates, the timelines you have ahead of you. And if you're able to get a sense of those three things, I think you're pretty much onboarded.

It doesn't mean you're gonna be at a hundred percent Yeah. But you are gonna be set for success, right? So I would say those are the things that I would look for.

Dan Lines: That's cool. I really like your idea to start with the people. The other thing, when you start with the people, they will like your, the developers that are reporting to you, they're gonna use that as an opportunity to tell you about the pain points in the system.

Hey, I really check out this poll request. This is an example of something that's not going well. or, okay. Check out this area of the system. I've been really str like they're gonna tell you what the pain points are and when you meet with everybody, you're gonna have an idea.

Oh, okay. Now I know where to dive in. And then the other thing I would say is maybe that not every team has this, but maybe, there's an architect or there's another like director. Hey, could we sit down and do a whiteboard session of how the system works? Where are the strengths of the system?

Where are the weaknesses? What are we working on next? Where is this evolving to like that? That can help, I think a lot to accelerate.

Thiago Ghisi: Yeah. Yep. The other thing I would say I think is really important to use your onboarding as a validation step, especially towards the end of like the second or third week You want to be the one that's validating, with the people that you're gonna be working with. Okay. Those are the problems. you wanna have the people that told you the problems hearing from you to make sure that your interpretation is actually correct and you might have more insights, connect problems together, but you also wanna be proactive on that sense.

You wanna, you don't wanna be just reactive, just absorbing. And the way to do that as a manager is to putting yourself in positions where you are presenting things where you're. Trying to summarize, digest those informations, because that's where you get the feedback. No, that's completely wrong.

That, oh, that's on the right path. And people also get to trust you because, oh wow, two weeks, they're already saying the problems. They're already understand the relationship between things. They're already asking questions that I don't know the answers for. So I think that's is a great thing to keep in mind during your onboarding as well.

Dan Lines: You said it there, but let me ask you the direct question. You're a director and you bring on a new manager that's reporting to you at the end of two weeks or at the end of three weeks. What would impress you, or what would be the signals that would show that, oh, this person's like on the right track?

Thiago Ghisi: I would say two things. One is someone that would bring me concerns. They have. Either regarding people or regarding things that they don't understand or they're like, like they are confused about like for example, one, it could be, okay, I talked to this people, and I felt that this engineer is not happy, or that is a conflict here, right?

That one is able to map some action points, some hotspots, right? And on the other side, someone has really good questions about. Why are we doing X if the problem that we have to solve is X? And if you have this tech that to do right? Or like, why have we not done the design of the system this way? Someone that is is able to articulate great questions that like, so sometimes you, even, you like as a director or as a manager that has been there for years is like, Wow, that's impressive.

Or is okay, that's great. I, let me give you some context. That is a good indication that they got deep enough to be able to like, make some connections and ask questions, and that means that they're really going like on the right track in my opinion.

Dan Lines: That's cool. Yeah. It's almost if I came on and I was reporting to you it, what would be really badass is in the first week.

I set a meeting with you for two weeks later and I said, Thiago, I'm setting this meeting with you, which is gonna summarize what I learned in the first three weeks. And if I came to that meeting and I had your categories, I said this is what I capture from the people side. Here's the things I think is going well.

Here's some of the things that people raised to me that I wanna put on your radar that we should start looking at. Here's what I captured on the architecture side. And I wanna confirm or deny with you, I think we have debt in this area. Do we need to prioritize that? What do you think?

This is what I, so now we're having like this back and forth conversation about what I've discovered and what I think we should do next. But is it in line with what you think or am I off here? No, you were, that would impress you. That's good.

Thiago Ghisi: A hundred percent in line. Yeah. If you're able to summarize and validate what you learn and what is next, or what you feel should be different or you're confused about, I think that's like a pretty good indication.

A bad indication would be someone after three weeks is still asking questions like who should report to me?

Dan Lines: Or you're not hearing from them. They're silent. Yeah. Yeah. Yeah. Yeah. Okay. Hundred percent. So I think this is a good place for us to cut cuz we're gonna do a part two.

So we have a part two coming And I wanna thank you so much for coming on the pod. We're gonna continue the conversation. But before we go, I always like to give our guests a chance to talk about something and we were talking, before the pod star that you actually have a podcast. So let's have our listeners here.

What do you have cooking on your pod?

Thiago Ghisi: Amazing. So we started this podcast called Engineering Advice You Didn't Ask For last year. We did season one last year. Is free and available on YouTube, Spotify, everywhere, in this season, that we are releasing. We finished recording a couple of weeks back.

We're releasing now is like 10 episodes, and we're doing that now on substack and it is half. It's half free, half paid, right? And we're not gonna be releasing on the platforms is the experiment we are doing to see how much value are we adding and if that is a model that can help us with some costs that we have.

So really excited about this season 2. We had we really deep discussion with people that have been the industry for 10 plus years as managers, staff, engineers. Yeah, I would love to hear the feedback, but that's what I wanna leave here. Engineer advised you didn't ask for. That's the podcast that I have been working on for the past few years.

Dan Lines: Very cool. We'll make sure that we include the link to your pod. So thanks everyone for listening. We'll see you next week with another episode from Thiago. He's returning to talk about how to build a strong foundation, of skills that will allow you to get promoted now that you are an engineering manager and to carry with you for the rest of your career.

Thank you everyone.