#190 - The Staff+ Engineer’s Journey: Unlocking the Secrets of Staff+ Impact - Thiago Ghisi

[00:01:29] Introduction

Henry Suryawirawan: Hello, guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me, Thiago Ghisi. He’s one of the top leaders out there, engineering leaders, right? So today we are going to talk about this topic, which probably interest some of you who are ICs still at the moment, right? So we’re talking about Staff+, you know, Staff, Principal or beyond Principal engineers as well. How can we actually make our career and what are the things that we should expect or we should behave in terms of becoming a Staff+ engineers? So welcome to the show, Thiago.

Thiago Ghisi: Thanks. Thanks, Henry. It’s a pleasure to be here, man. I’m a big fan of your show, and yeah, I’m glad to be here recording with you today.

[00:02:11] Career Journey

Henry Suryawirawan: Thanks for that. So Thiago, I’m sure you know the drill, right? So first thing I would like to ask you to maybe to share a little bit more about yourself, if you can maybe mention any highlights or turning points that you think we all can learn from that.

Thiago Ghisi: Amazing. So I’m Brazilian, and I have been in tech for the past 20 years or so. And I started my career as a Java developer back in the day, right? Then, I mean, wrote a lot of SQL, then kind of like transition into a project manager role, didn’t like it. Then I would say the first turning point and the biggest highlight of my career is I joined ThoughtWorks. And I know you also worked at ThoughtWorks, Henry, right? And I joined ThoughtWorks back in 2012 when it was still kind of like early in Brazil. I was on their first oversea kind of like in Brazil and that kind of like completely changed the path of my career. I kind of learned English back then.

And then I would say the work at ThoughtWorks for two years then moved to the US. I was lucky to get a job in the US. Then as an engineer still, and then transitioned into engineering management back in 2016. And have been doing management now for eight years. So, fun fact is I have spent almost like half of my career in Brazil and half in the US now. And almost half as an engineer and now half as a manager. And I have been kind of like lucky enough to be able to have some growth and also growing on the management path. I’m a Director now. I manage other managers and growing a big team now at Nubank, and yeah, I mean, a lot of lessons there, but a lot of turning points as well.

Henry Suryawirawan: Yeah. Wow. It’s very interesting fact, right? So you have gone, like you said, the 20 years of your career. So when you said half half, that means a decade each. So I’m sure we’re going to learn a lot about being an IC, being a manager, right? Today, specifically, probably we’ll focus a lot more on the IC part, you know, Staff+ and the Principal engineers and those kind of things. Although I’m sure it’s also good learning for us if we know a little bit about management, right?

[00:04:24] Definition of a Staff+ Engineer

Henry Suryawirawan: So I think, Thiago, the first thing that some people would like to know about, what is your definition of becoming Staff Plus engineers? Because I-think in different parts of the world, the career ladder, the roles are probably not the same. So maybe if we can level set our definition first, what do you mean by Staff+ engineers?

Thiago Ghisi: Amazing. So the first thing that I would say actually is it’s funny that I’m a Director talking about Staff+, right? And I think that is when I gave the talk a month back, I think that was actually, one of my main motivations is to be someone from the outside, talking in and seeing kind of like, what happens with…, what do the Staff engineers that are super successful have than the ones that kind of like are not able to break through the Staff level or not able to grow beyond that half, right? So my definition of Staff engineer, the main thing they would say is like, first of all, you should not be working on a single scope, right? And I know this is super controversial, right? Like, but if you’re working on a like one feature team or on one particular, one single code base that’s used only by a few engineers, and it’s not, let’s say, impacting the entire organization, like you are not a Staff engineer by my definitions. Even though I get into a lot more details later, right?

So when I talk about Staff engineer, I break down into three core expectations. So the first one is someone that has a high blast radius of impact, right? Number two is someone that is able to do multi scale planning and able to influence the organization doing that. And I will explain more what is that. And third is someone that has ownership level that is beyond reactive or beyond waiting someone to give them a problem, right? And my definition is, if you are doing those three things, you are already operating at the Staff level, in my opinion. And I think like the other thing that I mentioned on the talk, and I think that’s part of my definition, is that a lot of people forgot almost how we got here, right?

How we evolve as an industry to actually get to the current state of the affairs, where we have the dual track career ladder, right? And I think one important thing to mention in addition of like everything else is that there is almost a relationship between the levels of the management track with the levels on the IC track, right? So it’s like the same way that you have a lead engineer and you have, let’s say, a tech manager, let’s say. You have, let’s say, a Staff engineer and have an Engineering Manager, a manager of managers. You have a Senior Staff, you have a more senior manager. You have a Principal, and a Principal engineer is almost Director level in most companies, so they have almost the same expectations of the impacting organization surface area that is similar to, let’s say, the equivalent on the management track. It’s not exactly one to one, there are nuances, there are different archetypes of Staff+, right?

But I would say, in general, I think it’s not that you can grow forever on the IC track, you have to keep in mind that there is some kind of almost anchors, like there is some relationship between those things, right? I would say in general, those are my definitions, right? So like high blast radius of impact. And blast radius, the thing that I like about it is it can be deep or it can be wide, right? Then able to do multi scale planning on an organization. I’m talking here mostly about mid-sized to large organizations. If you work on a startup, it’s a different game. I’m not talking about that, right? And someone that is able to go from finding a problem to driving the problem to solution, right? It’s not someone that’s waiting someone to, oh, solve this problem, or here’s a risk for you to find how to mitigate. It’s like someone that’s actively putting things on the backlog and influencing the roadmap, right? And not waiting someone to tell them what to do, right?

If you’re doing those three things and you’re able to have like high blast radius of impact, able to do multi scale planning, and able to kind of like to be ahead of the game, to be thinking kind of like six months, a year, two years, in materializing those visions and influencing, inspiring folks to work towards that vision, you are a Staff engineer, right? And doing that with technology, of course. Being someone that is technical, someone that’s able to guide others, mentor, but I’m saying in definition, like mentorship, like being good with tech, being a super expert, it doesn’t matter if you’re not able to do those three things.

