Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Podcasts The Journey to Staff-Plus Engineer

The Journey to Staff-Plus Engineer

In this podcast Shane Hastie, Lead Editor for Culture & Methods spoke to Akhilesh Gupta, a Principal Engineer at LinkedIn about the journey to a staff-plus role.

Key Takeaways

  • A key part of the principal engineer role is growing other people
  • Find opportunities to identify and solve problems that are causing friction in the development orgnisation
  • Collaboration and communication skills are needed for effective staff-plus engagement
  • Mentoring others and being mentored is an important part of becoming a staff-plus engineer
  • There is value in trying management roles in environments where it is possible to move between the tracks


Shane Hastie: Hey folks, before we get into today's podcast, I wanted to share that InfoQ'S International Software Development Conference, Qcon, will be back in San Francisco from October two to six. QCon will share real world technical talks from innovative senior software development practitioners on applying emerging patterns and practices to address current challenges. Learn more at We hope to see you there.

Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Akhilesh Gupta. Akhilesh, welcome. Thanks for taking the time to talk to us.

Akhilesh Gupta: Thank you. Thanks for having me.

Introductions [00:45]

Shane Hastie: Now, we met at QCon San Francisco where you were talking about staff-plus engineering roles, and I'd love to get into that. But before we do that, tell us a little bit about who's Akhilesh.

Akhilesh Gupta: Absolutely. I'm the tech lead for a bunch of consumer facing platforms at LinkedIn like search and feed. And I also work on what is called the LinkedIn's real-time delivery infrastructure. So this is used for publishing messages, and live video indicators, and stuff like that from the server to the client. And recently, I've been working on recommending out of network content on feed for LinkedIn users. And it's tricky because LinkedIn is slightly different. We are actually interested in figuring out what you want to get done, and figuring out how content from your network, and content from outside your network kind of help you get what you're trying to do done. So very interesting recommendation and challenges there that I'm currently working on.

Shane Hastie: Interesting stuff. So you are a principal engineer at LinkedIn. What does it mean to be a principal engineer?

What does it mean to be a principal engineer at LinkedIn? [01:52]

Akhilesh Gupta: I think short answer is a lot more responsibility, but I think the long answer is, at LinkedIn specifically, a principal engineer is usually at the scope of what you would call a VP's organization. So specifically in my case, we have an organization called the consumer organization, which is focused on the consumer facing products on LinkedIn. We also have a talent organization which is related to recruiter products, and we have marketing solutions, and then we have sales solutions. So the one that I'm on is the consumer organization, which is the LinkedIn that you and I know about. And so at this level, we have multiple products like feed, and search, and profile, and so on. And so I am the technical lead for setting the technical vision and architecture for these areas.

So that's one big part of my job. But I think an equally important part of my job is to grow other engineers, and make them successful in my organization. And so a lot of my time is actually spent on making sure that I can have other engineers grow to senior roles, and have a multiplicative impact on the organization. And that's why I'm involved in some of these efforts to kind of grow our senior leadership roles at LinkedIn, especially on the IC side.

Shane Hastie: In that pathway to principal engineer, this is the staff-plus journey, it's not the management track journey. So for somebody who's interested in that journey, how do they get there? What do they do?

The staff-plus journey [03:25]

Akhilesh Gupta: So this is exactly what my talk was trying to highlight last year, and I'll try to capture some of the salient points there. I think first of all, I feel like a lot of engineers, the first thing they kind of think about when they're thinking about how to get to a staff-plus role is they're trying to figure out how to kind of create that kind of impact for the business, right? Because ultimately most tech companies today, they're kind of trying to estimate whether you can have the kind of impact, the scope of impact that you would expect from a staff-plus role to get you to that role. And most engineers, they feel that sometimes that their managers are unable to find them the right opportunities, or they feel kind of constrained by the scope of the team that they're currently working on, or they feel that the best projects in the company, the ones that are actually that kind of impact are already taken up by others.

