Transcript
Gupta: My name is Akhilesh Gupta. I'm an engineer at LinkedIn here in Mountain View. As an important part of my role, I mentor other engineers at LinkedIn. A very frequent question from my mentees is, how do I grow to the next level? I usually respond by saying, you need to grow your scope and impact in the organization. Which is obviously followed up by, how am I supposed to have more impact? To which I usually say, work on more impactful projects. By this point, I've totally annoyed them. They either say that the best projects are already taken by others in the team. Or that they feel constrained by the scope of the team they are currently working on. Or that their manager is unable to find them the right opportunities. I'm here to tell you that you can be a staff-plus engineer, even if all of these are going against you. Even if you have a manager who is far from ideal, even if your team has a tiny charter, and even if you're not automatically chosen to lead the biggest projects in your organization.
At this point, you're probably going, how? Let's start with a scenario, and you will tell me if you've been in the scenario before. You start your new job as a senior engineer. They've assigned their architect, Lisa, to give you a rundown of their shiny, new tech stack. They tell you, everything is so modern in the stack. Their iOS app is on Swift. Their web app is on React. They use GraphQL because REST interfaces are so '90s. At this point, you're starting to feel that all your skills in Objective-C and REST API interfaces are going to be absolutely useless. Then she tells you about the backend. It was built by some legendary engineer five years ago, who is now the CTO at a stealth startup. She tells you to ignore it, because no one really knows how it works. What are your peer engineers talking about at lunch the next day? You hear your peer engineers complain about the backend. It's written in C++, but no one in the team knows C++. The code base is 30,000 lines of code. It's deployed once in two months. The deployment process includes manual validation of the entire app by an external contractor. No wonder none of these contractors really last for more than a few months.
Who has been in a situation like this? I bet almost every one of you at some point in your career. As you spend more time on the team, you see how the backend is making everyone's lives miserable. There are frequent production issues. People have to be on-call all the time. Managers are complaining about wasted engineering cycles. PMs are complaining about impact to customers and the business. When you hear complaints like these, you have two choices. You can join in and make more complaints about how everything is messed up, or you can think of this as an opportunity. Raise your hand and decide to fix that problem for your team and your organization. Which choice do you think gets you closer to the staff-plus engineering role? Yes, of course, the second one. If you keep making that choice, you will keep broadening your scope of impact and ultimately land that staff-plus role. Let me tell you how. I will show you how you can recognize such problems and use them as opportunities to solve hard technical problems to grow your career.
Six Steps to a Staff-Plus Role
Let's first talk about how you recognize such problems. What were some characteristics of this problem that I just presented? It's super tedious and challenging. Everyone is complaining about the problem, but not many are willing to do anything about it. It's impacting more than just your immediate team. It's directly or indirectly having a negative impact on customers or the business. In other words, addressing the problem will not only make your peers and managers happier, but it will also matter to the business. You have now recognized a problem worth solving. Let's go a little deeper into what you may need to do to pursue a solution to this problem. You're all excited, and you go tell your manager that you want to work on refactoring the backend. The first question she will ask you is, why? This is probably the most important question you will answer in all your projects. What is the motivation behind your work? If you get this right, most of the battle is already won. Then, she will coach you to make a business case for solving the problem, so you can convince the leaders of the organization to work on the problem. You will answer three important questions. Why is the problem important? What are the various aspects of the problem, and the requirements from the solution? How do you plan to solve the problem? This is also when you will encounter the two most dreaded terms in the life of a senior engineer, the level of effort and the return on investment. Both are critical to making a business case for solving a problem.
The first question you should ask yourself after identifying the problem is, what are the soft skills needed to solve this problem? In this case, you may need to connect your project to business impact. Maybe it's faster product iterations, or developer productivity, or the ability to free up maintenance and operation's bandwidth. You may need to write a document to communicate your motivation. Get feedback from peers. Convince your peers that this is worth doing, and convince clients of the backend that a migration is worth it. You may need to gain alignment with execs. You need to present your ideas in various engineering forums in the company. You would need to align with non-engineering leaders, like product managers, who would be worried about the cost of refactoring the backend against current product priorities. These are all things that I have been most uncomfortable with in my own career as an engineer, but they keep showing up over again.
You finally convince everyone, what next? You now need to come up with a technical plan to make this happen. For this problem, you will need many technical skills: understanding the backend's code base, creating microservices, defining better models, maybe API interfaces, and of course, a ton of refactoring and modularization. Maybe even defining a client migration plan when your refactoring is done. Doing this exercise will give you a vital understanding of whether solving this problem will help expand your skill set as an engineer. How should you evaluate whether you want to pursue a solution to this problem? You should again, ask yourself a few questions. Are you interested in solving the problem? Will it energize you to do the hard, tedious work to solve this problem? Do you believe in solving the problem enough to see it through all the eventual roadblocks? Because you will have to convince people across organization boundaries to make this happen. Are you willing to learn the technical and non-technical skills required to solve the problem? In most real-world scenarios, you will only possess maybe one or two of the skills needed to solve the problem. Maybe you have no prior experience in the other skills needed. You may need to go outside your comfort zone and embrace these skills to succeed.
What should you keep in mind while developing solutions to this problem? If you're refactoring, are you building tools that can help make future refactoring tasks easier? If you're having a hard time recognizing clients on the backend, are you building reusable tools to make it easier to do so and find these clients the next time? If data migration is turning out to be hard, are you building a generic data migration tool for your storage solutions? What happens when you do this? Your work starts to have an impact way beyond your organization, because there are other teams struggling with the same problems. Always ask yourself, am I building reusable tools and libraries that others can use in similar work? We now have a good framework for this. You seek and recognize impactful problems. You evaluate whether a given problem is worth solving, and build a business case for it. Then you determine the technical and non-technical skills needed to solve that problem. Of course, you ask yourself the right questions to determine whether you would be interested in solving the problem. That's paramount. If you decide to do it, you practice the skills that are outside your comfort zone. While working on the solution, you develop generic tools that others can use when they are solving similar problems. That helps you multiply your scope of impact beyond just this immediate problem.
How Learnings Are Applied
Let's go through a few more scenarios to see how we can apply these learnings. Let's say you write a plan for refactoring the backend, and you want to get some feedback on your proposal. You ask the engineer John, who is sitting next to you, and they tell you that they have a weekly design review meeting. He gives you a link to sign up for it. You go up and open up the signup sheet, and you find that the next open slot is months away. You demand an explanation. John tells you that the design review is headed by His Excellency, the Distinguished Engineer, Mr. C# himself, and everybody wants in on it, so it's not easy to find a slot. You know who I'm talking about, the uber-tech lead that everybody is afraid of. You're obviously quite curious to know what goes on in these design review meetings, and so you decide to attend the next one, just to see Mr. C# in action. The meeting starts with a super complex 50-minute presentation. The presentation is only about the solution without any mention of the problem. Everyone pretends that they understand everything and no one except Mr. C# says anything at the meeting. The last 10 minutes of the meeting, he asks a completely unrelated question about the possible use of neural nets in the solution, and the meeting ends.
You come out of the meeting, and John complains to you how he didn't understand anything in the design review, and hates going to these meetings. The presenters complain that they didn't receive any useful feedback. How many of you have been in at least one design review meeting like this one? Once again, you see a significant problem. You can think of this as a huge opportunity to do something about it. Let's apply the framework we developed before, and start with understanding the scope of this problem. This process has been used in the team forever, and it's hard to change it. Most engineers are not happy with it, but no one is really doing something about it. It's definitely impacting more than just your team. You find out that design reviews are generally run like this in the entire organization. Since engineers wait a long time for a slot for these design reviews, and don't really get any helpful feedback, they end up delaying their projects, which slows down the team and of course slows down the business.
Skills Needed to Address the Problem
Let's see what skills you need here to address this problem. The first thing you probably need is to become vulnerable and authentic, and inspire others to be the same. You may do that in your next design review meeting by asking for a clear definition of the problem being solved. The funny thing is that when you ask these questions, everyone in the room, including Mr. C# is probably thanking you for it. They're like, finally, I understand what we're talking about. Or you suggest that people be allowed to raise hands and ask for clarifications any time during the review. You exercise that ability to influence and inspire your peers to make better use of their time. You help engineers realize that problems may be complex, but the solutions must be simple and easy to understand. You may also take a totally new approach and propose that instead of one-way presentations, the team should pre-read a two-to-three-page design document and use the meeting time to actually discuss some of the most important areas of the design, so that engineers who are working on that project can get feedback on specific areas.
You may need the skill to convince everyone to try out your new model. Once again, you need to write a proposal, get it reviewed by maybe your peers, maybe by management, and gain more consensus to update how you do design reviews in your organization. Finally, if your revamped design review process becomes successful in your team, again, you may want to share your proposal for running efficient design reviews throughout your organization, and have a much broader impact on the entire engineering organization. At some point, you all have probably thought to yourself, I'm an engineer, do I really need to practice all these non-technical skills? Ultimately, you're solving a real problem for yourself and your peer engineers. These skills are helping you make that happen. Each of these skills is a very valuable skill to develop and grow as a senior engineer. Some of these skills will definitely be uncomfortable, and that's ok. This is exactly where growth occurs towards a more senior role.
Technical Example 1 (LinkedIn)
I now want to share two recent technical examples where I applied this framework that we just discussed. I hope this serves as an inspiration for you to find challenging technical problems in your own domains. At LinkedIn, I've been working on messaging for some time now. One of the aspects of instant messaging that makes it challenging is that users interact with each other in real time. This is not too big of an issue when users are being served by the same data center. This becomes a significant challenge when users are interacting with each other, and are routed to completely different data centers because of their geographic locations. Imagine, Alice from the U.S. sends a message to Jane in Australia, and they're pinged to different data centers. In a naive implementation, Alice would write the message to Jane's mailbox in our own data center in the U.S. This message would then eventually get replicated to Jane's data center in Australia. Jane would see the message only when the replication finishes. This replication can take multiple seconds. As you can see, this naive cross-data center replication strategy doesn't work too well for instant messaging.
Apart from LinkedIn messaging, I started noticing that other products and services across LinkedIn were running into a very similar problem when they were trying to build a live interaction with each other across multiple data centers. At this time, we were also building products like live video. We were doing events, live audio rooms. It seemed like a pretty universal problem for such experiences. This is obviously a very challenging technical problem that we have to solve. I started applying the framework that I shared with you. Many teams were complaining about a lack of a strategy to address this issue. People were resorting to brute force solutions instead of a common solution in our infra layer. The scope of the problem was clearly beyond messaging. Sure, we could have solved it only for messaging, but there was clear scope for this problem to be solved more generically. It clearly mattered to the business as we would not really have been able to ship all these important product experiences without a solution to this problem. Or maybe we would do so with expensive individual solutions at the application layer. It had all the right ingredients for a problem that needed to be addressed with a common solution for the large engineering organization.
Next, I evaluated the skills I needed to develop to solve this problem at the right level. I obviously needed many technical skills, like understanding cross-data center routing at LinkedIn, understanding cross-data center replication in our data layer, understanding atomic commit protocols on databases, and doing tradeoffs between latency and cost to serve. Apart from that, I also needed to evaluate whether we should leverage our open source solutions or build something in-house. These are all great skills to pick up for a systems engineer to grow to a staff-plus role. Even more than that, I needed many of the same soft skills that I mentioned earlier. Gathering requirements from other teams with the same problem. Building a business case for solving this problem at the right infra layer, so that all applications could leverage a single solution built within the infrastructure, connecting the work to business impact across application teams, and gaining alignment with storage infrastructure leads and executives. Of course, to do all of this, I needed to describe the problem and propose a solution with clear written technical communication.
You may wonder whether all this effort is worth it, to build a common solution instead of just solving the problem at the application layer for messaging. Such problems give you that opportunity to broaden the scope of your impact, and solve this problem not just for your team, but for similar use cases beyond your immediate team. In this case, we ended up building common remote data center write APIs, and common libraries to route traffic to objects and entities ping to a certain data center. Working with my peer engineering leaders across the company to solve this common problem, was a very important skill that I developed in my path to a staff-plus engineer.
Technical Example 2 (LinkedIn)
Let's go through one more technical example where I encountered a problem, I recognized a pattern, and built a generic solution, which is now widely used at LinkedIn. Going back to my work on LinkedIn messaging, this diagram represents a very simple view of the messaging delivery flow. A sender sends a message. The messaging server does some preprocessing to authorize the send. Then the message is persisted in the backend. Finally, after persistence, the message is delivered to the recipient device. If the preprocessing fails, we simply return a 4xx response to the client. If the message passes that step, a payload is passed to the persist message operation, and a 202 is returned to the client. The reason for that is that the persist message operation can possibly take longer, and we don't want the client to wait for that to complete. The challenge with this flow is that the persist operation can fail, and we can't really expect the client to retry for these server failures. We need to make sure that the persist message operation completes reliably, once we send back the 202 Accepted to the client. It's now the server's responsibility to finish persisting the message that the sender sent. This is where we realized that we need a durable queue, which can queue up these persist operations, so that when we process these operations, and do it asynchronously, we reliably complete them. We also realized that this circle part of the flow is actually pretty generic. We built this generic solution for reliable processing of queued operations, where a job processor is responsible for completing these operations, and retrying any operations that fail so that we never lose any individual operation.
Going back to our team here, this needed me to learn many new technical skills. I need to build a solution with strict requirements. I needed exponential backoff with retries. I needed durability of the operations across deployments and failures. I need to evaluate various open source and in-house solutions for an asynchronous operation queue, and job processor. These were all invaluable technical skills to pick up. Even more importantly, this pattern of reliable async processing needed a generic solution for many of the problems elsewhere in the company. We needed it for async completion of large, bulk operations from end users like GDPR data export, and for operations that needed 100% reliability, like payment processing. Building this solution generically gave me an opportunity to have an impact on teams outside my organization that I would have almost never interacted with. Remember that evangelizing your solution is as important as building it. Other teams need to know that you built a generic solution that addresses their needs for them to be able to leverage it. Use the forums in your engineering organization to evangelize what you've built so that others can find value out of it.
What Can I Do as a Leader?
Let's take a second to see what you can do as a leader in your company, to support your engineers looking to take this path to organically grow into a staff-plus role. First, when you hear engineers complaining about their tech stack, and their engineering processes, don't shoot them down. Help them channel that energy towards understanding the root of their complaints, and solving the tough problems behind them. At LinkedIn, we actually encourage constructive criticism that actually leads to action, and that motivates engineers to become part of the solution and grow themselves. Second, we are living in a world of truly async communication. I want to encourage leaders to create regular forums in which engineers get to take a step back and talk about things that are going well, and things that need improvement. This will help plant those seeds in the minds of these individual engineers to start dedicating themselves to solving some of their own challenges.
Coach your engineers to sell their ideas and proposals. I'm sure an engineer at some point has come to you and said something like, I think we should use GraphQL. Ideally, the first question you would ask them is why. Why should we do this? What is your motivation behind this? This immediately helps them start reasoning about their proposal in a way that is critical to be able to convince others. They might say it's the next best thing. It's so much better than REST APIs. Then you ask, why is it better than REST APIs for us? This is when they pause, because you specifically asked them why it's better for us. This forces them to think about a lot of things that they may not have considered. What is it about our company and our systems where GraphQL would have an advantage over existing REST APIs? What would the migration look like for us? What would be the level of investment needed to make that move? What do we specifically gain from this migration? Hopefully, they say, let me think about this and get back to you. At which point, you should encourage them to write down their motivation in a document, get feedback from the team, and iterate until they reach a conclusion for themselves for whether the team should be moving to GraphQL or not.
Finally, don't hesitate to create training programs to help your engineers develop the soft skills that are needed to grow into senior roles. At LinkedIn, every few months, we dedicate an entire week to these classes that are actually run by staff-plus engineers, targeted at engineers early in their careers. The classes cover a broad range of topics, like workshops on technical communication, documentation, public speaking, understanding the business, and even presenting to executives. There is something extremely powerful about your staff-plus engineers sharing their own experiences, in how they develop these skills with junior engineers directly. We actually call it the IC Career Development Week. It is one of the most successful programs at LinkedIn. Almost all engineers at LinkedIn go and attend these workshops based on their interests and hear what their senior engineers have to say to them.
Big Takeaways
I think we covered a lot of ground. Let's summarize the two takeaways from this presentation. First, you do not need to wait for someone to assign you a big project to grow your career. Meaningful, impactful problems are waiting to be solved all around you, as long as you're willing to keep a keen eye for them. Engineers complain about the systems and processes all the time. These tedious, unattractive problems could be your biggest opportunities to solve hard technical issues with massive impact on your organization. Solve the problems that no one explicitly asked you to solve. Second, lose your fear. Beyond your technical skills, you must embrace the soft skills needed to solve these problems. You have to do that if you want to solve the problems at scale, even if they make you uncomfortable. Understanding the business, aligning with non-engineering leaders, presenting to executives, written communication, and even public speaking, are all skills that all engineers must constantly practice.
When you get back to work, go find your most vocal peers, the ones who never stop complaining, sit down and listen to them. Apply this framework for recognizing and solving impactful problems. There are like big technical challenges hidden behind each of these problems, except maybe some of them. If you do this, I promise you that you will discover impactful projects to organically grow into the staff-plus role at your organization.
Questions and Answers
Nardon: How many years did it take to land staff and principal position from the senior role?
Gupta: I think the place that engineers are coming from is like, is there a set timeline for when I can grow to the next level? Or, is there a specific amount of time that leaders expect somebody to spend in a particular role before they consider them for promotion to the next level? I think more engineering organizations today are not really worried about the time that you've spent in a particular role. They're much more worried about how much impact you're having on the organization. This is clear from the fact that so many of my peers at LinkedIn, and even at Uber, when I was working there, have a very broad set of timelines that they have followed in different roles in their organizations. It's not that everybody spends the same amount of time being a senior engineer before being promoted to a staff engineer, or that they spend the same amount of time being in a staff engineering role before being promoted to a senior staff. The reason for that is that everybody has impact in a very different way. Impact itself can be achieved in a very different way. The way I would think about it is, are you having fun? Are you doing projects that get you excited? Are you having meaningful impact on your organization? When I say meaningful impact, it goes back to the same stuff that I spoke about in the presentation: it must have clear business impact. Again, everything is a business. You must make sure that the projects that you're working on, the problems that you're solving, have clear, meaningful business impact. As long as you're doing that, and you're increasing the scope in which you're having that business impact, you will ultimately grow to the next level.
For my personal situation, I actually switched from LinkedIn to Uber when I was a staff engineer, and I spent about one-and-a-half years there as a manager, not even in an IC role. The reason I did that was because I just really wanted to get that management experience. Fabiane is a pro here, but she will tell you how it's so important to understand how management works, apart from how ICs play a role in an organization. That experience really helped me because now I could understand how the business works, how everything needs to connect to business impact. That made me a much better IC. That helped me when I came back to an IC role and helped me grow into a senior staff role and then a principal role at LinkedIn. I have been in this for about 12-and-a-half years.
Nardon: How many such impactful projects did you need to contribute on, to get promoted?
Gupta: Lots of them, at every stage of my career. There have also been projects on which I've worked on, which did not result in the impact that I was hoping for. This is also very important to understand. Sometimes we only talk about the positives, only about the fact that like, this is having amazing impact, or like, this moved sessions by 3%, revenue by 5%. There are also cases where you end up putting in all that effort, and the project doesn't succeed. One of the things that I've learned is like, even in those projects, you end up taking a lot of learning away. You end up recognizing, what are the things that you could have done better? What are the things that would help you not make those same mistakes in the next project. Even in projects where you realize that you haven't achieved the impact that you were hoping for, make sure that you work with your peers, to break it apart and understand where you could have done better so that the next time you're working on a similar project, you're learning from it, and doing better again. Almost in each part of my career, I've contributed to tens or even twenties of such projects. At the same time, I've also failed at maybe five or six of them in each part of my career, and that has helped me a lot in learning through my mistakes.
Nardon: How did you ensure that work was noted by the upper management to get you that role? How did your leadership help in uplifting you?
Gupta: This is very important, because it's really important to communicate what you're doing. As an engineer, your role is not only to execute, your role is to also clearly communicate what you're doing. Why you're doing it. What is the impact that it is having. What were the final results? What leadership is looking for, is for you to take on the responsibility for creating that impact to the business. They want you to clearly understand what the goals of your project are, describe them, and then evaluate yourself when you're done. When you finish doing that project, don't just be like, I'm shipped and I'm done, and move to the next project. Get to a point where you clearly evaluate what your results were against the goals that you had set for yourself. That is what leadership is looking for. They are trying to understand whether you can really, truly, frankly, evaluate yourself against the goals that you've set, and against the business impact that you promised that you would have, and what you actually had.
There's a theme in these questions, and I want to address that, which is, you're not only growing in your organization, you actually want to grow in the industry. It's not enough to be a senior staff engineer at LinkedIn. It's actually more important for you to be a senior staff engineer in the software engineering industry. What I mean by that is, don't worry too much about whether you are a certain title in your particular company. What is more important is, are you sharing your learnings broadly in the industry? That's where conferences like these come in. Talk about your work. Write about your work. Blog about your work. The more you do that, the more you'll be recognized as a software engineering leader, not just in your organization, but in the broader industry. That is way more important than a particular title in your company.
Nardon: What happens if what the company expects from you is not aligned with what you want for your career? Should you change jobs, change companies, or maybe try to change your expectation inside the company? Is it easier to be promoted to staff if you change companies, instead of being promoted inside your own organization. Should you change companies to be promoted, or should you try to be promoted inside your own organization? What's your experience on that?
Gupta: I'll first repeat the original answer that I gave you about what to do in a situation where what your skill sets are, or what your aspirations are don't align with the current organization that you're working on, or even the current company that you're working for. I think you took the specific example about being a frontend engineer, and your company not creating that environment for you to grow in that role, or having a broader impact in that role. I think one important thing to realize is, again, your organization and your company is a business. The way you're thinking about it is, am I having the business impact that is required for me to be growing in my career in that organization? If your aspirations are being technically deep in the frontend stack that you're currently working on, make sure that the project and the work that you're picking up is something that also connects to business impact for that organization. It is entirely possible that that isn't the case. Maybe the organization that you're working for, or the company that you're working for, is simply not spending as many cycles or as many projects diving deep into the frontend stack. In that case, it is actually the right thing to do, to either broaden your scope and say that, I'm also interested in frontend iOS technologies, or Android technologies, or frontend API technologies, or even backend or near-line technologies. That's one approach of going about it. The other is to find an organization within your company that actually values the work that excites you, and where your career aspirations lie. If not, find another company, find another organization that aligns with what your aspirations are. Because ultimately, you own your career, you own your growth. It's your responsibility to find the right team, to find the right organization that not only aligns with the mission and vision that you have in your mind for you, but also aligns with the work that you want to do. It's definitely something that you need to take control of.
Changing companies to grow into a new role? I wouldn't say that that is true, de facto. As an example, I switched from LinkedIn to Uber. I did management there for about two years, but I didn't actually grow in my role, the leveling was the same. I gained a lot of valuable experience doing that. The way to think about changing companies is, again, what I said in my previous response, which is, you would do that when it aligns with your own goals, when it aligns with your own aspirations. When you're going and doing something and changing your role or changing your company, do it with the explicit intent of growing yourself and finding the right problems to work on, which align with the business that that particular organization is aiming for. It's absolutely not true that you would just switch companies to grow to a staff role or a senior staff role. Because, ultimately, you would grow to that role only if you have that impact, which aligns with that business. The first order of business is to find the place where you can work on projects that align with the business goals of that organization or of that company.
Nardon: How do you find good mentors? In these roles, you have to do mentorship and coding, how do you manage time for everything? How much more time out of office hours do you have to do to keep up with everything? It's probably one of the biggest problems in the staff-plus engineer role.
Gupta: Good mentors. I think finding a mentor is definitely an experiment. You need to go out and talk to people that you look up to. I'm sure that in everyday work in your career, you run into people where you're like, I really like how they approach their work, or I really like how they think about their role in the organization and the contributions that they're having to the organization. Find such people, talk to them. It's all about this experimental phase where you understand where they're coming from, what their goals are, do they align with your goals, and try it out. Hang out with them over coffee, or invite them to a one-on-one. See if you're able to connect with them. See if you're able to ask them about the problems that you are running into. That is the right way to be connected with people that you look up to, and then find that one person who you really bond with and make them your mentor. That's probably the approach that I've been using.
Managing time is absolutely one of those things which is extremely hard as you grow into more senior roles. You must have heard this term over again, delegation is your friend here. The more you're spending time mentoring and helping other engineers succeed in the project, the more you're able to delegate work that is actually much better suited for somebody else's growth. Think about it this way. You are working on the things that help you help other engineers. You're taking nebulous business problems, converting them into concrete projects, and then having engineers work on them. If you do that, then you are spending your time on the most critical pieces for the business and not the stuff that other engineers could do.
See more presentations with transcripts