Henry Suryawirawan: Yeah. So very interesting, the core expectations that you mentioned just now, right, the three things. I’m sure we’re going to cover a lot about those three later on. But in the first place, I think that you mentioned about dual career track. I think this is also something that is pretty new, probably in the software industry, right? And especially in the big tech this is probably common. But in some other organizations, maybe manager is like the peak of the, you know, engineering career, right? Which I’m sure also maybe happening Brazil. But in maybe the US, you know, the companies where you have a big tech, a core competitive advantage. IC is also one of the track that probably engineers can aspire to become, right?

[00:09:43] The Different Level & Scope of Responsibilities

Henry Suryawirawan: And I think the first thing that I just want to highlight, right, in many of such organizations, the level where you become Staff actually is starting from like a Senior software engineer, and then you take a leap into this Staff engineer, right? And you mentioned about scope of responsibilities. Maybe outline a little bit more about this scope of responsibility, because I think that’s pretty good guidance, like a quick guidance to say that you are at this level at what particular responsibility. So maybe if you can outline bit on that.

Thiago Ghisi: Amazing. So I would say, like, when you start your career, you’re working at, let’s say, called the task level, the more granular possible thing, right? And as you move, like, to senior, right, or as you move to mid level, it’s like, when you’re a junior, you’re given a task and you’re given instructions, you’re given help, you’re given support, you’re given kind of like, oh, follow this example, do this migration, replicate this kind of screen, right? And then once you move to mid level, you’re more able to handle a little bit more ambiguous and larger tasks, right, to a point where when you become senior is the point where you’re able to get something that is not well defined and is large quote unquote, right?

Like a good example is you’re able to own end to end the delivery of a new feature of a software or an app or a website, right? You’re not only getting a particular task, you’re getting the goal, right? You need to kind of like do the whole discovery, you need to break down the RFC, you need to work with dependency, you need to be able to do almost a full cycle and full stack, almost, right? I think like, yes, there are definitions of senior that do not necessarily involve working across the stack, but overall you have like something that is not well defined and you’re able to kind of like to be the future lead, right? Like leading that from, let’s say, concept to production, right? I think that’s like senior level.

And then Staff is when you start to oversee not one feature, but multiple features that usually means multiple groups, multiple squads, or multiple teams and Staff is usually between, let’s say, one to two to three different squads. And you’re overseeing that, you’re setting that vision, you’re helping to create that platform, you’re working on things that are important, not only for a small area or a small, let’s say, as we call, stream aligned team, right? But you’re working on something that will have enough leverage and be reusable or be impactful enough that you need to be thinking ahead of time. You need to be working across. You need to influence more than one backlog, let’s say. You need to work with more than one PM, right? More than one engineering manager. And you are like almost like the tech lead of tech leads or the architect, even though I don’t like that term, right? But you’re the one that’s kind of like shaping the vision and helping to take the most ambiguous problems and shape a little bit to give to the senior engineers. And to also kind of leveraging the senior engineers to be giving their opinions but you were kind of like guiding. You’re driving that, right?

And then I would say once you go from Staff to Senior Staff and Principal and Distinguished, is when you go from, let’s say, a couple of backlogs, a couple of groups to maybe a department, right? Like maybe a product line, right? Like maybe for example, instead of the one particular flow of your app or of your, I don’t know, website, whatever it is, like whatever kind of software you have, you’re owning kind of like the whole product or you’re owning the whole business unit, right? Like you’re the one responsible for a series of groups. And then as the Principal engineer is definitely at the domain level, at the product line level.

Distinguished, I think the definition of a distinguished engineer is someone that is able to impact the industry. It’s someone that’s able to create technology or to shape a new methodology or something that has impacted how we do things at the industry level. But over the last couple of years, these terms start to be overused. And now, like, Distinguished is more synonymous of a Principal. There are companies that even created the title Fellow, right? That was something that I think Google started off like top of the top engineers that were like almost kind of like at the C level, but on the engineering track, right?

But I think like it’s easy to think about that on the IC ladder if you look at the management side, right? Because on the management side, it’s exactly the same, right? Start as a manager of a single team, that you manage managers of a well contained area, where there is some bounded context around that, right? And then once you become like a senior manager, you are kind of handling two or three bounded contexts. And then when you become a Director, you own a department that involves multiple, right? And I think like it’s exactly the same thing on the IC ladder, but folks usually forget about that, right? They think it’s just about getting better technically and being faster and all that, but that is not the case.

And I think like one of the other things that I mentioned in the talk is that, in my opinion, becoming a Staff engineer is almost a lateral transfer. It’s almost like you go from being a senior engineer to being a junior Staff engineer. You are at the beginning of another career ladder, the same way that once you go from senior engineer to tech manager, engineer manager, you are going from senior to junior manager and you’re kind of like, you’re starting all over again, right? So I think a lot of people forget the skills that got them to be senior, to be good technically and be able to scale at the individual level are not necessarily the skills they’re going to get there to be able and to be successful at the scale at the Staff level, right? And Staff level is when you go from, let’s say, building software to create orgs that build software, right? Your goal is not necessarily to be the one coding, but it’s like, it’s the one that’s creating the processes, that’s shaping the vision that will allow, like the org to create software. And is not necessarily you by hand, right?

Henry Suryawirawan: Yeah, thanks for highlighting about this lateral move. I think same like for an IC to become a manager, right? So this is kind of like the tipping point, typically, after you become a senior software engineer, right? You’re good with your craft, you can code, you can churn out features. You-can work well within a team, right? A single boundary, just like what you mentioned. But there’s a cross path, typically, for this dual career track, where you choose an IC, which is like the Staff level path or the engineering manager, right, becoming a manager. And typically those two tracks require you to learn about different set of skills.

I think what you mentioned, when you work with multiple teams, multiple people, stakeholders, definitely you will need have kind of like, stakeholder management, better communication and influencing, or maybe thinking beyond just a one scope, so thinking about different areas of things. So definitely something that people can think in terms of how you shape the leveling between different roles in company. And I think the path to get there is not about getting better at the technical stuff, knowing more about, I don’t know, frameworks maybe technologies and things like that. But the scope of impact within the organization, right. So I think that’s really, really true.

