Transcript
Leandro: One thing I noticed when I reached a more senior developer role is that first I was expected to be more autonomous. I was expected to do work that was more impactful, whatever that means. I was working on a wider scope, and I noticed that there was never enough time to do what I knew was important. Now I was getting questions from my manager about what I should be doing. I thought, "shouldn't you be telling me? what do I do now?
I'm Sabrina. I'm a Principal Engineer at Intercom. We build a customer service platform for companies who care about delivering the best customer experiences. I want to talk to you about this transition to a more senior engineer role, and how you must be intentional about your time and the work that you do. I'll talk about how to define your personal development journey as a senior staff-plus engineer, starting with how your role changes as you become a staff-plus engineer. Why it's important to be intentional about your goals. The process that I use to set and keep track of goals. Finally, how that process can help you in more than one way, including how to set you up for your next promotion.
People Leader - Technical Leader
You don't need manager in your title to be a leader in engineering teams. More companies are investing in senior individual contributor tracks to support engineers as they grow. Leaders need to set their own goals, balancing personal, team, and company's priorities to define what to do and what not to do. This is important both for managers and individual contributors once they reach a more senior level. My current role is principal engineer, but I used to be a manager. I know I just said that you don't need a manager in the title to have that experience. Being a past manager helped me so much in my principal engineer role today. I've learned a lot as part of my role as a manager, from my peers, from my own manager, and from formal training as well. Unfortunately, it's still more common for companies to provide support for new managers, but not so much for more senior individual contributors when they get promoted into this role. I think mostly it's because it's more common to transition from an individual contributor to a manager. There are more resources and there are more similarities on how managers work across departments. It's more likely your company will have a standard training for all managers.
I used a lot of my skills as a manager when I moved to a principal role. However, not everyone will switch tracks like that. It's important for staff engineers to be given support in areas such as communications, leadership, mentorship, and many others. I'm so happy to see more books, more blogs, and conferences like this one happening to support staff-plus engineers. Companies should be proactive about providing the support, and not expect engineers to just learn on the job. If you are or were or you're thinking about becoming a manager, that's ok too. Charity Majors wrote an article on the engineer/manager pendulum. That makes a great case for changing tracks every few years. This flexibility can make you both a better manager and individual contributor as you change roles. There's a lot of transferable knowledge between tracks. It makes you an individual contributor with stronger leadership skills, and a manager that's still up to date with tech and maybe have more empathy for engineers, day-to-day.
What The Staff-Plus Engineer Role Looks Like
You get promoted or you're a staff-plus engineer, what does that role look like? It depends. It depends is really a phrase for all of us when we're talking about technical tradeoffs and other decisions that we have to make day-to-day. Your role and your personal development depends too. It depends on the company size and how teams are organized where you work, what level your manager is at, your role expectations. Maybe you have a career level definition in your company, how it's defined in that level. How autonomous you're expected to be. It also depends on your own personal experience and your preferences, and what kind of engineer you are. This role goes also by many names. After the more traditional senior level, the next level can be called staff, or principal, and after that distinguished. Again, it depends on where you work. They usually have one thing in common.
One of the main changes that happens when you are promoted into this type of leadership role is that you're expected to be more autonomous. This might mean that you're expected to be closer to the edge of the team that you work with, so being a bridge between your team and the rest of the organization. Or it might even mean that you're no longer part of one team. You might be working with groups of teams regularly, or changing teams depending on your goals. You usually don't belong to one specific team for a long time anymore. How does that change impact you? Before, when you were in a team, your goals were your team's goals. You could also have your own personal goals, but your main focus was to deliver on your team's goals. Now that you're not part of the team anymore, how do you know where you should be focused on? Before, you joined all your teams' meetings and communications, now that you're not part of the team's rituals anymore, how do you know what's going on? How do you keep context of what's happening? Before, you were evaluated mostly on execution and delivery of projects, you're now evaluated on your leadership skills, strategic thinking, communication, coordination. Coding is just one of the many things that you do, so what else should you be doing?
Work Scope of the Staff-Plus Role
This role change not only expands your scope, and your impact, but it also changes the kind of work that you do. Let's talk about how you can find this new kind of work. If you don't actively think about your goals, it's easy to be busy and not be impactful. This busy work can be urgent work fires, or even work that you're not the most suited person to do anymore. For example, if you're continuing mostly coding when there are better ways for you to be effective. There's plenty of busy work to be done, but you know that that's not what you're supposed to be doing. That's not the highest leverage work that you can do. You know you should be doing high-impact work, so where do you find this magic backlog of high-impact work? You create it yourself. As a staff-plus engineer, it's up to you to identify and define what you should be working on. Your role now is to gather context and evaluate opportunities to help shape what you and even other teams should be focusing on.
Creating and Prioritizing Backlog of High-Impact work
I'll talk through the process that I use to help me create and prioritize this backlog of high-impact work. What I do is I create a personal backlog of ideas, problems, areas to investigate, similarly to how a team would prioritize their work. A little caveat here, what I'm describing was not defined in one day. It was an iterative, and it is an iterative process that I use, and improve and change gradually as I use it, and I learn more. I hope this talk will give you a kickstart with the process if you want to take it on, but it's really up to you to take it on and shape it to your needs and your preferences. Let's go through the process.
1. List All Inputs
A backlog needs a list of inputs first. These are all the possible things that you could be doing. Some of the inputs you should look into, so first, business and product strategies. These are your main drivers. Do you understand your current business and product strategies? Do you know how your product or your team's areas fits with the wider company's strategy? At this level, you should be learning more about how the business works and how other departments work, and working very closely with product leaders. Think about expanding your network beyond just engineering. Think about what's coming up next quarter or next year. Are there any risks and opportunities? What can you do to help prepare, disambiguate, and evaluate ideas? Secondly, you think about the team's needs. If you're working closely with a team or a group of teams, think about what they might need. Are there executional challenges ahead? Are there riskier, more ambiguous projects that you can support? At this point, what I do is review the team's plans and roadmaps for the next quarter to spot anything that might need more support. I also talk to their managers and ask what support they think they might need or their team might need in the coming quarter. This is where you can think about the future as well. Is there any work that you can help prepare or disambiguate ahead of a team, so it's more concrete and validated by the time the team takes it on? Another area for input is your department, in the engineering organization you work for. Are there cross-team initiatives that can elevate all of engineering that you want to propose or join? For example, there could be technical strategies across engineering, what kind of technologies you're using, automated testing, and so on. Also, it could be about recruiting, broken processes, operational issues. They're not just for managers, having input from engineers is really important too. I also added here some tips for managers. Sometimes it's hard to know what we can expect from your manager now that you're in a more senior role. Here's something that you can expect from them. Your manager can help you to make sure that you have access to the context that you need. They're probably in leadership and across meetings that you aren't. They can support you by sharing context and creating connections to leadership and other teams.
2. Prioritize Inputs
Once you have a list of inputs, prioritize them by company needs first. Your main goal should be the most important thing that you're doing to help with the company goals based on their strategy. Sometimes that might not be the thing that you're spending most of your time on. By calling it out as your top goal, this means that you drop all other goals to get this going if needed. Next, think about riskier areas. Maybe there are product or technical risks. Maybe it's a complex project, or there's a new problem space that you haven't dealt with before. There could be operational risks, or some performance risks, or scalability risks, or even organizational risks. If there's a new team forming, or there are teams that are lacking senior engineers' support. Finally, match your personal growth areas with these initiatives you identified and prioritized. Think about what feedback you got in your last performance review. Review the level description for the areas that you need to develop. For the areas that you're strong at, what does the next level look like? Can you stretch yourself? You should identify any initiatives that you want to drive or make the case for that will help you with your personal growth goals. You frame the goals that you prioritize based on company priorities and risk by also explaining how they'll help you grow as well. Here managers can help you by giving good performance review feedback and identifying opportunities. Also, don't forget to ask your manager what's going well, and ask them to explain why. It's really helpful to hear back from managers what we're doing well. Your manager can also help by putting their weight behind an initiative and formally sponsoring a project that you're proposing.
3. Trim It Down
Finally, this list that you created is gold. You have a prioritized list of impactful work, and you won't have time to tackle it all. How do you trim it down? With delegation. Are there opportunities for delegation? Mentoring and growing engineers is part of your role as a staff-plus engineer. You need to be a multiplier and share what you've uncovered. Your manager can help find opportunities for delegation. What I do is I chat to managers, my manager and the teams' managers that I work with, I share this backlog that I identified and see if I can help others grow by delegation. If I spot anything that would be beneficial for someone else to take on, then I'll talk to that person and see how I can support them.
Write It Down
Now, you have an achievable list of prioritized inputs aligned with your personal growth goals, and prioritized by company needs and risks, it's time to write it down. Write it down in the tool of your choice, something that you feel comfortable with, that's easy to refer to and update. I use a spreadsheet, but that might not work for you. Pick the tool that you're most comfortable with. Here's the format that I use. Each row is a goal. I'll go through the columns now. The first column is a copy of the principal engineer level area, and I use this as a reference. This makes it clear how this goal aligns with my personal growth goals. This is how my managers measure my impact. It's good to have that as a reference. Align the scope and impact expected with the area that's the focus of that goal that I set up. The next two columns are the most important ones: commitment and impact. Commitment is what I'll do. I'll deliver on a technical strategy for an area. I'll write a new version of an interview rubric, or I'll support an engineer as they drive a risky project. Impact is, if I do this right, what benefits would we see? How will the world be a better place if I achieve my commitments? This part is quite hard to articulate. If there are any ways at all that you can measure this with metrics, definitely do that. Anything that you can track is definitely easier to understand the impact. That's amazing. If you can have it, use it. That's not always possible for every type of goal. Another thing that I've found super helpful is feedback from the people who you're working with, and hopefully have benefit from the work that you do. This can be very helpful too. The final two columns are about setting expectations of my involvement. The role is, am I the one driving it? Am I part of a working group? Am I on the hook for it, or am I supporting someone else? The last one is just defining which one is the main goal. For the main goal, it means I will drop something else to finish this if needed.
Here's an example, I'll talk through it. The level of description for a principal engineer at Intercom says that we need to monitor and raise the bar for a good technical design. This is the area that's related to this goal. The definition of the commitment is to define and implement an engineering-wide metric for code quality. The impact that we want to get with this is that teams can monitor their code quality and invest in improvements when needed. I think if I would rewrite this one, I actually try to find a metric or something that we can track. For example, if the quality was around testing, maybe testing coverage, or if it was around updating or upgrading some technology, it will be how many teams have done that already, something like that. The role for this one, I'm a driver, so I'm the one doing the pushing for this project. It's my main goal. The second goal, another level expectation for principals at Intercom is that we grow capacity at staff and personal level. We're helping other engineers be promoted and get into that track. The commitment here as an example is that I'll coach Anna on a project she's driving. I'll have one-on-ones with her, and I'll join early project scoping sessions. The impact is that Anna has support needed to work on her growth areas and submit a promotion proposal for next cycle. The role for me is I'm a supporter and it's a secondary role. I hope that gives some shape and idea of what that document looks like and what goals I'm talking about.
Share It
You have a first draft, but you might still be missing some context. Now it's a good time to share it with others. First, ask for feedback and any expectations from your manager. Hopefully, this is a continuous process, and you've been getting regular feedbacks in your one-on-ones. This is more about confirming you think you're done, and asking them, is there anything missing, or do I need to change anything before you can share more broadly. You can share with your peers, other staff-plus principal engineers. That's also a good time to check that the riskiest areas that you all know about have the right coverage from staff-plus engineers. Also, share it with cross-discipline peers. If you work closely with designers and product managers or others with context in the area that you're working on, share it with them. This is a great way to answer that question of, how do I know what's going on? How do I keep context? It helps both by forming relationships with teams and other disciplines. Also, for you to get a context on what you might be missing by not working with teams as closely anymore. Those conversations can also help you manage upwards, be the voice of tech and help your manager and other leaders understand what's important. Your conversations about your goals can become pollinators of context, sharing it with folks as you explain your goals and why they are important.
Once it's done, and you and your manager are happy and you have your goals, you can share it with everyone that works with you. Once my manager and I are happy, I write a publicly available version of that spreadsheet, that's a written document that's easier to digest, really short. That has my goals, my commitments, and the context on why I prioritize those areas. Sometimes, if you're expected to be working on something that you're not, it's also useful to add that and explain why you didn't prioritize it. I use this document as a chance to reiterate how principal engineers work and what to expect from me. Sometimes I might be working more closely with a team and sometimes I might be more hands-off. It's a good place to clarify how teams can work with me and what they can expect. This is not a one-off process. You should find the right cadence for you to review and iterate on your goals.
Track Progress
This is my timeline. I'll talk you through it. At my company, we plan quarterly roadmaps for teams. It's a good cadence for me to set my own goals per quarter, as teams are prioritizing their goals. I define my goals quarterly, and then we break each quarter into two cycles, so it's two, six-week periods. I break down each goal into milestones that I want to achieve within that six-week period. Breaking it down helps estimate and it's really much easier to think about what you can achieve within six weeks rather than the whole quarter. Then, yes, we have weeks. I also use this cadence to track my progress. On a weekly basis, I review each milestone and quarterly goal that I have, and then plan my next week based on the progress that I want to make. I also use the weekly reviews to keep track of what I've done, of my actual progress. I write down what I achieved in the previous week, including links to artifacts and any outcome or impact that I had. I also write down any positive feedback or things that I'm proud of. It'd be really nice to keep track of that as well. I use the second six-week period when it starts, to review my progress overall and reprioritize, or rescope the goal if needed. It's a really good checking point to look at the full picture and see, will I achieve my goal in the next six weeks or not? When the quarter comes to an end, I review the previous quarter's progress and decide what if anything to carry over. Most goals are either done, or they can be dropped, or they change into something else as I learn more.
Over a quarter, it's great to look back and see the week updates and see each step I took to achieve a goal, what went well, and where things got derailed. Because it's really important to adapt and change if needed, because change is going to come definitely, we can be sure of that. You have your goals. You're happily working towards your prioritized goals, when someone asks you to do something else that's also mega urgent, important that needs to be done right now, what do you do? First ask yourself, am I missing context? Have things changed since I set my goals? That's possible. Things change, as I said. Goals are not set in stone. This is not something to constrain you, it's something to help you. If things did change, reprioritize. Talk to your manager and reset your goals. Another thing to think about is, can it be delegated? Is there anyone else that can take this over? Again, talk to your manager, talk to other managers, they can help you find a home for this problem. If not, say not now. Don't say no, just say "not now", and explain what your other priorities are, and why you can't tackle this request right now. I usually find that when I explain the reason behind my no, or my not now, people are very understanding. You can take note of that request too, and this can be a good input for your next goal setting period.
What About Coding?
Sabrina, what about coding? This is an individual contributor role after all. How do you find impactful coding work? I believe as staff-plus engineers, we should still be shipping production code and delivering customer value. It might not happen every day, but it needs to happen enough that we understand the shape of the code base and the problems engineers and our customers have. How do you find the time? The same way that you define any other of your goals: setting your priorities with your manager and carving out the time for that. Think about why you want to spend some of your time coding. What are you trying to achieve? What's the impact? As an example, when I joined Intercom, I joined as a principal engineer, which is another interesting way of being onboarded as a principal engineer in a company. When I joined Intercom, I needed to get an understanding of the code base. It's quite a long-lived code base, a long-lived product, there's a lot to learn. What I did was I joined the on-call rota for a couple of teams for a few weeks. The goal was for me to get a broad experience in our code base and get deep dives into the code base, guided by real customer problems. On-call provides a great learning opportunity. If there is an incident, an issue, or a bug reported, that's showing me two things, there's a valuable area that someone cares about because they reported an issue. There's something that could be made better there, whatever that is. It's a great signal that this could be an impactful area to work on. When you're coding, go beyond just fixing the issue at hand. When you're taking on coding tasks, you can use your skills to think beyond the task at hand and spot patterns, opportunities, and problems that you can address in a more holistic way. This can be input for your next goal setting period, for example, and proposing a project in that area. You have the scope and the experience to identify and then advocate and gather resources to help solve some of these wider problems you spotted while coding.
Beyond Goal Setting
I found that setting my goals intentionally thinking about my time, and what I'm doing intentionally, helped me beyond my personal development. One of the ways that it helps me is onboarding. It helps me actually set expectations and introduce my role to new teams and new teammates. Given how much the role can change, depending on the company and even the person or the time of the year, it's useful to have a reference of what you're doing and why. For example, when someone new joins a team that I'm working with, I can point them to that public document that I mentioned, and say, "This is what I'm doing. This is why. This is how you can work with me." It helps me focus. As I just said, say no. It's a lot easier when you can say why when you say no. Say no if more comes up, or intentionally reprioritizing if needed, instead of just jumping from one fire to the next. It also helps me not getting distracted by those fires, or by the urgent non-important tasks, that busy work that I talked about. One of the things that I really like about this process is that it helps me keep motivated. I find that as leaders, our feedback cycle is less immediate. Changes take longer. Or you might get caught up in fighting fires every day that you forget the big picture. I need to find ways to keep energized. These quarterly goals and their weekly reviews are a way for me to keep myself motivated and energized and understanding and seeing the big picture of why I'm doing the work that I'm doing day-to-day. Finally, because I tie my goals to my level, it makes my self-assessment for my performance review a lot easier. For me and my manager, I have a story to tell of what I've done and the impact that I've had.
What's Next for You?
That helps showing when I'm ready for the next level. This intentionality in setting goals and defining how you spend your time can also help you reach your next career level. Each time that you set your goals and you review your progress, you're creating a track record of what you've achieved, and the impact that that had. When you pick your goals that are aligned with your personal growth goals, you'll be exercising those growth areas and showing how you have progressed. You can point to it and say, this is what I've done, and this is how I progressed. Where do you go as a staff-plus engineer? I'll say it again, it depends. What this means to you depends on your company, the trajectory that you have there, the career levels that they have at your company. It really depends. Extending your role as a staff-plus engineer usually means increasing your level of impact and scope. Maybe you're working with a team, and then you're working with a group of teams, then you're working with groups of teams or the whole organization. Sometimes you might be at the top of the career ladder for your individual contributor track. At that point, don't be surprised if you'll be asked to help define what the next level looks like. You might be defining the role yourself by the work that you do. It's part of the autonomy and the seniority of that role, and it's a quite exciting thing to do. You could also think about going to management. At Intercom, we've had many examples of engineers becoming managers, and then coming back to engineering and some even going back into manager again. My colleague Dave Lynch wrote a great blog post about it.
Summary
As a staff+ engineer, your role now is to gather context and evaluate opportunities to help shape what you and other teams should focus on. It's important to really think about what you want to achieve and why. You can do this by creating your backlog of high-impact work. Prioritizing that backlog and trimming it down by using delegation. Getting feedback, and sharing your goals. Breaking it down into milestones and tracking your progress, and repeating it. It's not a one-off process. Exactly how you do this, it's up to you. As a senior technical leadership level, you must be intentional about your time and the work that you do. It's part of your job now.
See more presentations with transcripts