So what I try to convey in that talk is that there are actually ways to find, and solve meaningful problems in an engineering organization that does not necessarily need you to wait for somebody to give you that opportunity. And so part of the path to growing to these roles is to find these meaningful impactful problems that are kind of waiting to be solved all around you. And you can do that by kind of identifying systems and processes that are not working really well in the realm of influence that you currently have, or in the scope of the organization that you're currently working on. And these are usually very tedious, unattractive problems. People kind of complain about build times, they complain about how hard it is to do, for example, multi-data center solutions, or building solutions that need to improve developer productivity in terms of how fast somebody is able to ship their code. These are all hard problems that engineers complain about, but don't necessarily think of them as opportunities to solve those with good simple solutions, and then create impact that way to grow into their roles.

And then finally, I spoke about the need for developing soft skills because that is one thing that engineers underestimate a lot. To solve problems at scale for a staff-plus role, you absolutely need to understand the business, you need to kind of figure out how to align with non-engineering leaders, you need to present to executives, you need to have really good written communication skills, and then even public speaking. These are all things that engineers must constantly practice. I think if you add all of these, you are on your path to a staff-plus role.

Shane Hastie: Now, many of those things are not areas, particularly, when we step out of the deep technology into interacting with others. These are not things that are taught in the engineering schools.

The need for people skills [06:06]

Akhilesh Gupta: Yes, that's a great point. And that's part of the reason why a lot of engineers, they're like, "This is all non-technical stuff. Do I really need to think about developing soft skills? Do I really need them as an IC? Isn't that a management thing?" But that's not true. As you kind of try to have impact at scale, you have to work with people. You have to convince others about your motivation for pursuing something. You have to convince others about the why, the what, and the how, right? And all of these need you to have those skills. So I think the recommendation that I usually give to engineers trying to aspire for this role is that even though they're not something that you're being taught directly, you need to practice them, right? Find somebody that you can kind of riff with, send them a document talking about the motivation of why you're trying to pursue something, see if you can get feedback, see if you can iterating on it, and then slowly and steadily you develop these skills.

And then yes, there are organizations, even at LinkedIn we do this thing called the workshops for people trying to grow into a senior IC role where we actually have senior ICs talk about technical communication, and documentation, and public speaking, and all of that stuff. So we are doing these little training programs. But at the same time, there's no replacement for just getting out of your comfort zone, and practicing this. Every opportunity you get, figure out how to kind of make it happen with some practice.

Shane Hastie: You spoke about part of your role in that principal engineer is growing other engineers.

Akhilesh Gupta: Yes.

Shane Hastie: How do we do that?

What’s needed to help grow other engineers [07:45]

Akhilesh Gupta: There are multiple facets to this, and I'll just take some concrete examples because that's helpful. So as I said earlier, one aspect is where I'm making myself available to actually participate in some of these talent building workshops, right? I would go out there, and share my experiences with how I have gotten better at technical communication. Maybe I will do a workshop on writing a design document, or maybe I'll do a workshop on presenting an example of creating a business case for a technical solution that I was trying to build, or maybe I will do a workshop, and presenting to executives from the perspective of an IC where I was trying to get something approved for the entire organization like a technical direction that I was trying to get approved for the entire organization. That's one aspect of it.

The others are, I do direct one-on-one mentorship for some of the senior staff engineers in our organization, and I also benefit from one-on-one mentorship from distinguished engineers, and fellows in my company who kind of return the favor.

The third aspect to this, and which is probably the most important one, is just direct code reviews. I think one of the best forms of growing other engineers is through reviewing their code, and providing feedback on how they're structuring their code, how they're thinking about the architecture, how it fits with the rest of the systems that they're trying to work with. And the more you can do that no matter how senior you are growing in your organization, the more people will respect you for your influence in their day-to-day work, right? There is only so much that you can do outside the realm of real hard code. And so I have seen senior engineers kind of dive into mentoring other engineers through code reviews, the more I've seen them being successful. So I think it's a combination of all of these things.