Thiago Ghisi: The one thing that I was going to say, I think like knowing well the technology, knowing well the frameworks, knowing well what’s possible to do, and most importantly, knowing how to innovate, right? Knowing how you can leverage technology to achieve, let’s say, the priorities of the company, the struggles of the company. It is what makes like good to great Staff engineers. It’s like the innovation that comes with it, but it’s not the technology itself. It’s not the skills itself. It’s like being able to put that into something that in that organizational context is going to be successful, right? And that’s why kind of like just bringing new technology even then being amazing is not necessarily going to solve the problem. You need to be playing with the strengths and the weakness of the organization, right? And I think like, in that, a Staff engineer might be the one that’s finding kind of like how to optimize a super complex performance problem.

But it also can be someone that’s creating a methodology on how you can leverage like the same stack in a different way, right? Having a canonical path of like we only use this couple of technologies. Like that can be a Staff project on its own, right? I think technical expertise and technical excellence is important, but not the same way that they were all the way till senior, right? It’s a different kind of game and a different kind of plug and play, different pieces to make them connect.

Henry Suryawirawan: So thanks for highlighting that. I also like the definition of multiplier effect, right? You mentioned something that, you know, innovate beyond, a-certain particular technologies, right? You create a business impact. So I think the multiplier effect, same like a manager, right? So you influence multiple engineers, probably, in order to come up with some innovation that can impact the business, right? I think that’s kind of like probably a succinct way of explaining that.

[00:18:54] What Got You Here Won’t Get You There

Henry Suryawirawan: So you mentioned about what got you here won’t get you there, right? So this is like a lateral move. In your experience, you’ve become director for quite some time now. What are some of the biggest hurdles for people to switch from a senior engineer to a Staff engineer? What are some of the biggest hurdles that maybe trip some people? Because I’m sure many people here might learn from that as well.

Thiago Ghisi: Yeah. The first thing that I would say is like the people that are able to transition from senior to Staff in the easiest way possible are usually the people that have had an experience as a manager. I think like that’s crazy to say, but it’s like the people that are able to influence others, people that are able to delegate, people that are able to put visions that are inspiring, to convey, to be aligned with leadership, to understand what is the thing that’s going to move the needle for the organization, right? And I think those are the people that are super successful on this transition, and it is almost natural to them, right?

The things that get a lot of people, I would say, is the inability to delegate. And I think like if you see, when I said kind of like the ownership levels, right? That is also the same way you have like you go from task to feature to kind of like department. Like you also have the same thing on the ownership level. You go from being an implementer to being a solver, then to be a finder. And there is even the driver that comes later, right? So I think like the people that are not super successful are the people that are into this habit of waiting for someone to tell them what to do. Give me a problem and I’ll solve it. But like, they are on this continuous waiting, like some inbound request on something like their manager to tell, oh, I need you to focus on this. And they have not developed that muscle, let’s say, that they are able to analyze like the meetings, the docs, the OKRs, the external market. Like they’re not able to construct their view. I think they, they struggle a lot with that, right? People that never exercise that skill, that’s like really hard.

And that’s what I call like they are not able to be strategic, right? What it means to be strategic is doing things that are aligned with what the organization cares about or what the organization has prioritized, what the organization is looking for, right? And not doing things for the sake of technology, right? So I think like folks that were able to get to senior being like the one that does the most in details code review or the one that kind of like knows all the internals of the kernel or like the latest versions of the frameworks, all that. You’re able to get all the way to senior and those skills are really important, but doing more of that is not what’s going to move the needle, right? Doing more code reviews or like being the one that’s always up to date with the latest and greatest is not necessarily the thing that’s going to give you the most leverage, right?

And then like, the other thing is like the senior engineers, they don’t know how to work cross functionally, right? They don’t know how to work with PMs, with designers, with, I don’t know, supports, right? They have issues on communicating both with dependencies or stakeholders. They usually get in trouble at the Staff level, right? Because if someone is not telling them what to do, is not being able to kind of like do that cross alignment with the other people that depend on that software, that person is not able to communicate back and forth, right?

So those are the three things that I have seen that kind of like again and again, when I see in performance calibrations, in promotion committees, if you have one of those, let’s say, behaviors or lack of behavior, those are the things that are kind of gonna get you. And if you are not aware of that, and sometimes those folks, they keep insisting on the same path, right? Oh, I need to be more technical, but it’s more about are you able to delegate? Is your vision in alignment with what the company is going? Like can you influence leadership? Because if you’re not able to show alignment, you’re not going to be able to influence and you’re going to lose trust, right? And people are not gonna want someone that has Staff+ responsibility that they cannot trust, right? So I think those are the, like, it is a vicious cycle, almost like circle of problems, right? And one problem lead to the other.

Henry Suryawirawan: Right. So I’m sure that is a good learning, right? So for those people who are still aspiring, you know, to become Staff+ engineers, right? So thinking about what things do you need to change in terms of mindset and behaviors, which is, I think, a good segue for us to start moving into the expectations.

[00:23:34] High Blast Radius Impact

Henry Suryawirawan: You mentioned about the three core expectations of becoming a Staff+ engineer. So just to remind a little bit, the first one is about high blast radius impact. Multi scale planning, right? And the other one is about autonomy and ownership level, right? So maybe let’s start with the first one, high blast radius impact. So what do you mean? Like does this always mean that you have to move the business metrics? Or do you mean the engineering metrics? Or when you mention blast radius, what does it mean?

Thiago Ghisi: Yeah, I think, like what I mean by blast radius is a reminder, let’s say, that the amount of the organization surface that you’re impacting matters. And it is also a reminder that it is close to impossible for you to have a high blast radius of impact trying to do things last minute or not planning for that to happen, right? It’s like if you’re able to have like a high blast radius but it was out of luck, out of like random, like it’s not what I mean by having a planned high blast radius, right? And I think the thing that I like about blast radius and I think it’s important to anchor on that definition of you go from like working on a single team then to influencing multiple groups then to own your department. And when I talk about blast radius is like, oh, I’m not saying that you are impacting all the time all the engineers in the company, right? Even though like one thing that would be super high blast radius is a change or a new framework or a new way of doing things that you’re going to be empowering or multiplying the capabilities of all the engineers and making their life easier, right? That’s one kind of blast radius.

