Career Journey 1: Interviewing & Getting Promoted | Thiago Ghisi

0:00I 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. And also, it's very, very low chance that I'm going to 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. Hey, listeners. We spend a lot of time at Dev Interrupted talking to leaders about what makes them and their team successful.

0:42But how do you know what makes an engineering team great if you don't have anything to compare it to? Mark your calendars because the 2023 Engineering Benchmarks Report is about to be released. And to celebrate, Linear B is hosting a 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.

1:21The 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. Register today at LinearBee.io slash events, or use the link in the show notes. Hey, what's up, everyone? Welcome to Dev Interrupted. I'm your host, Dan Lyons, LinearBee co-founder and COO. And today, we're joined by Chiago Giese, Director of Engineering at Nubank. Chiago, welcome to the show. Thank you, Dan. It's a pleasure to be here. Thanks for the invite. Yeah, of course. It's awesome to have you with us today.

2:04And I'm going to give a little bit of a background about you. You've worked for startups in Brazil and the U.S. I think you've been, as we were talking before the show, you're 10 years in New York City now. Almost there. 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 kind of 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.

2:52and 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 going to 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.

3:39So we have a packed show today. Chiago, let's kick it off. I think the best place to start is when an engineer comes to you. So an engineer is coming to you. And they say, hey, I think I'm ready to try out being a manager. What's your first thought? That's great. So, I mean, I have had that happen to me like a bunch of times. And I think like it would depend a lot on the profile of that engineer and my previous history working with him or her. But in general, I would expect that that person was already doing some kind of leadership job, even as I see. So if it is someone that's just coding all day long, hate meetings, does not have any soft skills, is not communicating, usually I have concerns about that.

4:41But 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 other dependents 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 like, okay, how can we make that happen? Because 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.

5:28Because I tend to feel that managers are more successful when they have a more diverse and a little bit more full stack-ish 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 someone that really has only seen and has only done a small part of this tech. So that concerns me a little bit. So I would say those two things like, OK, what was the background? What different language frameworks, what different parts of the stack they have worked on?

6:19And are they already doing some kind of leadership? Are they already seen 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 two things, I would say not everybody is going to like, not everybody is going to be successful as a manager because for different reasons, but those are good, really good indications. Right. I'll steal something from you. So you've made a lot of, I think, great LinkedIn posts, and I think you have some articles and stuff like that.

6:59And I read a few of them before. Or one of the things, it's actually a tip from you. If someone comes to you and says, hey, I want to 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 want to be a manager, you ask them why. and they say, well, I really want to grow my career. I need more money. I'm stuck being an individual contributor.

7:38I don't think there's 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 Linear B with our people management person, Jess, sometimes it means there's not a good individual track. And that's not expressed, meaning, okay, there's junior engineer, there's engineer, there's senior engineer, there's staff engineer, there's prestigious. So sometimes it means that they cannot see a clear path for career growth on the individual contributor track. And you want to hit that right away and say, hey, I don't think you really want to be a manager.

8:16I 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 want to make people better. I want to make sure our projects hit on time. I want to 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 you know we can't get out to production or it's having issues they're connected with their local i'll call it like their local ecosystem so it's like quality sre support and then after that like you know very tight-knit with product then into marketing and all of that But I think that's a good, I always found like if they cared about quality and they want to get the feature out there and they care about support, that's a very good sign.

9:23What do you think about that? Yeah, no, I love that. And the why question is, yeah, is the fourth thing you should ask. And I think if you're working with someone for a while, you kind of already know the why, right? But I think it's worthwhile asking like either way, right? And the other thing I would say is another bad answer on the why is, oh, because I don't want to be technical anymore. Oh, because I only want to do the people side. So that's also a red flag on the other side, because engineering managers still are engineers and you still are expected to stay technical and to be able to give feedback, to look at the architecture.

10:06But of course, you're looking at a 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 the company should fix that and make the career ladder crystal clear. The other thing you said, and 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 are seeing problems that are really hard to solve as I see, right? Either productivity problems or either pain points on the customer experience.

10:48And they know that as I see, they're going to have a much smaller scope. They're going to be looking at one or two things at the moment. And as a manager, they can have a little bit more broader impact and talk to more people, influence in some other places, right? Because they're not going to be only and developing on the different piece of the code base. I think 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.