Shane Hastie: How do you code review Copilot code?

Copilot as a productivity boost [09:45]

Akhilesh Gupta: Great question, Shane. Well, I don't know if it's generated by Copilot, but maybe I see enough bugs and I'm like, "Hey, this is not written by a real engineer." But jokes aside, we are part of the Microsoft organization, and Microsoft is championing this in a big way. And to be honest, it is extremely helpful. It's not what people think it is. It's not that it will suddenly come in, and kind of write all the code for you, and the only thing you're doing is committing it. That's not what is actually happening. What is actually happening is you're still doing what you were doing. You are kind of breaking down a tough problem into manageable chunks. You're trying to figure out how exactly code will kind of fit in with existing modules, and existing systems in your overall architecture. You're still trying to figure out what to do, and why you're doing it.

What it is doing is that as you're writing code, there are cases where we used to go to Stack Overflow to kind of figure out how a particular API works, or you're trying to kind of go, and trying to determine a particular Regex, which is really hard to write, where previously we used to go to a Regex generator kind of figure out whether the Regex I'm writing is actually matching what I'm expecting it to match. And incorporating that kind of thing into your workflow just makes you so much more efficient because you're not switching out of your IDE, right? In the IDE, you don't have to go and switch between browser windows, and everything that you want from Stack Overflow, and from all the knowledge of the internet is just right there. It's kind of making it happen for you as you go, and then writing documentation is a breeze with it. I think that is the kind of stuff that I'm using it for, and I love it.

Shane Hastie: Good to hear some real implementation – there is such a lot of hype, unfortunately.

Akhilesh Gupta: Yes. I think if you cut through the hype, it really helps in your day-to-day workflow.

Shane Hastie: So that leads me into the developer experience. How do we build a frictionless developer experience? And what does that look like for our environments, for our organizations?

Working towards a frictionless developer experience [11:43]

Akhilesh Gupta: We commonly talk about this at LinkedIn in terms of how improving developer experience can have a huge impact in terms of business output, and how even small improvements in how fast developers are able to kind of get their job done results in massive changes, and massive shifts in your product velocity as a company. And I think there are multiple aspects that go into this, and I will chip through some of them. I think it starts right from the process of defining requirements for a project, right? Traditionally, people used to have the sense for the waterfall model where somebody defines product requirements, then design comes in, and defines design requirements, and then engineering comes in, and tries to figure out how to do it.

So the first area that we want to chip in on is figuring out how we can kind of meld these design product, and engineering iterations with each other instead of making it a true waterfall process. That's the first aspect of it. So a lot of effort in our company at least to kind of make sure that engineers get to be a part of the product design and requirement process. And we are able to prototype quickly, and learn from those prototypes so that we can feed back into the product and design process, and iterate based on true engineering prototypes that are out there so that people can see it, feel it, provide feedback on it. We can do user research on it, and then iterate from there instead of it being a very big cycle where engineering finally implements it, and then people realize that it's the wrong thing, and then you go back to product design. That's one.

The second is when engineers are actually writing code, and I already spoke about that, right? How to kind of make that workflow just so much more fun than what it used to be by kind of bringing in things like Copilot, and creating a developer experience that just makes it much easier to kind of pull in stuff that is available as libraries within your organization, pulling in existing solutions within your organization. So we are looking into IDE plugins that can kind of find the right library for the right use case that you are currently working on, and Copilot is also kind of helping with those kind of things.

And then there is the time it takes to build, right? You write code, and then you kind of figure out how to kind of make sure that the results are seen quickly enough so that developers get a very quick feedback loop that like, "Hey, I made this code change. The build happened. Here is what changed," right? And, "Is this right?" So improving build times is a huge part of improving our developer experience.

And then once you've kind of committed your code, tested it, built it, the next one is to kind of get it deployed very quickly. So we are constantly working on making sure that as engineers commit code, the time it takes from commit to publish, production publish is shortened as much as possible because that's what gives developer true happiness that like, "Hey, I committed something. It made it to production. I'm able to see my results," right? "And I'm going to move on to the next thing." So starting from requirements all the way to getting into production, and then being able to debug things in production quickly. I think improving that entire flow is what makes for a great developer experience.