But there is the other kind of blast radius that’s like, it might be more contained on the area on a single bounded context, but that deeply impacts the business. Let’s say, if you’re able to solve, like, imagine that you have, let’s say, a particular feature or a particular product line that is really inefficient, right? It’s using, like, cloud resources really badly and you’re able to fundamentally change that in a way that is, in a significant way, much cheaper like to the business. And it completely changed the constraints of the business to be successful, right? Or you unlock the possibility of doing something else that was a blocker to you then, right? Even though that has, in theory, a small blast radius, it might have a super deep blast radius. Because then if you have increasing revenue in one area of the company, that will enable the company to shift resources, to have more money to do other things.

And the blast radius is not on the first level effect. It’s the second order, third order effect of the changes that you are… But the thing about the expectation is you are not gonna be able to have high blast radius, let’s say you’re not going to be able to have that intention, like, intentionally be able to impact high blast radius way if you’re not planning, if you’re not in strategic alignment, if you don’t know how to influence. I think it’s like in order to get to that core expectation and to be able to do that, there’s so many things that need to line up, right? So it’s like, that’s like just the tip of the iceberg.

Henry Suryawirawan: Yeah, so I think it’s a very important, like when you mentioned about second degree, third degree, right? So you need to probably understand the chain of impact that happens after you deliver something, right? And I think the blast radius here could mean two different things, I-saw your talk, right? You could go deep in the technical part or also the organizational aspect. And straddle between these two, right? Because I think sometimes you have a project that is more technical thing, maybe, I don’t know, rewriting something to make things better. Or you can work on the business process, right, in order improve certain metrics of the business. So I think straddling between these two probably is some good tips to create a high impact, high blast radius that you mentioned.

[00:27:23] Multi-Scale Planning & Influence

Henry Suryawirawan: And I think you mentioned about planning, right? Yeah. Maybe some people got lucky, you know, they went into a project and the impact is really great. But it’s rarely happening that way. Sometimes like you have to really understand maybe first the-business, the performance of the particular system at the moment, right, or maybe the legacy code base. And after that you plan something and create the impact. Which comes to the second expectation of becoming Staff+ engineer is a multi scale, multi level kind of planning. And also influencing. So maybe tell us a little bit more this.

Thiago Ghisi: Yes, so I think, like, the first thing you’re going to say about this second expectation is that, yes, as a Staff+, you’re not expected to manage people, right? You are not a people manager. And I 100% agree with that. But that doesn’t mean that you’re not expected to influence people. You are. You’re not their people manager, but you are kind of like influencer, I would say in the sense that you are the one, or you have to be the one that knows how to play the organizational dynamic and know how to influence people, orgs, right? And you know how also I think it’s like you know how to navigate, you know who you have to talk to to get like a vision into place.

Let’s say you have this amazing idea of a super high blast radius project or high blast radius way of doing things that’s going to completely shift the way that the organization does engineering. It’s not something you’re going to be able to do from like the night to the day. It’s something that is going to take time, and you’re going to have like, I need to staff a completely new chain, I need to partner with a vendor, I need to have the business buying, to be able to allocate one quarter, like a half of the year, and a couple of like the most senior engineers to be able to design this problem, right?

So I think like, that’s where, when I say multi scale planning is like, you are able to play with the different horizons of time, right? So there is this definition that like big picture thinking, right? Like someone that is able to see kind of like one, two, three years down the line and work backwards, right? And I think that’s great. I have seen a lot of people but more important than having the vision is like to be able to align people there and to be able to know exactly what needs to line up and when is the time for you to put that as a new OKR, like write that on the six pager, whatever it is. Like when you have to influence, let’s say, the board meeting, like to get approval to do some of those things, right?

And that’s the thing that going back to the point like yes, the Staff is not a people manager, but it needs to be able to influence the organization, it needs to navigate the organization, it needs to be able to know how to cascade things up and down, and it needs to be able to play with these multiple horizons of time, right? And have a vision, working, getting feedback, trying again, like this logistics of kind of back and forth to get something big done. It is what is actually gonna be able to break or make someone as a Staff, right? Because if you’re not able to play with the constraints of the organization, very likely, you’re either gonna burn out or you’re gonna kind of like be stuck, right?

Henry Suryawirawan: Right. I think I love that the explanation just now, right? So first thing about the different levels of horizons, the horizon of time or the vision, right? Or sometimes like you build a roadmap, Because sometimes you cannot just achieve it within a month or a quarter. You have to think beyond just one quarter, right? It could-be multi years even, like if it’s a big complicated kind of problems. And I think you mentioned about influencing, right? This is also something that many individual contributor are stuck at, trying to convey why we have to do a certain kind of project, right, or deliverable.

[00:31:06] Stakeholder Management

Henry Suryawirawan: And another thing that is probably quite a challenge for some people is actually to debate or maybe dealing with a more difficult stakeholders. Because sometimes techies, we talk in technical terms, like we can’t translate to business. And sometimes people don’t get convinced. So maybe from your view, right? How can we influence maybe stakeholders better, right? So maybe a few tips.

Thiago Ghisi: Perfect. Amazing. So this is the thing that I have seen a lot of Staff engineers and more senior engineers saying is like they don’t have the patience to influence, right? And what I mean, patience is, a lot of time, you just need the time, plays the factor, right? Like let’s say you have a meeting with a super senior, like product manager or like a general manager or someone that owns a big scope and you give that person idea, you plant that seed, right? And initially they’re going to say, oh, why is any saying that, right? And they’re going to have pushback. Well, I have this idea that we could go this way. We could leverage this platform. And it’s going to take some time for them to reflect.