11:24And you see a lot of people getting bored out on that, right? trying to do both jobs for a while is good. It's a good experience to not formally have the role but being doing the job. But after a while, it's exhausting and impossible. 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 is our CEO now, Ori Karen. And he stayed super technical, but also had all of the skills around management that I think we're going to touch on that you need to be successful, making people better, seeing the big picture.

12:08And I do want to 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 the ability to actually make good decisions and know where to spend your time. make people better. So you do got to stay technical. One thing that I will point on, and then we're going to go into misconceptions of management. You said something, I think if someone came to you and said, yeah, I don't want to 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.

12:52So you started as a software engineer. Every company now is mostly a software company. And there's a lot of amazing technical products out there. And if you have an engineering skill set, and then you transition into a product manager, oh my God, 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, But if you do hear that, maybe a product management track for that person. Yeah, yeah, yeah, yeah. And I mean, you stay super technical still, right? I mean, even as a PM, you can keep looking at code, keep looking at architecture, but of course you're going to be looking at different perspectives, a different angle, right?

13:41I used to say, I mean, I like to say that being technical as an engineering manager is different than being technical as I see, as an engineer. Because the way that I look into that, if you're looking to the C4 model, I don't know if you're familiar with that. The C4? So C4 is a way to basically design a system architecture, basically to draw out how your architecture is broken down. And C4 stands from the four layers. So it's like context, containers, components, code, right? So you see kind of like, okay, what is the context around what is the system context around 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?

14:38And then you get into code. So as engineering manager and also as a technical product manager, you have to look into especially the top three levels, right? But not much in details on the components and on the code side, but you have to understand exactly kind of like, okay, who used this? Like, what are the bottlenecks at the container level? And of course, get deeper on the components. So, you know, what are the different models you have on your system that are causing troubles? Like, 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're able to be on their own call, right?

15:18If 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 to navigate, allows you to talk to engineers to estimate projects, right? Because that's the only way you're going to be effective, right? As a leader and also to have some respect and a shared language to continue to be an engineer in some sense. So that's the difference. While the engineer is looking at the micro level, the engineer manager is looking at the more macro level in terms of the architecture. Yeah, that's probably the biggest difference.

15:58So you just came up with the four Cs or the four Cs paradigm. You know the last time that I heard about the four Cs, it's when I bought a diamond. Did everybody buy a diamond? Cotton, clarity, color, and carry. Yes. I had to look it up, yeah. Yeah, C4 model is actually not my invention. C4model.com is a guy named Steven. Let's jump to misconceptions. Are there any top misconceptions that we didn't kind of hit on that you'd want to put out there for people? I feel that maybe a misconception or something that people undermine or don't actually know how much effort it is, is around aligning people and around, I would say, managing people, but more on the performance management side.

16:55Performance review, performance cycles, all that. I have seen a few managers stepping sideways back to IC after experiencing a year of 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 or a bunch of different squads or to go on a single goal end-to-end. And there will be people with strong opinions everywhere. And your job as a manager is going to be cut through the noise. And to get those people to be okay with paths that they are not super happy about. So especially if you want to have high-performing teams, you need that ability to go on, understand the architecture, and to align people.

17:51because if you just let the gravity happen, let's say, the standard is people are going to be blocked, people are not going to make decisions, right? So your job is going to be to be a facilitator, but more importantly, to be working in 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 skill set than you're used as an engineer.

18:40So I think those things are things you should be aware of before. And of course, there'll be with that a lot more meetings, a lot more. And I think there is a limit of how much you can optimize because you've got to be doing one-on-ones. But I think the things that are going to be consuming a lot of our energy around alignment and people management, career management is hard. It's hard to give feedback, 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 tangible. Because if you just stop on the first time you get a pushback, you're not going to last.

19:20I mean, I think you nailed it. I can comment on each. So I mean, like the role, there's a lot of talking. There's a lot of communicating. There's a lot of translating. So you're going to 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 kind of tell if someone's going to be good at that. So like, 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, CEO, marketing, that type of stuff.

20:03In 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 going to have people, and I don't want to discourage. I was an engineering manager. It was awesome. It launched my career, to be honest. But yeah, people are going to come to you. Hey, Dan, I'm not happy. I am having trouble with this person. Or people aren't performing well. You got to let people go.

