Transcript
Ghisi: I'm super excited to be introducing you all to my talk, breaking the ceiling. It's about how you grow above staff level and beyond. The first question many of you might have is, why do we have a director of engineering, someone that's not a staff-plus, talking about staff-plus? Here are some things that I did over the last 6 years on the management track that can provide external perspective to you on someone that has seen what happens on the other side. I have been interviewing a lot of people. I have also been in a lot of calibrations, more calibrations than I can count. I have seen what happens behind the scenes on promotion committees. Also, when someone is having their performance assessed, or presented to the group that is deciding, is this good enough? Is this actually at that level that we expect?
Outline
The summary of the talk, and the thing that I would love if you all get at the end of this talk is, what got you here, won't get you there. This is the skills, the behaviors, the strategies that took you from junior to senior, are not the same that are going to take you from staff to principal to distinguished. You actually need to reinvent yourself to go after that. First, we're going to talk about career ladders, or what I call expectations. What it actually means to get there. What is there. What is staff? What is staff-plus? Then we're going to talk about the transformational leaps, that's like, the performance reviews, the promotions, the patterns of behaviors for the folks that I have seen that have been able to do those leaps again and again, not once, but for multiple levels, and way beyond staff. Then, lastly, we're going to talk about the staff projects that in my view, are the tool or how you actually connect the expectations from the ladder or the expectations that are hidden on the ladder that a lot of people don't understand, with the behaviors from the top performers. What I've seen, not what's on the ladder, or what is on books, but what I have seen that actually moves the needle and actually makes people get promoted, into a framework that hopefully can help you starting tomorrow, to put together your expectations and help you to write something that can help you to achieve the expectations that we're going to go over.
Career Ladders
First, we're going to talk about career ladders. The first question that I'm going to try to answer is, what does it mean to be a staff-plus engineer? Because, yes, we have staff-plus titles, but a lot of people get this wrong. What does it mean? It's the number one question I get from folks, especially junior engineers. They come to me and say, "I really don't understand what staff engineers do. How do I get there?" I think that's the first thing that we really need to understand. Not necessarily, again, what's written on the ladder, but, actually, what are the expectations that I have seen, that actually everyone has in their head when they have someone who's a staff? In order to answer that question, I need to go back in time. If we actually go back as far as like 10, 15 years ago, most companies had this model of career ladder where you grow from junior to senior, and then when you get to senior, you were stuck with the senior title, and there was no way to move up on the ladder, unless you became a manager. That was a pattern that we had seen for decades. Then, luckily, we actually had 10, 15 years ago, the creation of dual-track career ladder. I think it might date a little bit far back more than that in some companies. Especially in the last 10 years or so, it's the model that a lot of companies have been working. This was a win-win for everybody. Senior engineers that were unable to grow after a certain level on the previous models now had a hope, like, now I can get to this level. For the company, it was also a win, because they had those folks that were stuck on the senior engineer title, that actually were impacting more areas of the company than some managers were. The creation of this actually revolutionized not only the IC track, but also the management track. The thing that, to start with, clearly defined what is a staff is someone that's not sitting on a single project, on a single thing. Someone that's overseeing an area that's bigger than a particular project or thing.
Then, does it mean that the dual-track career ladder solved all the problems? The answer is, no. There are still problems with the dual-track career ladder, not with the ladder itself, but how usually people expect the ladder to solve problems that are not necessarily the problems that the ladder was created for. Here's the problem number one. The levels and expectations across companies, they vary a lot. Even though we have staff, and I believe we have as an industry somehow a clear definition what staff means, with title inflation and with different companies in different stages, some companies have more levels than others, the title doesn't mean much. The levels and expectations vary a lot across companies. That's the number one thing that you have to keep in mind. If staff is there, but if the titles and expectations and levels vary a lot, what does it mean? Just an example, at Nubank, the company that I work for, we actually have a level in between. There are some companies that have that. In some companies, you actually have something in between. The next thing that is a controversial thing is the move to staff, a promotion or a lateral move. I wrote this tweet 2 years ago or so. I really believe, and going back to what I said at the beginning, that what got you here won't get you there. That's the first mistake that people make when they see the dual-track ladder, they're like, there is a clear line, like senior, staff, and they think they're just going to do exactly the same and fine-tune a few skills here and there, do a few things. In reality is as big of a change as moving to the management track. It's like you have to completely change how you operate, otherwise, you're not going to be successful. That's one thing to keep in mind is you go from being a senior engineer, to being a junior staff engineer. Same way you're restarting your career. That's the first thing that I want to say is keep that in mind. The career ladder has the expectations. The other thing that is important here is people forget that there is an equivalence between the IC track and the management track in the scope of responsibility. That's the other thing is like, does it mean that as IC I will keep growing and my responsibility will stay the same? No, it's not exactly one to one, but it's like, as you go to staff, senior staff, your scope becomes as big as a director, as a VP, and you have to be operating under a much wider surface.
The other problem with career ladders is, the career ladders will not show you all the hidden growth there are that are beyond the career ladder. The career ladder is not supposed to get to where it's going to show every single way you can grow. It shows one path that you can grow. Actually, in order to move further, after some level, you actually have to go to the sidelines. Here's just some examples of, as a senior, you can move back and forth and all that. Here's the example that in some companies, and I think this is amazing, actually, at the same level, you have senior engineer, and you have the first entry level manager, they're exactly the same level. It means that a senior engineer can move to be a tech manager after a small change, for a while, and move back and forth without actually having implications on titles or even salary implications. It's much easier for someone to try it out and come back, than actually a promotion, or actually a job change. The other thing is like, there's a big difference between titles and roles. It's almost like one follow the other. The ladder is not supposed to be the place where you have all the roles that one has to play. The tech lead in a lot of places is a hat you can wear. It's like as a senior engineer, you have that option. You can be on one project as tech lead, and moving back. Just to illustrate actually, you can be on a loop almost. There are other things like, for example, you can change the platform. You're working as a mobile engineer, and then you become a backend engineer. You're still a senior engineer, but you're growing sideways, and that's going to help you to almost go to the next jump when it comes. There is this idea of career ladders versus scaling walls. I think a lot of people feel that the career ladder is like climbing the ladder, is one thing. The people that are super successful, they actually are moving sideways, because the moment that someone gets stuck on the ladder, they're moving from the sidelines. I think that's the other thing that you have to keep in mind. I see a lot of people missing that.
The third thing with career ladders that a lot of people miss and I think is important, especially because we're talking about growth and staff-plus, is that there is a hidden dimension of time. If you actually see this, it seems like, every other year we are going to be promoted. There are some funny numbers here. I got this from Levels.fyi, that's an amazing site on that. Actually, on average on the industry, how long it takes to move between levels, for the people that move the level, there are people that got stuck, but for the people that move, those are the average that we had across the industry last year. The one thing to keep in mind is that, at staff-plus and above, the time to move is much higher. Actually, this picture doesn't even show the whole problem behind those numbers. Because if you actually were to map a 40-year career, you would see, it looks ok. You're going to become a senior. It's almost like the same time it took you from junior to senior is the same time that it takes you from senior to staff. That doesn't look as bad. If you actually grow in reality, and I think the one thing to mention here is that, it's much better when you have more levels because it's easier for you to get skills, and get used to different ways of operating, than to do the move from senior to staff. It is a much bigger jump when you don't have anything in between. If we'll actually be more realistic, it would look something like this. The actual numbers would be almost like this. It's like if someone is senior for 10, 15, 20 years, it's all good, because as a senior you can grow laterally. You can change platforms. You can be the tech lead. You can go and be a tech manager. The reality is that not only the time it takes to be promoted gets bigger the more you go up on the ladder, but the opportunities are much scarce as well. There are much less positions. Every level you go up, it's like, almost the time doubles to get there, to get experience, to have projects that will materialize in getting there. Also, there are not as much spots. I think this is the third problem. Just to summarize the point, part one is, keep in mind those three things as you're looking at your company career ladder, and as we're moving on this talk.
Staff-Plus Expectations Across Companies
I talked about career ladders, how they came, and how they are helping to improve things at the industry level. What are the patterns of expectations for staff-plus across companies? Where do I see most senior engineers dropping the ball? Where do I see that people are not aware of this thing? This thing is the reason why they are not even close to a staff promotion. Those images are career ladders that I have worked with, helped to write, or helped to improve over the years across three different companies. Those are the three things that I came up with, that really are what I considered expectations for staff-plus. I'm going to go over each one of those three. That answers the first and the second question. The first is, what are the patterns of expectation that I've seen consistently across companies that if you do those things, it's going to be unavoidable to be promoted, or to be staff-plus? The second thing is, where do I see most senior engineers failing because they're not aware of those? Those three things are the answer to both questions. Blast radius. There is this idea that you need to have a wide impact. As a staff, the impact should go beyond a single group or beyond a single project. There is, on the other side, this idea that you should be technically excellent. You should go deep, and you're the person that knows the most about the topic. I actually believe the mistake a lot of people make is they go so deep on the technical expertise, and they forget the organizational surface, or what I call the blast radius. In my view, yes, technical depth is important. We're going to see on part two, on the behaviors on why that's important. Where I see a lot of people dropping the ball is on the blast radius, in terms of impacting the organization. There are much more shapes of blast radius. The reason why I chose blast radius, and not only like high impact, is because there are different shapes of blast radius. You can have an impact on something that's deep, something that almost changes how a product line works. You can create a new platform, a new library or something that is going to make everybody else more productive, all the engineers are going to know who you are. Blast radius is the thing that you have to keep in mind in this expectation for staff-plus. If you are working on a project that's only affecting your own code base, and not everybody is knowing about that thing, is usually a red flag.
Second, multi-scale planning. Multi-scale planning was an idea I first heard on Getting Things Done by David Allen, but is the idea of like the horizons of focus. When I heard about this, I heard on a course from Tiago Forte that is about the horizons of perspective. I see a lot of people talking about big picture thinking, like the staff should be looking over the next 2, 3 years. I agree with that. The thing that I see a lot of people dropping the ball is on understanding how those things come into play. It's like, yes, as you move up on the ladder, it's like you go from knowing what to do in the next few hours to knowing what to do in the next few days. Of course, as you get to principal and director, you're expected to be 1 year ahead and to be removing risk, or planning the roadmap for the things in the next year or so. That's fair. I think the problem that I see a lot of people missing is that they don't understand how to cascade things from the day to the week to the quarter in how the organization dynamic actually works. It's like the very effective staff engineers, and the expectations that, again, are not clear on the ladder but if you do those three things, and especially this multi-scale planning is what's going to allow you to scale and to having title of staff is like, a staff is someone that knows like, there is a project, we're going to need more people to help next year. There is a thing that we need to sell to the CEO. They know how to play the different time horizons and to bring things back and forth. He's not only thinking about the next few years and having very visionary ideas, but it's also how you bring that in reality and how you play with the organizational structure and how things go on the organization to make that a reality, because there is a limit. I think that's another mistake a lot of senior engineers make. There is a limit of how much 2-week projects you can do, like going nights and weekends to solve a problem. You need to be looking at things, how can you do that in a sustainable way?
Then the third expectation that, again, is not clear on the ladder, but I feel is where a lot of people get it wrong is the idea of implementer, solvers, and finders. It's like, you start your career as an implementer. Someone that gets, do this task, follow this example, just implement this. They give you the problem and the solution, you just have to replicate that almost. Then, as you move to senior, you become a solver. Someone gives you a problem, and you go and you figure out. Then, there is the third level. I think a lot of people stop at the solver. There is even the archetype that's called solver that I think actually creates more damage than it helps, is the finder. Is someone that is not only solving problems and different shapes of problems, but is someone that's thinking ahead of time, and is finding the next priorities, the next things that the organization needs to focus. That's the idea of the problem finder. If you actually put that on the ladder, on the bottom here, you can actually see, ok, you start as an implementer, then you move to solver, then you are a finder. In reality, there is another thing is, you never actually stop being a solver or implementer. That's another mistake. There are people that never go to finder mode, they're never finding problems, finding risk. There are people, they're just going finding mode, and they throw over like, there is this problem here, we're going to get blocked here. In reality, the very effective staff engineers and the behavior that they do, is pretty much this. They're able to go back and forth on the different horizons of time, but also in different roles. We're going to see on the part two again, but if they don't have someone to delegate, they almost need to be the solver. They'll have someone to delegate the implementation, they need to be the implementer as well.
Action Items
A few action items on this part one. A few things for you guys to think about if you're stuck on the career ladder, or if you want to get to staff-plus, at some point, is when it comes to high blast radius of impact. Are you working on projects that are actually going to move the needle and create a huge blast radius of impact across the org, or you're working on what I call, feels good snack tasks. Or priming, there's a lot of antipatterns of things that have high visibility, but really low impact. Are you really focused on things that are going to cascade down, or up? What was the last project that you worked that actually had an impact beyond your project, because sometimes it's hard to find. In order for you to create something that has a high blast radius, you need to think through. You really need to stop and see the permutations before you jump into solving mode. The second thing is multi-scale planning. The question you should be asking yourself is, can you work ahead of time, like planning dependencies, helping to shape the roadmap for the year? Can you influence other stakeholders, other dependencies? Can you work a quarter or like a half ahead of time? When have you done that? Again, if you are able to materialize those three things, to me, you are a staff. It's just a matter of time of like when you get promoted. How are you influencing the department and your group beyond your squad or something, with your vision? I think that's the other thing to keep in mind.
Third, is the ownership and autonomy level. It's like, what is the percentage of time that you're operating as a solver versus a finder versus an implementer? You need to be careful with that ratio. Because if you are 100% as an implementer, or 100% as a solver, you're not going to get through staff-plus impact and influence. You need to allocate some quality time to be a finder, because it is a skill, and it takes time for you to actually start to uncover things that are behind the scenes, and again, connect the two things that I said, and how you put that on the roadmap. How you act more as someone that can delegate, but also someone that's not only working on what's being asked for. The other question is, what is the ideal allocation? Should I ask people that are at the next level like, what is the allocation of their time that they try to play with this? Sometimes it's 100% solver. Sometimes it's 100% implementer. Sometimes there is a short-term gain of like a big project, and the best thing a staff can do is go out and he's like, forget solver, forget finder, just need someone to implement and get this to production as soon as possible. You have to be playing with that. On the long term, that needs to be a balance. Again, action items. Think about those three things as you go. Because in my view, those are the expectations that if you're able to bring to a promotion case or to a calibration, those are going to be the things that people are going to be impressed by. Those are the things that actually makes the staff engineers, in my opinion.
Transformational Leaps
The second thing is about the transformational leaps. Transformational leaps is the idea of promotions, basically. It's like not only promotions, but what are the behaviors? We talk about behaviors, because it's like when it comes to interviews, when it comes to presenting your performance cycle, when it comes to building your promotion case, is all about behavior. I will tell you about this. There is this idea that, in mostly interview loops, you have a behavioral interview. Why do we have a behavioral interview? Why do we ask, tell me about a time you have a conflict with a peer of yours? Tell me about a time you influenced stakeholders. It's because we need to see evidence that you were able to do those things in the past. I think this is an important frame. Because as you go to promotions, promotions about staff is about the past, is about demonstrating evidence, and is about demonstrating behavior. It's not skill. It's not potential. It's about, have you done those things?
I'm going to go over pretty much what are the achievements, what are the things that people that got promoted level after level had that allowed them to be promoted, allowed them to be top performer again and again. Also, how you can apply that on your next promotion. I'm going to go over three leaps, the leap from lead to staff, or from senior to staff, depending on your company, from staff to senior staff, and to principal and beyond. I'm using Nubank's career ladder, just as an example. The first leap is the lead to staff. What I have done here, over the years, I have accumulated probably dozens of cases of promotions to each one of those levels. I have tried to anonymize and cluster them into what were the achievements that those folks had? What are the patterns here, folks that got promoted from senior to staff? This is just a word cloud on that. If I had to summarize, and I'm going to go over the patterns, because we're going to connect this all back. From lead to staff, what are the things that those folks did that actually got them promoted? It's like what I call strategic decision-making is about, we're able to drive key technical decisions and being aligned with goals and roadmap. I think this is really important. Second, I think effective mentorship and leadership. It's almost like mentorship and leadership are not supposed to be needed unless you're going to scale yourself. The moment you need to scale yourself is one of the most effective ways to scale yourself and to have other solvers under you, is like demonstrating leadership and mentoring others. Third is cross-functional influence. It's like the seniors that were able to get to staff, or the people that were able to work with product, design, and they were able to bring alignment and connect what the technical side could do with what other folks had or even other departments were expecting at the time, and deliver high impact project. If I were to go back to a lot of those cases of promotions that I accumulated over the years, and I've seen being canonical promotions, promotions that were undeniable, that everybody is like, yes, that's a clear case of what it means to be a staff. Those are the three things that I have seen.
Then the second leap is from staff to senior staff. What are the things that I have seen? I'm trying to anonymize things. Those are the huge words that appear again and again. Here are the three things, the patterns that got those people promoted. You see that there is a pattern of promotions, and leadership in critical initiatives almost connect back with what I said in the previous level, broad and scalable influence. Broad influence is hard if you're not mentoring or leading. That's why mentoring is one of the behaviors that we are going to see the most across a lot of promotions. Third is operational excellence. Yes, delivering one project is great, but you need to demonstrate that you can go from building software yourself to building orgs that build software. How you do that is if you have a track record of operational excellence, that's the way to go. Then the third is to principal and beyond. Here, you see some words like, platform, business domain, planning highly, strategy again, proactively. Here like, to principal and beyond, the one pattern that I've seen is those people, they went from owning a domain that involved 5, 6, 7 squads, to almost understanding so deep a domain or a product line, that there were meetings with the general manager of the area. They were an important person to drive the strategy for that particular area of the company. Again, that plays back to the multi-scale planning that I was talking about. The other thing is innovative technical leadership. I said, on the blast radius thing, there is a dimension that's technical depth. How deep you're able to go. In my view that plays here. It's not necessarily being the person that knows the most about the technology, but it's being able to innovate with that. That's the key thing. Sometimes the innovation is not really necessarily like on being the expert, the person that knows the most about that. A mistake that I see a lot of junior engineers making is they make this joke, they say, I know more about Android than the principal engineer, therefore, I should be the principal engineer. I have seen a lot of those things that they only look, I was able to solve this really deep, nasty bug here, that not even the staff engineer knew about. It's like, being staff or principal is not necessarily being the one that knows the most there. He's the one that knows enough that's able to connect to materializing innovation impact. Is someone that sees things that other folks are not seeing, not necessarily the most deep technically. I think, again, this is a huge mistake, if you go so deep on the technical side and forget everything else, you're going to get stuck.
The third thing is, again, mentorship. Connecting now back, if I could summarize in one slide, what are patterns for those people that got promoted from senior to staff, staff to senior, senior to principal? I would summarize into three things. One, strategic influence and ownership. Ability to drive things that actually have a business impact. Then, leadership and mentorship. Again, is like, you have to scale, you need to have broad impact. How do you do that? Leadership and mentorship is the way to go, the patterns of behaviors that help you to move there. The third is what I call technical excellence and innovation. That's like, you're able to navigate complex systems. You're able to find approaches, methodologies. You have a track record of being able to innovate again and again, not once. It was not lucky. You have a methodology. That's why I emphasize so much on the three expectations, because it's not lucky, is consistently and over time is almost undeniable to get to this level of impact.
Just to end this part two is, on the other side, what are the patterns for people that got stuck. If you actually look at the patterns of the people that got promoted, you're going to see almost the opposite on the people that actually got stuck. Again, I collected a lot of achievements, a lot of areas of development from those people, and try to put here. Those are the kinds of words that you see on performance calibrations, when we're talking about those folks that are not necessarily moving, is their behavior, what's happening. If I had to summarize in three things again, is like they lack strategic vision. They're so focused on the deep technical part, the task, and they forget the why I'm doing that task. How can I go beyond that task? They have an ability to delegate. Probably number one is like, if someone is unable to delegate, unable to inspire other people, they're not going to be able to scale impact and influence, is number two. Third is communication issue, or poor stakeholder management. Because if they don't understand the vision, if they don't know how the different horizons work, they're actually going to get stuck on communication. They're actually going to get stuck on talking to stakeholders. They're actually going to be pushing for things that are completely unaligned with what the organization is thinking. Those are that.
Action Items
Action items for this part. I think having role models, or the idea of going and finding people that are doing those behaviors, that are inspiring to you is a lot more powerful than checklists. I think that's the thing that career ladder, a lot of people they try to go, and like, those are the bullet points that are listed as principal engineer expectations. They try to like, I want to check that. The opposite is a lot more powerful, is like find those people that will inspire you. Find the people that mentor the way that you can see yourself mentoring. That's a lot more powerful, than trying to see things as checklists. I hope I conveyed with the examples that those are the behaviors that matter. Second, everybody has one key behavior, and that's the book, "What Got You Here Won't Get You There." The idea that you have one behavior that is causing more damage and stopping you from being promoted, more than like, you should leverage your strengths and double down things. Sometimes you just need to fix that one thing. Especially when you get to senior to staff, one of those three things that is really there is communication, delegation, is going to be really hard for you to be promoted. You have to address that, more than knowing more technology, or being the expert in different areas. Those might be as important as doing staff project. Third is, instead of looking outside-in, look inside-out. What I mean by that is, a lot of people go and they read books, or they see like, what are staff-plus doing in other companies, and they try to fit that in their organization. That usually doesn't work, folks. If there is one thing that I learned, as a director, is it's much easier to replicate cases of promotion that happened in your organization. Because the reality of your organization is probably different than Google, Apple, and all those big companies. Instead of that, look for cases, look for canonical promotion cases of staff-plus, cases where everybody was talking about that person was operating as a staff for a long time and got promoted. Talk to those folks. Do informational interviews. Ask for one on ones with those folks. The information you're going to get there is unlikely you're going to be able to find in any books or anywhere else outside. Really double down on that.
Staff Projects
The idea of staff projects. What are staff projects? There is this idea of staff projects that I first heard about on Will Larson's book, "Staff Engineer." He says that those are the three things. There is the whole discussion, do you need a staff project to be a staff engineer? There are people that never had a staff project. I actually liked the idea that your job as a staff engineer is basically to do a staff project again and again. My criteria to what is a staff project are going to go next. For Will Larson, those are the three things that a staff project has. It's complex and ambiguous. It has a lot of stakeholders. It is a thing that if you fail, everybody is going to know about. It's the thing that is important, and is challenging. Both failure or success there are going to be either celebrated or impacted in some way. Then, here's the part that I try to bring all together. If I had to summarize what is a staff project in my view, I like to put those two images together, because one side is what are the expectations that are canonical almost across companies? In my view, if you're doing those three things, you're going to be a staff, almost in any company. What are the top behaviors, the behaviors for the people that got promoted again and again? A staff project is something that's the intersection of all that. It's something that has a high blast radius of impact, something that you have to play with the multi-scale planning idea. You have to think back and forth, influence and talk to people one year ahead of the need. It's something that you're not only solving. It's not usually something that someone is handing to you, solve this problem. You are finding. You are selling. You are operating. If needed, you're going down to solver, down to implementer. Those are projects that you have a chance to demonstrate strategic influence and ownership, end-to-end. You have many opportunities for leadership and mentorship, because otherwise, you're not going to be able to deliver those things, and are going to be powered by technical excellence and innovation. Those are the things that are going to make it possible for you to get to staff project. If I had to summarize, this is the thing that's going to get you promoted. It's like doing those 1, 2, 3-year projects that have those three things. You replicating those behaviors are not necessarily a formula for success. If you don't have those behaviors, that's a problem. You can have many other ways to do other things, but those behaviors are actually the things that will make it easier for you.
You have this idea of staff project. How are you materializing that in something that you can take tomorrow? How do I make sure that my staff projects are good enough, and you have time to work on them? I think that's the other thing that's way outside the ladder, but that so few people do, is setting expectations in writing. Setting expectations in writing is something that a lot of people get stuck with. A lot of people, when I ask, what are your expectations for the year or for the half? "I have that in my job description." It's like, no, I'm not talking about the job description, I'm talking about, what are your expectations for the half? What are expectations for the year? You have to write it down. One of those expectations has to be a staff project. Not only to get promoted there, but even if you're already a staff or senior staff, you need to have at least one staff project. Here, I put one example of one of the staff engineers that report to me. His staff project for the year is going to be to go from Apache Pinot, from early adoption to be available to general adoption company-wide. It's a huge challenge, because Apache Pinot competently changes how you do real-time analysis, remove the data pipelines. It's something that you need to work on the timescale planning, you need to influence stakeholders. It's something that's huge. If that materializes, it's going to change how the company operates, because it means they're going to have access to real-time data, where sometimes we need one day or two days for the data pipeline data to be available. It's huge. I like this model that's super simple, yet so few people do. You have the deliverables, are three things. One of the deliverables should be one staff project. You can have other things, but also the skills. We talk about, like there are probably some skills that are holding you back. There's probably some skills that are preventing you to move. There are probably some skills you get feedback from your peers on 360 feedback, how you're going to develop that. For this person, like, for example, conflict management is something that as a staff, you need to learn to say no, more often. You need to jump into forums when the meeting is not on a nice vibe, and to be able to handle that. There are other things like maybe someone that was promoted to staff, but was never a mobile engineer, was never a backend, you need to increase your visibility understanding on one area to be able to be effective. It's like, write it down, top deliverables expectations and top skill expectation. If nothing else, if you do that tomorrow, and bring that to your manager, that increases by far your chance of being promoted, because the worst thing that can happen is you're actually trying to write that on the day before the self-assessment is due.
How do I make sure that my manager is not biased, and I don't have surprises on performance review? That's the, ok, I go and I write about my expectations. My manager is all good. That's a huge staff project. That's what's going to get you promoted. You deliver that, and there is a surprise. No, it was not good enough, the committee didn't approve. How do you mitigate that? There is this concept of performance calibrations. I'm pretty sure all of you already heard that's the idea of the manager presenting to other managers to calibrate the bar. To actually make sure that we're being fair with everybody, that you don't have people that are being on the role model, or depending on like, consistently exceeds expectations. The idea is, we need to apply that for each level at the beginning of the performance cycle. It's like the same way we do performance calibrations at the end, we need to bring that at the beginning. It's almost you have expectation calibration for all the principal engineers in the company. The managers of those principal engineers, they have to bring it to the table. You have other level plus one ICs on the discussion. You have the manager presenting. You have facilitator. Usually they have a time-keeper, a note-keeper, and a cross-calibrator, someone from another department. If that is not happening, you're going to have surprises at the performance cycle. I understand that not a lot of organizations, a lot of companies are going to be able to do expectations calibration. If you cannot do something like this. If your organization doesn't have that, some way that you are checking if the expectations that the manager, the IC are setting are at the level that the person is supposed to be, or the level that the person is targeting, the level that we feel that this person can be promoted end of the year. How can I make sure that there'll be no surprises there? There are ways to do that with other mentors. You can do this informally. You have to do that. Because if it's only between you and your manager, it's usually not good enough. There's a lot of bias. There are a lot of people that they think something is a staff project, when, if I go back to the expectations and the behaviors, they're not even close.
Action Items
What are some action items here? Write down your expectations, at least one staff project, one key skill, like for next half. We're just on the half for H2 in most companies. Calibrate against your peers. If you cannot do something as the expectations calibration, where your manager is presenting the case, and is getting feedback back to you, and you're making sure that the expectations are aligned and everybody agrees. If that person reached those deliverables and is able to improve those skills, that person is at the next level, do that informally. Third, not only do the expectation writing and then the performance self-assessment in the end, you need to be having checkpoints. You want to be grading how you feel each one of those things are going, and you need your manager to be also saying, "I think this project is ongoing." "No, I feel this is really bad." You need to be continuously reviewing your expectations, not only at the beginning, like every month, ideally every quarter, because you're going to have less surprises if you do that. If you don't do that, performance calibration is going to be a huge pain. You're going to have a lot of supplies in the end.
Summary
If I had to leave, in one slide, everything that I talked about, it's career ladders, titles versus expectations. Focus a lot more on the expectations. There's a lot of hidden opportunity for growth. Remember the 40-year career. As your level goes up, the opportunities are fewer, and it takes more time. If you actually keep in mind the long-term impact, you're going to have focus on impact and influence, your chances to reaching the next level are going to be much higher and you're going to have less pressure on yourself. If you chase too much the next promotion, that almost is going to work against you. The staff-plus expectations, high blast radius, multi-scale planning, ownership and autonomy level. Then the transformational leaps, like focus on role models over checklists. Try to find your key limiting behaviors or skills. Look inside-out instead of outside-in. Then, staff-plus projects or how you bring that out together into a framework that can help you to materialize this, in the same way that I talked about multi-scale planning. Is about finding your project. In order to write your expectations, you're going to need to almost go to a different ownership level. If you cannot do expectations calibration, there is a saying that like, the best day to work on your performance calibration for 2024 was December last year, the second-best day is today, and the worst day possible is January or February 2025. Do that as soon as possible. Then the idea of, don't get surprised. Having a status on your calibration, don't forget that: don't write 6 months later. There is also an idea here of having snapshots of expectations. Sometimes there is a reorg. Sometimes there is a big change that the expectation you had at the beginning of the year is outdated. The idea of doing those reviews is like almost you need to take a new snapshot and throw that out of the window. It's fine. It's better to do that than to have the illusion that what you wrote was still valid a year later.
See more presentations with transcripts