And you also have to almost take their input back and say, oh, I remember you worry about this area. Let me get back to you in a month later, present again. And like, I think it is the shaping of the solution. And it is like, I think there is also a dynamic that is the more people you bring early, the more people feel that they were part of the solution, that they were kind of designing that along with you and not something that came as a surprise. I have something that’s perfect that nobody ever saw that is going to solve everything, like folks are going to be super resistant about that, right? And you need to be patient.

And that’s why I said multi scale planning is like involves multiple tries and maybe that was not the moment. Then there is a incident that happened and oh, remember that solution that’s going to solve that scalability problem, that’s going to solve the performance issue. You have to be able to play with the events, right? You have to be able to play with like AI now is like the big hype, right? It’s like maybe two years back, if you talk about LLMs, right? People are not like, no, but now it’s like, oh, that’s… so you have to start to warm up people to the moment that you’re going to do a request for new headcounts. The moment that you’re going to put like something on the roadmap that’s going to consume a big chunk of a particular group’s time, right? So I think like, that’s all about that.

And if you don’t know how the cycles in the organization happen, how decisions are made, in which rooms you need to be part of, who you need to talk and when you need to talk, right? When can you give them idea for them to use to that board meeting or that kind of like C level offsite, right? You need to be able to play with the constraints and knowing like who you have to influence and when, is an art, right? But it is not something you can do from like one day to another, one week to another. It usually takes months and sometimes it might take years, especially if those are high, really high blast radius.

So I would say like that’s the thing about influencing that’s hard, is that a lot of people don’t have the patience to wait a seed to kind of materialize and something to develop over time, right? And taking a different shape, I think that’s also important, right? Don’t be attached to the initial idea you had, and I think you’re driving the solution. It might have like a slightly different shape, and that’s okay, because people are still going to remember, oh, the initial seed of that idea came from you. But the more allies you have, the more people are along with you on the journey, the better it’s going to be, right? So I think that’s the thing that Staff engineers need to understand, because otherwise it’s not gonna be sustained.

Henry Suryawirawan: Yeah, so I think that’s really interesting, right, to have the patience. Especially, if you probably are new in the role, right, or new in the company, right? Sometimes you need to earn the trust and gain credibility first before you can actually influence other people. And I mentioned about stakeholders, but also don’t forget you also need to-influence on the technical parts, right? You know, the engineers or maybe some engineers who-are also highly opinionated, or maybe engineers in another team, right? Like, why should they follow your thought process? So I think that’s also a kind of influencing that is probably difficult…

Thiago Ghisi: Inspiring others, right? Yeah. Inspiring others to work along with you. I think like, yes, I think like you have to influence up. You have to influence sideways. You have to influence down, right? I think this is exactly the same that the thing that directors and managers have to do. You have to manage up, you have to manage sideways, you have to manage down, right? And you have to be strategic about it, right? And if you’re able to sell a compelling vision to the leadership, but the engineers are not excited about that, that’s not going to be great, right? Or if your peers are going to be working against you, that’s also not going to be great. I mean, that’s like the 360 is so hard.

[00:35:52] Ownership & Autonomy Level

Henry Suryawirawan: Yeah. So very interesting skillset, definitely, but that’s not the only one, right? So we have the third expectations, which is about the ownership and autonomy level, right? So you mentioned something that, you can’t just wait for a project to be assigned or problems to be given to you, and then you work on it, right? But you move beyond the implementer. You mentioned about this earlier, right? The implementer, the problem solver, problem finder and problem driver, right? So maybe tell us about this kind of framework so that we can understand how to become more autonomous.

Thiago Ghisi: So I think like there are three dimensions, right? I think like I said about kind of like you go from task to feature to multiple groups to then department, right? And you go, like, on the other end from being able to see the next 24 hours, what you’re going to do in the next week, then the next month, then the next quarter, next year, right? And then there is like other side is, like, you go from being an implementer, someone that’s given a task, the how, and also something that’s short in the time horizon to something that you’re going to get then, let’s say, a problem that is a little bit less defined and a little bigger, a little longer time horizon. You’re not going to get the next few hours for you to do something. You’re going to get the next few weeks, right, to do a feature. And then you need to get to a point where no one is actually telling you what to do. You are telling them what to do, right? That’s defined, right? You’re looking for the next set of problems that organization needs to fix. What are the next set of risks that we need to mitigate before the action materializes, right? And that’s what I call the finder. I think this is an amazing article from Randall Koutnik where he talks about the implementers, solvers, and finders.

And I think the funny thing is that after my talk, there was a principal engineer from a company came and said, you know what? There is another dimension, this is the fourth dimension, that’s the driver. Because a lot of staff engineers, they get to the, let’s say, the finder, right? They’re able to find the next problem, they’re able to find the next risk, but they are not able to drive that to completion. Or they are not able to move back to be a solver, to be implementer whenever it’s needed, and they are the only ones that are, let’s say, just raising problems, raising questions, right, and telling others what to do, but they are not being hands on whenever it’s needed. Or they don’t have someone to delegate to be the solver of a part of the problem, right?

So I think there is expectation that you move up on that dimension and you’re not only the one waiting somebody to tell you what to do. And whenever you find something that’s critical, that’s aligned with the organization, you’re not only throwing that at the wall for someone else, you’re actually following up on that. And trying to drive that to completion. I think that’s as important as having a vision, as important as thinking long term, is helping to drive those things to completion, because otherwise nothing matters, right? I think like you need to be able to materialize your impact.

So I think like that’s the thing that I have seen a lot of people struggling is they move from like solver to finder, and from finder to driver is pretty hard, because everybody is able to get from implementer to solver, because like, that’s natural as you build more skills or you’re more fluent on the language. As you understand the stack better, you’re able to abstract a lot of details, and you’re able to navigate and be able to solve the problem by yourself. But then to be able to find the next set of problems is you have to go out of the code base, you have to talk to people. And then like once you find, write it down a doc, influence the roadmap, it’s not like you cannot just be sitting, oh, what is the next thing? It’s like, yes, you have to be doing, you have to be kind of like trying to find the next big things, the next big risks that you’re gonna have.

