Transcript
Thiago Ghisi: This talk is going to be about my journey on the engineering management path over the last eight years. I’m going to go over what it took for me personally, and also in terms of organization strategy to get to an org of over 100 engineers. I was talking to a few people that this might be one of the last standing talks on the topic of scaling to 100-plus, especially with AI and a lot of things spreading a lot more, and having smaller teams doing a lot more. Maybe there’s still going to be a big thing in OpenAI, Anthropic, or things that are scaling, and AI is still not able to keep up with demand. It is a very interesting story, and I hope you take a lot from this.
The big question that I want you all to keep in mind as I’m going through the talk is, how do we scale to 100-plus engineers, to 100-plus people, without breaking yourself and your org? How do we scale in a sustainable and strategic way that things work, things are optimized? This talk is a lot more targeted to people that are on the engineering management path, but there are a lot of lessons that staff-plus or people that are more on the tech side can take, because I think the best orgs are not the orgs that you have a single person that’s doing everything, but you actually have co-ownership of the org, and you have the staff engineers and the principals and product managers, sometimes the BAs, whatever it is, working along.
Outline
I’m going to tell you some context about my org growth and some of the lessons that looking back retrospectively were very important over those years. Then I’m going to go over some practical lessons, like what I wish I knew going back 10 years ago, almost, like the lessons for my 30-year-old self that had just started on the engineering management path. Then I’m going to try to bring it all together on a framework on like, if I were to try to scale my impact or to look at scaling our engineering organizations in a very structured way, what order of operations, what frameworks were used to keep this almost in your mind as you go back to your work and as you see problems that arrive as you have new teams coming in.
My Org Growth: As an Engineering Leader
I’ll start with part 1, my org growth. I would start back in 2019, that was when I had just been promoted to director. That was the first time that I was managing other managers. I was at American Express at the time, and I just got one manager reporting to me. That’s context before the hypergrowth and getting to 100-plus. I want you guys to see all the ups and downs. Then, 2020, middle of the pandemic, I was director for a while, and I started to have other squads, other groups, actually, getting to my org. I was trying to help other teams to work the same way that my teams were working.
Then, 2021, I did something that was controversial, I left my director job, and I went to big tech. I went to Apple, and I took a big, massive scope reduction. I went from managing an org of 30 to go back to the trenches managing a small team of 7 engineers. Then, here’s where the talk starts, 2022, Nubank — Nubank is a big fintech in Latin America — had just done the IPO, and I had this mix of experience that they needed, someone that had managed in mobile and fintech. I took over the mobile platform team.
At the time, I was leading more the app experience. That’s not at the beginning, I think when I started at Nubank, I had maybe 30 engineers, but at the end of that year, with the huge demand, a lot of users, I think it was maybe 60 million customers at the time, but growing at 5 million customers a month. It was insane. We got to 49.
I would jump in in the year and then tell you some of the things that I did looking back were very important things, and then I would connect back and forth. The very first thing that I did was what I call establishing order to chaos. This is like setting your operational cadence. I think like, what is this? This is more about the meeting structure, the rituals you have. I think like getting the execution in order in a consistent way across the org. One lesson that I had learned early in my leadership journey was that once you’re a manager of managers, you not only need to be managing your direct reports, you need to be managing throughout the org.
If you see that there is a low performer, or a high performer, the direct manager is not doing a great job, you’re responsible for managing across. There is one thing that is very important, and that’s probably the thing that can speed up things more than anything else, is decision making. It’s like, yes, putting more engineers on a project helps, using AI helps, but one of the most powerful things you can do as the engineering leader is helping to speed up decision making. I’ll go into the details a little bit later, but keep in mind those three foundational things that helped me at the time.
Then, 2023 came, and I decided to move departments. I moved to the platform infrastructure side. I was on the product org, leading the app experience, the homepage, and then I moved to the platform, to the foundation infrastructure of Nubank, and I got a scope reduction. I knew that there was a big move taking out inefficient things that were being done in a duplicated way on the product side to the platform coming in much later. Here are the things that I did in 2023 that I think were foundational to then get last year to 100-plus. The very first thing is, once you’re past 50 engineers, there is no way for you to scale without having a leadership team under you.
At the time, I need to start to create those retools for those teams. It’s very hard to have a leadership team when you have only two or three managers under you, but it’s much easier and almost impossible not to once you have 10 managers under you. You need to have some structure. The thing that’s very important about creating leadership teams is they need to be around the same level. It’s a flaw that I have seen, if you have a leadership group where you have a lead engineer and a principal engineer, or a super junior manager and a senior manager. You need to try to level that up. They need to be opinionated. One thing that I found is that if each one of the managers is just caring about their piece of the pie, they’re not looking at the whole org, things are not going to scale much longer. You need to cultivate that, and that was one of the things that I did.
The second one was, unlock the cultural levers. I think once your group goes over 50 or 30-plus, you need to create some identity. I think that might be what kinds of things this group does that’s different than the other groups. For example, knowledge sharing, what are the things you do for preparing for on-calls? What is the thing that’s different about this group? I think the most important out of this is you need to start to build a long-term view, not only what you’re going to be doing for the rest of the year, what you’re going to be doing next year. How do you do that? The easiest thing that I have found is you start to cluster problems, you start to do benchmarks outside, you start to talk to people, and you’re going to have a very good idea of what you need to do next.
Again, I’m going to go into the details in this, but just walking you through. Then, 2024 came, 88 people at the end of the year. Different than 2022, 2024 was a year where there was a lot of reorgs, a lot of different parts of the organization moving into my org. Whenever those different orgs got merged into mine, I needed to level up. One of the most important things here is once you have groups that have been working in different ways, you don’t have the same tenure around. For example, you have one squad that has two lead engineers that have been in the company for five years, and you just got another squad that might have only new people. One of the things you need to do is start to distribute that. It’s impossible to balance perfectly, but your job as you’re scaling the org is to move things around a little bit, so the groups are a little bit more evenly distributed in multiple dimensions, not only seniority, not only tenure, but also the archetypes you have in the different groups. Who are the people that can help some group that was struggling?
Then the other thing, and that’s one of the biggest things that I want you to get at the end of the talk is, we talk about reorgs as a very bad thing, as a bug. I want you to see this as a feature. For that to happen, almost the same way we do continuous deployment, you need to think about, how can we do small changes in the org that are not going to be traumatic and are going to be easy to roll back if you need to? How can you almost dry run it first? I think that was another thing that I did a lot.
The last thing is, once you have an org of 100 people in your organization, Nubank at the time was maybe 8,000 people company-wide, you need to be operating as a driving bar raiser for the things you want to see differently at the company level. Also, to get visibility of your group. I think the bar raiser is the Amazon term, but it’s not only the one that’s asking for different things, or is the one that is guiding the company on a different direction. I’m also going to go into the details here. Here’s the thing, this year is already more than 100 people in the department. The biggest thing is it took me nearly eight years and a lot of ups and downs to be able to get an org of 100-plus and to be prepared to handle that. It was not overnight. The rest of the talk is, what did I learn on the hypergrowth from, not 49, but actually 30 when I joined, all the way to 100-plus?
The Practical Lessons: Notes to My 30-Year-Old Self
Here are the practical lessons. Here are the big things I wish if I had to go back. The very first thing, execution is the thing that breaks or makes an organization to be successful. In a big organization, the business units that are delivering are the ones that are going to get more attention, more resources, more people. This seems controversial at first, but I don’t think it’s controversial at all. A lot of times a bad decision is better than no decision at all because you at least are going to get some input. You can iterate.
A lot of leadership, I find, is about having a position. I have found a lot of engineering managers, directors, that stay vague and wish-washy and they let the teams figure out. You see that there is some decision that needs to be made and they don’t intervene. I think one of the most powerful things you can do is you need to have context to be able to guide the decision and to be ok if it was a bad decision. Once the team sees that it is ok to take bad decisions, the most important thing is not spending a lot of time researching or trying to figure out the perfect thing, a lot of things start to run a lot smoother.
If execution is the basis, the very next thing is people management. There are two big things here that I want to focus on. It’s like, if you cannot manage 100 people, you cannot do people management with 100 people, what do you focus on as an engineering manager or as an engineering director, or as a leader? You focus on the low and the highs. I think the one key lesson is that the patterns of low performance are sadly the same almost. They are super narrow. If I take out the performance improvement plans that I have seen engineers struggling and people that we had to let go, they usually fail or had problems because of one of the 10 reasons. There may be a dozen reasons why almost all low performers, they struggle with some of that.
On the other spectrum, the high performers, they are almost unique. That’s especially true at the executive level, where at the beginning of my career, I would get super frustrated with the executives like, how is that VP not seeing that problem? How does that person not know how to do whatever it is, reliability? What do they not know? Because what brought them there was not being well-rounded. It was actually for being super good in something very specific. They were good enough in other things. There are two ways on this lesson. One, the high performers, they’re going to be great for something very unique and you can double down on that and be able to sell that for promotions or whatever it is. When you look for people above the organization, you should not get frustrated for the things that they don’t do as well as you do. You need to try to find what is the big leverage that they have and try to leverage that. I struggle a lot with that because I would expect folks to be better than me in all dimensions once they are higher in the organization. That’s not true. The other thing is, and this is for the lesson about building a leadership group. You need to have a leadership group under you.
The very first thing that happens every time I try to do this is they don’t see that group as their first level team. They see that as a second level. What I mean by that is they always want to prioritize what I call their kingdom. Here’s an example of a situation that you might have seen. Let’s say a VP or the CTO asks you as the director or VP, we need to have a new squad in the next two weeks to work on this new product area or to build this new platform, but we don’t have new headcount.
Then you go to your leadership teams like, “Folks, we’re going to have to move folks around. This is very important for the company. Here’s why”. A lot of people, the first reaction is avoidance. It’s like, not my problem. Like, I’m not going to give my people. Instead of like, no, this is the most important thing we can do for the company. It’s more important than whatever is going on inside. It takes years for the leadership group to finally understand that like that group, those meetings, those weekly staff meetings, it is the most important thing. It is what’s going to allow them to advance. It’s the test of their maturity to the next level. There is a very good article from Will Larson called, Treat Your Peers as Your First Team. He goes over the details, and is like, you see that a lot of the leadership groups, even the more senior leadership groups sometimes are problematic in that way. That’s one of the very big things that is easy to say, but it’s very hard to do.
The other thing is, I talk about the cultural levers. What is culture? There is a podcast with one of the co-founders of Netflix, and he said something that I fully agree with. Once I heard it, I could not go back. It’s like, nothing will tell more what the culture is than who you promote and who you let go. You would think that everybody would be super sad the moment you let someone go. It’s like, as far as you make that happen in a very structured way and you give the chance for the person to improve. Actually, people are going to thank you for shaping the culture because there is nothing more powerful than that. I think that’s sadly something that not a lot of people talk about. Your actions shape the culture, like how you react to an incident in production, how you treat someone, how you call someone out when they’re doing something that’s not ok. I think the levers are on hiring, promoting, and firing. If you’re going to have an org that’s bigger than 50 people, you’re going to have to remember you. That’s the thing that matters here.
The other thing, and that was a lesson that I learned again and again, engineering cost is real. A lot of times over the last three years, I tried to, we need to have a couple of engineers dedicated to doing this thing. Let’s have that engineering manager and that product manager do 50-50. They’re going to manage their core squad, but they’re also going to be managing on the side, this other group. That doesn’t work. You’re not going to have the attention of those people. It’s much better in my experience to have a slightly bigger squad of 7 to 10 people, and the engineering manager and the product manager are 100% there, than to have 2 of 5 or 2 of 4. Because you would think that like, yes, as an engineering manager, you can run two standups, but the attention you have, it breaks everything else. I have tried and it’s painful because that is what’s going to force you to do the actual prioritization. It’s much easier when you can create things out of thin air. That doesn’t work. Keep that in mind.
The other thing, write it down. This is especially true when you’re doing the small reorgs that I mentioned. You would be surprised of how things get distorted as they go down in the organization. You tell your leadership group in a meeting, we’re going to do this. These are the reasons. Then they tell their own managers, and then they tell the ICs. Then when you’re hearing back, the ICs worry about some things like, why are you worried about this? My manager said, you said. That’s a mess. Just write it down. It can be a very simple one-pager. Every time I did that over the last two reorgs that I did, it worked much smoother. Like, here are the three things we want to fix with this reorg. There is a problem with this. We don’t have anyone owning this system. All the analytics engineers don’t have a manager currently. Here’s what I hope to get on the other side. This is the source of truth.
Remember, as you are discussing reorgs or discussing things, going back, every time you see a distortion on where is that idea coming from, go back to the one-pager. Is there anything here that’s not clear? It is very important as you have a chain of commands, going down. Try to write this down, what I call the MDRs, management decision records, just the drafts of what you’re trying to do. It helps a lot. The same way that we have been using ADRs, architectural decision records, so that every time someone wants to go back, it’s almost like it would be great to have an MDR repo where you can see the whole history of your org and all the decisions you made to get to the point where you are now.
That was also a very hard lesson that I needed to learn again and again. It’s like, not everything needs consensus, and that’s a good thing. Consensus is a very expensive way to get to alignment. I think David was showing what he called the DACI, not the RACI. I think it’s actually better than the RACI. One thing that I found super helpful is, try to define up front who is accountable for that decision. If I had to boil down this project to one manager and one manager only, or one manager and one staff, who is that going to be? Make it explicit from day one, those three people are responsible, whatever, but the accountable are those. If there is a delay, if there is anything that’s happening there, they are going to be the ones that are going to be making the decision, even if that’s controversial. Even if that goes against what the group thinks. Because again, going back to the thing that I was saying, speed of decision making is the most important thing. I’m not saying you should never try to get consensus. I think you should, like 99% of the time, try to get consensus.
The moment you have some very needy pick coming in, you need to make a decision. Folks need to trust that we’re going to go in the right direction. Once we have real information, real data, we’re going to revisit that. That’s a very important thing, especially for people like me, that are people pleasers, that like, everybody is super happy. I don’t want to have even one engineer that’s not 100% happy. Sometimes making the decision and going back and talking to people always works much better than making everybody else wait, because there is one or two reasons to wait for something. I’m not saying never do that, but avoid consensus as your only alignment method.
Eight, dry run it first, then roll things out. I talk about the idea of reorgs. I’m not saying that you should be doing changes on the org chart out of thin air. What do you do? You call it like a small taskforce. You put people to work with other people. You create like, this is just this project. You want to try it out to see how things are going to be before you commit. A lot of the big reorgs, they don’t go well, because it’s a one-way door. There is no way to go back. It goes to the next one, it’s like, most reorgs, or what I mean by reorgs, traumatic, top-down reorgs, can be totally avoided if you’re doing a lot of the internal bounded reorgs.
If you are constantly shifting things, and there is friction here, moving things, you’re not going to see the tip of the iceberg as much. Of course, the big reorgs, especially when you’re having big changes like AI now, are going to still be needed here and there, but they’re going to be a lot more rare than you would think. Think about reorgs in two ways: external bounded, internal bounded. Internal bounded is what makes the organization great. It’s like what nobody talks about. External is the thing that happens once every five years that every time someone hears the word reorg, they get traumatized. That should not be that way, reorg. The org chart is actually a very powerful tool to optimize things, to make things run a lot smoother.
Then the final lesson, again, this is also very controversial, is, you should manage your skip levels the same way you manage down level. You would think that executives, they want executive briefings, they want numbers. I’m going to be treating the CTO of my company, just going to be sending, we reached this, we shipped this. You would think that that would make your relationship with the CTO better.
Then if you treat the same way you treat your most junior engineer, it’s like, the most junior engineer in your team sometimes don’t even want to have the one-on-one with you. They’re scared. What do you do? You build connection. You try to find like what they do, their hobbies. I have found that the executives where I had some personal connections, the relationship worked much better than the ones that I kept on a super high level executive briefing. You also think, but executives are super busy. They don’t have time for that. I think that’s a very bad argument. Executives have a lot of time. They don’t want everything compressed. It’s an illusion, at least in my experience, that that kind of exec-level management is going to work. Especially for your career as you go up in the ranks, having that connection makes folks remember you. It also is the thing that’s going to allow someone to trust you or not. The numbers are great, but if you don’t have the personal connections, it’s going to be shady.
The Framework: Evolving Your Leadership as Your Org Grows
How do I bring this all together? If there is one thing that helped me the most over the last two years to think about my impact is this idea of the three levels of impact framework. Every single week you should be constantly thinking how I can impact at each one of those three levels. How can I have something that’s going to help not only my org, but my skip level, my boss org, and sometimes even the entire company. If you think about your agenda, if you think about your expectations, the projects you’re doing, you need to think about, are you splitting your time where you’re only in your org or you’re also helping some way in your boss org? What are you doing to help the context across? There is a very important thing to remember about this framework, that you must understand things outside-in first.
By that I mean, you need to approach things from the outside-in. It’s like, if you’re doing something, but you don’t understand why is that important for the company, you’re going to have a big problem. You need to go back almost to the customer or to the C level, like, what is important for the company right now? What is the direction? What are the priorities? If that’s the thing that’s important for the company or those are the kinds of things that the customers are struggling with, then you go like, how is your boss, how is your department helping there?
Then, how are the things that we are doing actually connecting back to that? You have to remember, especially if you are at middle management level, you don’t have any influence or authority to make decisions at the company level. You have indirect influence and authority via your boss or your leader on the department or the bigger org, and you have full direct influence and authority on the things you are doing. It’s almost like, yes, you must understand things there, but you have to start from where you are. You actually must always act inside-out. That’s why you need to have the context of what is important, what we’re doing, how the things connect, to then pull in the direction that goes there. Because again, if you don’t do this way, you’re going to boil the ocean. You’re going to have an idea to change the process for the company and you have not tried it yourself. Then you go down and you remember those things.
How do you do that? Here’s the things that I’m going to try to bring back. You start from your org to the outside, but you have to remember, you need to understand things outside-in, you must act inside-out, at the same time. Here’s the framework that I think like looking back are the things that I would focus at the different org sizes or as your org matures over time. How do you do that? You start with your org and with your own leadership chain. You start with what? You start with your org, you start managing low and high performance and establishing your operational cadence.
The very first things you need to focus on, like there is nothing else to do unless you’re managing execution, you have meetings on time, you’re sharing knowledge, and you’re managing the low and high performance. Once you get the frameworks, the things established there, then you go to the next level, that is building your leadership team, shaping the culture, creating the long-term view, because those are going to be foundational for your next leap. Then, leveling up as a continuous org. You start from your org and you try to level it up.
The next thing you need to do is like, you look at your manager department and you ask the question, how are we managing performance as an org? How are our calibrations? How are our expectations? How is the operational cadence? How are our deployments? How are our plannings? You start to look, how can I bring something that I’m doing very well in my org and help my peers or my boss to disseminate that? How can I show something that I did to other people so they inspire them to adopt something better? Then you go to the next level. We are managing high performance, we have good calibrations, performance, all that stuff.
Then you go, how is the long-term view for my department? Do we know what we’re going to be doing next year? Do we have a culture here? How are engineers across different directors collaborating? How is the leadership group that I’m part of at my boss org operating? How can I bring ideas in there? Then, you look the same way like, is there any room for optimization here? Is there anything that I could pitch to my boss so things run more efficiently? Only then, you go to the entire company or the whole engineering, and you look, how are we managing low and high performance at the company? How is the long-term view? You keep scaling in that way. If you approach things that way, you can have a very structured and organic way to scale your organizations. You would think that once you do that, all levels, you would be happy. No. You never get there. You’re always going to be struggling at one of the levels. You’re always going to be going back and forth.
There is one more thing, there is a hidden dimension on this framework that I didn’t talk much about, but that’s critical for scaling your org, is yourself and your career. We talk about your org, your boss org, the entire company, but there is actually something that I learned the hard way, that at the most senior level, impact is not enough, influence is not enough. Just being visible is not enough. What is enough to get promoted to C-level? Here are some of the lessons that I want to share. The very first thing is, you need to go back to my point about building relationships and cultivating goodwill. It’s one thing to be doing a lot of things to have a lot of impact, another thing is to have goodwill.
Goodwill is people that really trust you, the people that are going to bend the rules for your org. It’s more important to have relationships than goodwill than to have impact and influence. That was, again, a very hard lesson for me. You would think that impact and influence would be the thing that matters. No, it’s relationships and goodwill. Ideally, they come hand in hand. It’s going to be very hard to have goodwill if you don’t have impact. It’s going to be very hard to have a relationship if you don’t have influence, if you’re not actually doing good things. You have to remember, you lose goodwill every time you move jobs because you have to establish a relationship. Even if you are amazing, you’re delivering a lot, it takes a while for people to get to trust you.
Then the other thing to be promoted at the very high levels is the 10-30-50 rule. You have to be top 10% of something. If you break down the most important skills of your job as a leader, you have to be maybe top 10% in something, top 30% in other things. You cannot be below the top 50% percentile. For example, you’re amazing at delivery, but you’re a very bad people manager. It doesn’t matter. You’re not going to get promoted. That’s the thing that’s going to be louder than anything else. You have to remediate that. You would think that, strength-based leadership. It is true that you need to focus on your strengths, but you also need to remediate the very bad things, the very bad skills that are getting in the way.
Someone was saying, on the dev dialogue we had, it was like, I’m always the person that’s helping everyone, but I don’t think I ever had a very good manager that would put my case for promotion. I’m doing a lot of the glue work. I think another very hard lesson here is like, you need to set expectations in writing tied to a specific rating. Like, you can have expectations about, we’re going to be delivering this, we’re going to be absorbing this org, we’re going to be doing all these challenging things. If you don’t set the expectation of, what is that going to get for me, or, what rating am I expecting to get if I deliver those things? If you don’t get to have this conversation, you’re going to be on the, you’re amazing, you’re managers, you’re leaders like here, but you’re going to be on the second wave if we have a spot in promotions. You’re going to almost be passed here. The other thing is not only set your expectations tied to a specific rating or to a specific outcome for you in your career, stay calibrated every month. Ask every one of the goals, every one of the skills that you put to develop, how I’m trending. Also, a lot of the things are going to change.
At the beginning of the year, as you define some things, the company might be changing, and you’re not going to be tying back to the things you defined a year ago. You need to be continuously moving that. Then the last thing is, be the driving bar raiser. We all start as implementers. If you think about the career of a software engineer, it’s like, you start by implementing stuff. You start by migrating stuff from one language to another by having a very well-defined task. Then you go to solver. You get to senior, you’re like, you get a problem, you have a feature.
Then you go to staff, you go to finder. Not only are you expected to solve the problems that come your way, you’re also expected to be looking out for risks and mitigating them, or looking for what are the big things that I need to do? What are the big platforms? What are the things that are going to get in the way? What are the things that are costing a lot in our infrastructure that could be optimized a lot? It is also not only about finding problems, it’s about driving. The drivers are the ones that are operating, are the ones that are not only able to implement, solve, and find. Whenever they see something that’s not moving, they go there and they help to move things forward. If you are the driving bar raiser, the one that is not only telling folks what should be fixed, or not only fix small things, but the one that’s helping to drive the big things organization-wise, if you, again, cultivate goodwill and all those things, it’s very hard to contain your impact.
Conclusion
This is the last dimension of the framework. I think the conclusion is, great leadership is about distilling complexity, establishing cadence, and driving accountable execution. It’s also about sharing the vision, being the vision, and driving the vision. At the end of the day, it’s all about organizational resilience, when I talk about reorgs, when I talk about creating a leadership group. It’s all about, how can you go on vacation for a month and things are still running. How can you be out of the system. Those are the top lessons that I learned going over this journey to 100-plus people under my org.
Questions and Answers
Participant 1: While you manage managers, I have seen often, you ask a team, they can always have more people in their teams. It mainly comes with the intent to build some sort of siloed operations. They want to have all expertise within their team. One of the items you mentioned is in a collaboration, you have to be good at working with other teams, like managers collaborating with other managers with your teams. How do you remind your teams and ICs of cross-team collaboration while their mind is always thinking, we need more people so we can build all expertise within my team?
Thiago Ghisi: There is a very fine line between collaboration and delegation. I will tell you a story. I got a few different squads reorg into my org. There was one particular squad that had this behavior that anything that’s not owned by them is work that they need to put on someone else’s backlog. It’s like, “We need to do this, but it touches this other platform. We’re not the owner of that platform, so we’re blocked”. Collaboration is not only how to work with people, but knowing the fine line where you can cross the boundary and do something with the help of other people. Where it’s like, that’s a little bit too much. The argument that I could use, if we have to cross those boundaries, then we need more people. It’s like, no, you don’t. It is a very hard topic.
Going back to the culture, once you have groups that are able to collaborate well and you’re able to role model those things, and as an engineering leader, you can go back in all-hands you have, that’s an example of a great collaboration of how those teams did. That’s how we want to replicate. There is a limit of how much headcount you can keep adding to a group for that to be efficient. There are so many tradeoffs to balance, it’s very hard to give an answer on what is the balance between collaboration and adding new headcount. It’s tricky.
Participant 2: I’m very curious to hear about the dry run of an upcoming reorganization. You said transparent with the decisions, and at what time is that decision log or whatever communicated all the way down? Is it communicated all the way down? How do you make sure that that actually is communicated and not get stuck on some other manager level?
Thiago Ghisi: There are different levels of dry runs. One of the things that I learned doing reorgs at scale last year, I think I did five reorgs or so, is that there is almost a formula, at least that I came up with that worked well. It’s like, I do the first draft of the reorg, then I bring my direction and they stress test that. Then I bring all these test engineers and let them speak their mind, and they’re going to criticize things. The first dry run is, you start to bring the next level management before even you do anything. Like, “Folks, this is the idea. Here are the goals. We want to solve those things. Here’s my proposal. This is the first draft. Go and hammer it down”.
Then you take a note and you iterate again. It’s like, ok, here’s the v2 based on the feedback. I’m not going to do everything you’re wishing that we could do. Is this acceptable? I think that’s the first level of dry run. Then once we have not consensus, but alignment on, I think everybody can live with this new org chart. It’s like, how can we take it from here to there? Is there any project that’s struggling? Then we can create a taskforce or we can move one engineer or two on a temporary basis to one project. We can have a different engineering manager taking over a track of work. Then, every week, every two weeks on your staff meetings with the leadership group, you ask, how is that going? Then you keep kind of like, not working. Iterate again. We need more people.
Then you finally announce. You announce in multiple ways. How do we ensure that the message gets communicated to everyone? I usually have a Slack channel with my whole org. In the case of Nubank, I had the mobile platform group, a private channel with everyone. We would communicate very transparently, “We’re kicking off this new taskforce”. Every time we would do a move of, this is official. I would write down a big message saying, “Folks, over the last two months, we experienced this. We actually learned it’s working much better this way. Starting today, these people are going to be moving to this new manager”. Then we do a thought-out, a Q&A. Once you do enough reorgs, it’s always one after the other.
See more presentations with transcripts