20:43You got to 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 working here. I got it. We got to talk. OK, so you got to be on and you got to be. It's kind of just like a next level of emotional intelligence working with people. And that's the one that that's the part that I've seen people go from being a manager back to IC more than anything else. Yeah, I fully agree. And you reminded 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, right?

21:29And if you're going to be a first time manager, a lot of times that might involve managing people that used to be your peer in the company, right? And the second thing that I think is a good indicator or someone is going to be successful as a manager, it might be controversial, is how much heat can you handle, right? When you have a really tough meeting with C-level or VP level, like saying that the project is not going well or that whatever you're presenting is not that good, right? How does this person handle or has handled this in the past, right? Can they stay calm? Can they put a plan together?

22:08Are they humble to admit that? Or are they more the explosive kind of people that are not able to stay calm, stay in control when those tough situations happen, right? Because your job as a manager is going to be to calm down, to put a path forward, right? And if you're not able to 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 going to be by yourself, right? Right. 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 kind of either have it or you don't.

22:48So yeah, I mean, 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. you. So how can someone shine in the interview process? You know, what do you look for? That's a tough one. So just as a context, so I have spent a lot of time trying to get better at interviewing throughout my career. And that was the thing that got me a job abroad and allowed me to move from Brazil to the US, right? And one of my goals kind of like a couple of years back was to help more engineers to move abroad to get better high-paying jobs.

23:39Are you saying from Brazil? From Brazil. I would say more developing countries. Because I think Brazil is just one of many. Brazil's got an amazing startup thing going on. Amazing talent. Amazing people. Awesome stuff. Engineering-wise, it's incredible. And I'm working mostly with Brazil these days. It's nice. The majority of coaching is based in Brazil, and I'm super glad of that. But, okay, on the interview. So I would say there are a couple of things, right? So that is like interviewing as IC. That's one thing. Interviewing as a staff engineer. That's your IC, but the expectations are different.

24:19And that is the other thing, interviewing as an engineer manager, right? So 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 on those things, there is no easy tip or thing that I can say. It's going to be a mix of experience and practice. How much have you been trying out those things? And it's going to be really hard to be a great interviewee 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.

25:02That is a relationship. But at most, you have to prepare for that. But I think the thing that I emphasize the most is about the behavior interviews. And especially for managers, I think that's what is what breaks 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 when they get those questions. Or they talk about the we and not about the I. They don't talk about their specific contributions. They don't sell themselves. I think that's another problem.

25:44So I would say on the system design and coding side, I think the best thing I can say is do a lot of pair programming, a lot of mock interviews. and that's the only way to go. And designing a lot of systems, I think that's where you're going to be more successful. On the behavior side, the thing you should do is every job you have, you should at least have top three to five stories, top three to five accomplishments, challenge you had. And then whenever you get those questions, 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?

26:25Those like maybe top 20, top 30 questions that like people ask in behavioral interviews, you have a story behind it or you have a framework, right? Every single behavioral interview question, you're going to 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 going to 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.

27:07They don't want to look on histories. They don't want you to tell the last time you designed a system what you did. They want to see how you think. And if you don't have a framework on how you operate, it's going to be really hard to convey. You're going to be waving hands and running circles. And the final thing is write it down, how your answer to those well-known questions, and have friends of yours or mentors reviewing and commenting on that. What looks good? What's like, that's a little bit shady. That's not a good example. because once, and the fact that you're not going to 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 going to convey is going to be much, much better.

28:00So I think those are the things that I would say. Super smart stuff. A lot was going through my mind while you were giving those great answer. And I'm going to try to summarize. so first and foremost the difference between a good interview in the manager and a bad interview a bad interview is everything that you say is really vague a good interview is you're coming with specific examples of here's the situation 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 like the perfect answer, I'll try to give like a perfect answer because you're gonna, what the interviewer wants you to do is give specific answers of what happened.

28:56So 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? I'll try to make up a perfect answer on the fly. But of course, well, 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, because I've been through this, is I set up my squad and it was a group of engineers who had all the skills.

29:36I had UI, I had 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. And what happened when I rolled out this framework was this and that 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, really well. But if I would have done it again, I would have changed this other thing. Like, that's a really dope, dope answer. Now you have to have that answer for every single question and you'll probably get the job.