But you have to make sure that the things you put on the roadmaps are moving forward. And that means driving that sometimes, that means having somebody else to drive for you. And if you’re able to delegate all that. That’s how like those three expectations, they’re all connected almost, right? And when I talk about strategic view, when I talk about delegation, when I talk about communicating and influencing other stakeholders, that’s how they play. Because you’re not going to be able to achieve those core expectations if you’re not able to do all of these other things.

Henry Suryawirawan: I like the addition of the driver part, right, because like what you mentioned or maybe that particular person who just mentioned about that. I think it’s really true sometimes like people can find proposed ideas, right? But to actually drive it to completion or even beyond a certain particular milestone, right, multi level milestones, I think it’s pretty rare to have that person who that passion to drive people. And making sure that it still follows the chain of process, right? Like it’s not like something that, okay, when an incident happens or some issues happen, they just stop right there. And some people also follow this promo project, you know. So-you work on a promo project, and after that, you know, you just leave it after you get promotion. So that is also quite typical that I’ve seen in the industry.

Thiago Ghisi: Actually, two things now. But I think that, the number one is, when I mean like going from finder to driver, you’re not being the technical project manager, right? You’re not, as a Staff, I don’t expect you as a driver to be micromanaging tasks. It’s more like at high level, like almost at executive level, you are kind of monitoring things. And when you see things are off track, you go, you talk to people, you bring the engineering managers together, you try to change direction at the high level, right?

So it is important, like when I mean driver, I don’t mean like you replace all the engineering managers, right? But you’re kind of, you’re overseeing that and influencing and changing directions. You don’t let something go off for long. The moment you catch it, you kind of like go back. And sometimes when it’s critical, you actually go and you join and you help to speed up. And you even like go back to solver, back to implementer if needed to make that project to be successful, right? Like you don’t have the attachment of, oh, I’m not going to code. I’m not going to do this simple task, because I know sometimes all you need is like enough hands and speed of completing things to finish a migration to ship something to production, right?

And you were saying something about promo project. Exactly! So that’s the other thing is like when I say all those things I’m saying is like things that are going to have a long lasting effect, right? Because there is this thing called promotion-driven development. Like the thing at Google that a lot of people mention that you do a project, kind of like it’s successful for one month then it’s killed and you got promoted. Or you create a platform that it’s not gonna work for that long, that has a lot of like bad practices and like it’s something that’s not gonna be there for long term, right?

And that’s not what I’m saying, right? That’s not the kind of project that just to drive the promotion. Something that’s gonna be sustainable. It’s gonna be kind of like a solid foundation for the organization. And I think like that’s hard. But I think like when they say all those things like a blast radius is not something that’s going to kind of like a new product that you launch and instantaneous like goes down, right? I mean it needs to be solid in terms of engineering, scalability, reliability, right? I think like when you are at that level, I would not expect anything less than that for Staff+.

Henry Suryawirawan: Right. So I also love that you mentioned just now, you highlight that sometimes, you know, you don’t just play the finder level only, right? Sometimes when required, you can move back to becoming an implementer. Maybe write some particular code that is difficult, or maybe you just pair with somebody, right, to get things done in correct way. So I think, yeah, you have to be able to play different levels, right? Not just becoming an architect, you know, sitting in the tower and give tasks to people. And I think another thing that sometimes people stuck, like how to find problems, right? So I think a few tips from me is actually sometimes you just need to observe. You know, some people just get used to the habit, right? And they don’t find things be problematic, but actually when you change something, you can create a big impact. And also understand about the business metrics or the OKR, and then try to relate that the things that you know about.

[00:43:51] Behaviors & Patterns

Henry Suryawirawan: So I think these three core expectation’s really great, right, as-a guidance for people to actually think about the things that they need to do. Another thing that you have is actually about behaviors that the Staff+ engineers need to showcase or demonstrate, right? Maybe a little bit here. How can people learn about the behaviors that are expected as well for them?

Thiago Ghisi: Yeah, so I think like one of the things that I did over the last almost eight years on the management track was to accumulate a lot of performance reviews, a lot of promotion cases, right? And also I was part of a lot of promotion committees and performance calibration as a manager, I had spent a lot of hours there. And one of the things I started to do for both my directs and for the cases that my peers would present or…, was to save, like, almost a collection of achievements or let’s say strengths or areas of development that either move people, accelerated people to be promoted or were things that got them stuck. Or things that actually prevented them from being promoted, right?

And I think those behaviors and I think, like why behaviors, right? Why you look at behavior? Why you look at the achievement level? And I think like it’s the same reason why in interviews you get asked the question, tell me about a time you had a conflict with a peer. Tell me about a time you deliver a big project, right? It’s because you want evidence of how you have done that before, right? And I mean the same way like when you’ve been promoted, they’re not being promoted on potential. In most cases, you’ve been promoted on something that you are already doing, you already did, right? And you’re just like, the promotion is just officializing that you’re already performing at the next level. The promotion is the conclusion of like that cycle. And so I start to collect like over a hundred examples of achievements or areas of development. And what I did was like to try to find patterns, both the patterns for people that were able to be promoted again and again, not only from senior to Staff, but the Staff to Principal, right?

Like what were the behaviors that kind of drove those promotions? And on the other end, I was looking on the low performers, the people that were either missed some expectations or people that were not able to be promoted or had their promotion cases kind of like do I need to wait another six months and work on this area, right? What are the skills that prevented the most engineers from moving across levels? And I came up with like some patterns that were pretty much consistent. But I think there are some in between levels, but I was able to almost generalize at the Staff+ level for both low performers and high performers, right? And I think like the thing that came up on the top behavior are the behaviors that if you have those things, it’s very likely you’re going to be able to grow again and again, are those three, right?

Strategic influence and ownership. So I think you’re able to influence in a strategic way, in a way that’s aligned with the business priority, right? And strategic here means is aligned with the business priorities of the company or the things that are gonna have the most impact. And ownership is you’re able to drive something to completion. You’re able to have not only identify this but people recognize that, yeah, and he drove that project. He was there from the beginning to the end. He was on the production incidents. He was on the discovery calls. I think that the behavior of being the driver, let’s say. And things that are strategic with the organization have a high blast radius are the top one behavior.