Shane Hastie: We spoke about the staff-plus track. You mentioned in the conversation we had before we started that you've also stepped into the management track, and stepped out. If somebody is interested in stepping into that management track, what do they need to do?

Stepping in and out of management roles [15:06]

Akhilesh Gupta: This was at a time when I was a staff engineer at LinkedIn, and I was trying to figure out whether I want to continue down that IC track and go into senior staff, and principal staff, and all of those roles, or whether I want to go into management, and try and figure out if that is something that I would like to pursue further down in my career. And the more I kind of spoke to people about this choice, the more I realized that I have to kind of try it out, that there's no replacement for actually trying out that role, and understanding how it works for me. And I think the good thing is that these days it's actually encouraged for engineers to kind of try out the management role. And if it doesn't work out for you, you can always switch back to an IC role. And I've also had examples of some of my mentors, and leaders who have kind of switched between the management and IC role multiple times.

So to specifically address your question of what people need to do to get into a management role, I think the biggest thing is that people need to kind of start developing those soft skills that I spoke about, those leadership skills which are so important for you to be effective at a management role. So things like written communication, things like being able to make convincing arguments for why or why not for your team, being able to work with executives. All of those soft skills that I spoke about are actually pretty common between senior ICSs and management.

And then secondly, I think you just need to love working with people, right? That is another big part of being a good manager. A lot of people think that, "If I'm a great engineer, I can also just directly be a great manager." And that is just so not true because with being a manager comes the responsibility of actually making your team successful in a way that you need to understand people at a personal level, and what their needs are, what their hopes are, what their aspirations are, and what their quirks are, right? What are specific things that would make specific people successful? Because everybody's different. You can't assume that your style will work with everybody. So this was one of the biggest learnings for me as a manager, where I realized that the more I tried to understand how a particular person was thinking about their career, and their role, and their contributions to the team, and truly internalizing, and empathizing with them, the more I was being successful in getting them to become much better at their role.

And that's how you derive satisfaction in management, right? It's less about the code that you just committed, and the thing that you just put into production, but your satisfaction cycle actually becomes much longer where you are investing in people, you are thinking about how they are maturing as individuals, and as technical leaders, and then you see results in the order of quarters or years where you realize that the investments that you made in this senior engineer today are going to get him to have a huge impact on the team and the company in a year. And so it's a very different mode of deriving satisfaction from your work, which is very interesting to me.

Shane Hastie: And recognizing that different level of satisfaction, and stepping into it.

Engineering and management have different satisfaction formulas [18:19]

Akhilesh Gupta: Yes, that is one thing that kind of trips people because they are used to kind of deriving satisfaction from their day-to-day code commits, and from their day-to-day architectural designs, and things that they ship into production, and then suddenly they realize that none of that is happening, right? All of that is actually being done by the people on your team, right? And you are actually the enabler for those people to be efficient at doing the things that you used to do. So making that mental switch that like, "Hey, my satisfaction is going to come from the investment that I'm making in these people rather than my direct code contributions or my direct production contributions," is very important to do to be successful as a manager.

Shane Hastie: Akhilesh, some really good points and interesting conversation here. If people want to continue the conversation, where do they find you?

Akhilesh Gupta: First of all, I'm on LinkedIn. You can find me, you can message me there, and absolutely happy to answer questions there. At the same time, I am also on Twitter. My handle is @agupta03. I regularly engage with people there too. And finally, I feel like forums like InfoQ are amazing. I will endeavor to kind of spend more of my time presenting at QCon conferences. I'll probably be applying again this year. So I'll see you at one of them, and hope to connect with people there.

Shane Hastie: Akhilesh, thank you so much for taking the time to talk to us today.

Akhilesh Gupta: Absolutely, Shane. It was a pleasure.


About the Author

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article