The other one is leadership and mentorship because you’re only able to operate at the finder or driver level if you have other solvers or implementers that know how to do things in a way that kind of is scalable to the organization. You have someone to delegate, right? And mentoring play into that, because the only way to have more people to help you is mentoring others, like growing them, like telling them, like what, how you learn to do the things you do now, right? Because the more people you have that are growing along with you, the more scalable is going to be your influence, the more impact you’re going to have on a larger scope, right?

And the third thing is it’s not that technical innovation doesn’t matter. It’s not that knowing something deep doesn’t matter. It does matter, but it matters for innovation, right? Like, so the behavior is those people are able to innovate, or they’re able to use technology, or they’re able to connect technology in an innovative way to achieve something, right? So I think those three behaviors that I said, are the things that usually, when you see a promotion to Staff+ and beyond, you’re going to see a combination of those three or a combination of two of them really happen.

And then on the other end the behaviors that got the most people stuck, right? The behaviors that prevented most folks to move. And I think that there is one note to say here that is, it is totally okay. And it is fine to be a senior engineer forever. And I think like on my talk, I even talk about that the career ladder, there are many paths for growth that are not visible in the career ladder. You can switch stacks. You can work from backend to kind of like kernel level and then you can go to mobile. So, you’re still a senior engineer, but you’re still learning a lot. And as a senior, like in some companies, there are seniors that make more than Staff engineers, right? The super seniors sometimes make more than the entry level Staffs, right? Because they want to incentivize people that are that kind of role, and they’re able to be super fast and strong ICs that like to be hands on, and that’s totally okay.

But the people that really were trying to move and got their cases of promotion blocked, usually, those three are the three behaviors that I documented. Like one is the lack of strategic vision, right? I think like they were working on projects that were not important or bad projects, let’s say, right? Or things that were not in alignment. Two, they were unable to delegate or scale their impact, right? And third, they had really poor stakeholder management or communication ability, right? Usually, for most folks, when they’re not able to break into the Staff level after a couple of years, there is usually one of those three things are coming to play.

Of course, there are cases of organizations that have politics, that have people that wanna play against the other, and I’m not talking about those organizations. Most organizations where there is performance review, there is fairness, I would say, those are the things that usually block folks to be able to perform at the next level. If you keep in mind the expectations and you keep in mind those behaviors you almost can do like in order to be promoted, I mean, it’s not a formula, but if you’re able to kind of achieve those three expectations, blast radius, multi scale, and ownership level, you’re able to do like mentorship, innovate, and you’re able to influence others, right? You’re going to be almost a machine. It’s like almost a flywheel, right?

On the other hand, if you’re not able to delegate, if you’re not able to work in a strategic way that’s aligned with the business, if you’re not able to communicate and influence stakeholders, it’s very likely you’re going to be blocked. So you need to address those behaviors to be able to grow beyond senior level. And I think those are the things that are fundamentally different when going from senior to Staff is like you need to completely change like almost the glasses that you’re seeing the problem, right? You need to kind of shift how you scale.

Henry Suryawirawan: I think this is really golden, right? So you just summarized the whole thing, right? The expectations, the three expectations and-also the kind of like three pattern or behaviors that people need to think about. So I think this is such a good framework for people to think, right? And-also, if you, let’s say, you want to become a Staff+ engineer, you need to understand all these aspects. They seem to be a lot, right?

[00:51:53] Role Models Over Checklists

Henry Suryawirawan: So maybe some people think of it like a checklist. I know that you don’t promote this kind of a checklist thing, but to find role models. How can we find role models? Because sometimes these kinds of qualities are rare in the industry. And sometimes it’s just luck. Like you work with somebody who is good enough that you can have him as a role model. But sometimes it’s not. How can we get a good role models for these kinds of behaviors which seem to be like impossible, right?

Thiago Ghisi: Yes, yes. I think like the one comparison they will make and that’s probably when you’re reading a fiction book versus a non-fiction book, right? Checklists are non-fiction books. So like when you read the fiction books, you’re going to have like a chapter that is laying out the framework, like oh you did this and might be playing some stories. When you’re reading fiction, you’re almost seeing as a first level player, right? Like you’re seeing that into action. You’re seeing all the nuance that came to play. You’re seeing maybe exactly the framework, but it’s not structured, it’s not synthesized in that way, right? And I think like a mistake that a lot of people make is like they get obsessed with what is written on the career ladder, what are the checkpoints, what are the spreadsheets. And they forget how to combine that into play.

And when I say role models are a lot more powerful than checklists, it’s not that checklists are not important. I mean, they are. In my talk, and everything we’re talking about, it’s just a combination of checklists, right? But there is nothing more powerful than seeing someone playing in front of you, right? There is nothing more powerful than, for example, I mean for me, I think like one skill that I really mastered over the years was conflict management, right? And I think that was a skill that I remember seeing my director back when I was at American Express being just a mastermind of that, and like, I would go on a meeting and I would be stuck, and I would kind of like, oh, can you join me this meeting to resolve? And it’s like seeing someone playing and seeing someone kind of bouncing ideas and it’s the same way…

Like one thing is for you to read a book. Another thing is for you to pair with the author of that book, solving a problem. And you can read the book again and again, you’re not going to be able to articulate well enough than seeing the person kind of bouncing ideas and like failing. And is not a straight line, right? And that’s important for career growth and like mastering those, what I call transformational leaps, right? When you go from one level to another, it’s not only a checklist of things, you need to be able to connect so many concepts in a pragmatic way, in a way that moves the needle, right? In a way that moves the conversation forward, right? And for organization is getting things done, is like, working with people that sometimes you don’t like, or kind of overcoming constraints, right? And the checklist is not gonna tell you that. It is such a mindset shift. And a lot of people try to find role models outside the organization that are playing in completely different constraints and having completely different challenge, right? And then apply on the organization, when they have people close to them, you’re already able to show them how to play under that set of constraints, right?

So I think it’s like, that’s the thing that people have to keep in mind and that’s what mentorship is about. It’s about kind of like, being able to have those role models, being able to bounce ideas. It’s not about, a mentor is not someone that’s going to give you another framework to think about. It’s someone that, he’s gonna kind of like adjust your kind of role playing almost.

Henry Suryawirawan: Yeah. So I think a little bit about mentorship, right? So I think if you are lucky, right, just observe within the organization people you admire. it could be not in the tech division, right? It-could-be in other business departments. You-can also get some mentorship from them and learn the kind of behaviors, patterns, just like what you mentioned, like a concept of a hero in a fiction story, right? You-follow the hero, and importantly, you get inspired by it, right? So that you know what are the nuances that you need to think about instead just following checklists.

[00:55:56] 3 Tech Lead Wisdom

Henry Suryawirawan: So thank you so much for this conversation, Thiago. I’m sure people have a lot things in their mind now, but unfortunately we need to wrap up. But before I let you go, I have this one question that I always ask my guests, which-you probably are familiar with, right? So I call this the three technical leadership wisdom. Just think of it like an advice that you want to give to us. So-maybe if you can share your version of three technical leadership wisdom.

Thiago Ghisi: A couple things that I would say, and those are the things that have helped me the most to scale as a Director. And I think it will help a lot of people to scale as a Staff+. I think like, number one is, I would say, use what I call the LNO method to evaluate your priorities against leverage and to time block your week, right? Like, okay, let me unpack that one, right? So it’s like the LNO method is L is leverage, N is neutral, and O is overhead. Instead of doing your to-do list in a way that you are evaluating, oh, this task is going to take two hours, this is gonna take like eight hours. You actually look at the tasks that are gonna have the highest leverage, right? What are the things that if I do this week are gonna have the highest leverage, are going to impact the most people. And by doing that to prioritize your week ahead of time. And allocating time blocking your calendar, you’re going to be able to put what I call like the big rocks in the calendar, right, and have time to do the things that move the needle. And not gonna get, in the sense kind of like have all the meetings overflowing your calendar and you’re not going to have time to do the deep thinking, the deep work. So I think like use the LNO to prioritize your week is like the first leadership wisdom that I would put. And I know it’s not technical, but it is in some ways because a lot of people make the mistake of being instead of having their calendar working for them, the calendar is working against them, right? So that’s one.

Number two is on delegation. And I think this is important, especially through Staff+, is like, there is nothing more powerful for delegation than learning for the people that work with you, or they’re under you, or more like, a little bit more junior than you, right? What are their goals? What are their strengths? And what are the areas of development? I think that this is a tip that is so powerful, because if you know what someone is trying to achieve, like, what are they good at and what areas they’re trying to improve. And you have a task, you have a project, you immediately are going to be able to tell them, hey, I have this opportunity. Why don’t you take this task? It’s the most effective way to delegate things. It’s so powerful.

I mean, even for managers, even for Directors, because then I know exactly who’s going to be excited about that task. It’s not about pushing things into people, right? Oh, you do this. It’s about how you frame that in a way that is gonna make them excited about that, right? And going back to scaling in a sustainable way and being able to go from solver to finder to influence the whole department. You’re not gonna be able to get there if you’re unable to delegate in a scalable way, right? Like have one on ones with people, understand their career goals, that’s the thing that is going to unlock the next level of delegation for you, right?

And the last leadership wisdom, tip that I would leave, is structure and write it down. That’s the main thing for so many things. I think like, on my talk, I talk about writing down your expectations for the year, right? Sometimes, we as tech people, as managers, as Staff+, we’re repeating the same idea, you know, in one-on-one with one, and another meeting. And it’s exactly the same idea but you’re only repeating meetings and like people are repeating and you’re losing precision.

At some point in your career, the only way to scale is going to be if you structure that and write it down and have like, okay, here’s the idea. Here’s the vision that I have. Because otherwise replicating that vision or that the same speech again and again to different people is not going to scale. And speaking sometimes you’re changing the narrative a little bit, right? And like by seeing things in paper or like on writing, people are going to be able to pinpoint exactly what’s wrong or what. And this applies to so many things. This applies to what is your strategy for the next year? What are the goals, I said, right? But I think what are the action items for a meeting? What instruction right now? And like you would not imagine the amount of people that, still to this day, they’re not able to write it down, like a good agenda, good follow up, action items, or even their goals, right? And most people, the problem is that it’s not that they don’t have goals or they don’t have like a vision. Is that the vision is not clearly articulated in a way that can be revisited on a snapshot. Like if you don’t write it down, you lose that precision. If you’re gonna ask yourself, oh, what did I agree with my manager a year back? Oh, I don’t have that, right?

So I think this is such a powerful way to be able to scale your influence and be able to be effective, to be pragmatic, right? I mean, it is the same way as an engineer, right? You write down, like, what else would you do to improve the code? You have a to-do list that’s close to the code base. You write tests, so you kind of remember what that code is doing, right? So I think it is something that is important and is one of the foundations to keep you scaling more and more.

Henry Suryawirawan: I like the last one, right? So always a reminder for anyone who get into more senior levels, right? I’m sure it’s not just Staff+ or Engineering Manager or Director and things like that. Anyone who wants to be more senior, right, I think they need to learn how-to write better. And with a good structure because to narrate your thought process is something that is not easy, right? And maybe for some people who write blogs before, right? You kind of like understand the kind difficulty to structure-your thought process. So thanks for sharing about that.

So Thiago, if people want to follow you or learn more from your experience, right? Is there a place where they-can find you online?

Thiago Ghisi: Yes, I’m very active on both LinkedIn and Twitter under Thiago Ghisi, and just follow me there. And yeah, it’s always a pleasure to bounce ideas with folks. And I’m always writing about career growth, and leadership, and engineering management, so I’m very active there. And you can follow me on both LinkedIn and Twitter.

Henry Suryawirawan: Thanks again for your time and sharing about this Staff+ engineers career aspiration, right? So thank you again for your time.

Thiago Ghisi: Thank you, Henry, for the invite. It was a pleasure, man.

– End –