Alfonso Graziano The staff engineer vs manager path A window over the tech career paths

In this talk, Alonso, a tech leader at a consultancy company, discusses career paths within the JavaScript ecosystem, particularly focusing on roles for engineers. He emphasizes that career progression is often not linear and that engineers can evolve and pivot in their careers by embracing different roles such as management, individual contributor, or product management. Drawing knowledge from influential books like 'The Manager's Path' and 'The Staff Engineer's Path', he highlights the importance of soft skills alongside technical skills in these trajectories. Additionally, he explores the concept of mentorship, the significance of communication, and how organizational differences can affect role definitions and responsibilities. Alonso also discusses tools and strategies for career development, stressing that making informed decisions about one’s path can lead to increased impact and satisfaction.

All right. Hi everyone. Thanks a lot for being here today. Um I'm Alonso. I'm a tech leader form. Again, thanks a lot for being here. Uh it it's great for me uh to be to you know have the opportunity to speak here today. Uh so in case uh you don't know earform we are we are a consultancy company we mostly work in the javascript ecosystem whoever work

with nojs or javascript here. Oh wow a lot of folks. Okay nice uh in case you're interested in air for maybe you can check out our website. Uh but today we are going to talk about a lot of things about uh mostly career and career paths. We're going to use uh well some of the resources I used to build this uh this talk are three I think

amazing books which are the managers path the staff engineers path and the software engineers guide book any have you read any of those oh wow a lot of hands that's great that's great folks great start uh in case you haven't read some of those I highly recommend you because they are a great resource a great starting point of course on this topic there are a lot of

um you a lot of books, a lot of courses as well, but I would kindly recommend you to look into it. Um, when I started my career a few years ago, when I was back in university, actually, I thought that, you know, the career path was like I'm going to start I'm going to be an intern, maybe I'm going to start as a junior engineer, middle uh

senior engineer, and then it's going to be a linear path. But the more people I know, the more I understand that it is actually quite different and you can change job, change role, uh change you know the company, the market is going to change folks. I know that's how our market changed a lot in this couple of years and it's going to evolve and it's going to

change. So we have to evolve as well. Uh we might for a lot of time um change entirely industry, we might change companies, we might change a lot of things. So we have to be prepared. Um also there are a lot of things that you can do when you are an engineer. Of course you have to reach a certain level of seniority but at that point you

can choose and you can go on the um you know management path on the individual contributor path you can become a product manager you can do a lot of things you can do technical writing you you can do content. Uh how many managers here? Oh okay nice. Okay so we got a lot of managers. I expect a lot of individual contributors as well. Uh but actually you

can choose a lot of different things and you can grow a lot of your art skills and a lot of your soft skills as well. This is just an example but again you can definitely craft your path. Now let's make things a little bit easier for us just uh just to have a little bit of context. When you start you are a junior engineer then you can

grow to you know middle level engineer then senior engineer and then at some point if you want you will have to decide whether to go on the management track or the or stay as an individual contributor and just create a lot of design documents and do a bunch of code and do a lot of cool projects. Uh but remaining a senior engineer is perfectly fine and this

is something which I want to stress a lot. uh in some companies it is also called uh terminal level or terminational level. So basically usually uh your company is going to ask you to grow up to a certain level and after that level you can just decide to remain a great senior engineer because folks just saying a senior engineer in our industry is so so so complex.

I'm not sure if you have ever worked with well you mentioned you worked with JavaScript like a lot of people worked with JavaScript. If you're a JavaScript developer, you have to deal with this with a huge environment, a huge ecosystem which is constantly evolving. So just to keep yourself updated and just to act as a senior engineer constantly is super super difficult. That's why you can just

stay a senior engineer forever. But uh that being said, if you really want to progress in your career, if you think that you want to have more impact, if you want to have more scope, we al we have to keep in mind something which is in my opinion really really important which is that as you may guess with great report with great power comes also great responsibility.

Um either if we go on the management path or on the individual contributor path. now okay but I'm just a middle a middle developer I'm just a junior developer I've been like I joined this kind of conferences when I was a junior developer and I thought okay there are a lot of advanced topics but what can I learn now today I want to give you a resource

which I really enjoyed and I read from time to time uh which is a beautiful article and folks I highly recommend you to read this which is the definition of senior from Luchano Amino an Italian uh software engineer and this article is great because within this article you're going to find a lot of things about what are the expectation from senior engineer how to become a proper

senior engineer uh what are the skills both technical and nontechnical that you that you should have in fact even if you are a senior engineer I would highly recommend you to read this one uh because you might find a few things that might be interesting but let's continue now I'm a senior engineer and somehow I decided that I want to progress with my career. I decided that

okay I want to have more uh more scope. I want to have more impact on my organization on my team who is working here across multiple teams or across multiple products. Okay, a few hands on. Okay, so usually when you're a senior engineer, your scope is just within your team. But you might decide, okay, I want to have uh an impact over the entire organization or over

multiple teams. Now, if I still want to progress, I have to understand what's the right path for me. Maybe I like helping people. I like doing mentoring to other engineers. Uh, but I don't know yet if I might enjoy doing a a manager job like full-time. On the other side, I'm really good at coding or I'm good at I'm good at software engineering, but I'm not sure

whether I might be a good fit for a staff engineer role or staff plus engineer role. So, how do I decide what's the right path for me? I think that this question is very important but we usually tend to um address this question as an optimization question. We are engineers, right? So, we try to optimize things. In this case, I think that this is not an engineering

problem. This is more a design one. And uh again, I'm sorry folks, within this within this talk, you're going to find a lot of resources which I highly recommend because they changed my life and might change your as well. Um, if you want to learn how to deal with more design problems, there is a beautiful book crafted by Stanford professors which is designing your life and it

is a very practical and pragmatic book which tells you what are the steps to define your life to design your life to craft the life that you want. Uh, it's again very practical and is based on a lot of studies about psychology and sociology. So it's very very helpful and useful. So once we understood that this is a a design problem not an engineering one now we

have to understand what are the tools that we might want to use uh a few of them just to name a few but there are a lot of them prototyping doing shadowing uh so shadowing sanctions with your manager for example finding a mentor a lot of mentor who yes uh do you have a formal mentor like like someone that's helped you in your career okay there are

a lot of people here that had mentors in their life. Uh then you can ask to your colleagues like your the people that are already working as a staff engineer or that are maybe tech leads within your organization. Study content, understand the scenarios within your uh company, within the industry, within the broader context. So basically just to summarize what we have to do to understand what uh

you know what path we should take is basically doing what we do usually which is gather data gather as much data as we can and if we can also practical experience in order to drive our decisions which might seem uh easy but it takes a lot of time and effort. Now I want to highlight a few key differences and similarities within RO uh within these two roles

and I think that there is one image which is great uh which I found in one of the books that I suggested initially uh which is this one. So this is basically a band diagram uh which highlights um you know what a soften engineer and an engineering manager are doing in terms of a soft engineer is mostly building software and working on strategy and on the alignment

while on the other side the engineering manager is also working a lot on the strategy side but is also working a lot on the people management. So I think that the at the at the intersection of this van diagram you can find some of these subal differences between the robots because I think that some of the differences are clear to all of us right but there are

a few things that I think are quite uh are quite interesting on this topic. Now of course even if those roles are almost streamlined uh there are a there are some jokes uh about the fact that every organization is quite different. So even if the roles like the name of the roles are the same the actual job might be entirely different. It's kind of a joke, but

it's it's true because every time you change company, you're going to find different politics. You're going to find different communication patterns. You're going to find different collaboration between teams. And so, we have to account for that. Um, of course, let's get started to talk about some of the key thing of the things that they have in common like these two roles. Well, first of all, even if

you talk with an engineering manager, engineering is the first word in the role. So you have to keep in mind that this person is as usually a strongly technical engineer. So has been a senior engineer for years and then decided to go on the management path. The second one is that communication skills are essentials in both these roles. You know, I had some colleagues in my previous

jobs which told me, you know what, I want to become a staff engineer because I hate talking with people. Uh, and I see a few of you laughing. uh which is true because when you are an engineer you think that maybe communication shouldn't be your key skill but the more you grow you more you understand that wow communication is quite important even for an individual contributor a

design doc even code like our code is communicating something to other people. So documentation, meeting, alignments, all this stuff is all communication. So your communication skills are going to be essential not just for managers but for individual Of course, as I mentioned earlier, um you can have a broader impact over the organization. It depends on the scale of the organization of course, but at least you're going

to have an impact departments. uh which might be quite interesting but at least initially at least for me it's been quite scary and then of course leadership I know that like leadership team leadership is one of the terms which sounds um you know a little bit weird because it's not something very concrete but I saw some of the best staff engineers and engineering manager acting with leadership

and when you when you see some people having that kind of leadership you really understand that leadership is quite important both for managers but also for individual contributors in different ways in totally different ways with some intersections of course but this one is of the this one is one of the key skills of both roles and of course in both cases I'm not sure folks if there

is here like any tech lead or any mixed role which we're going to discuss later uh but you usually have a less defined set of skills sometimes where you are let's say just an engineer, you can track your work a little bit better because you have a a clear set of tasks and you have a a clear scope of of your work. But when you are maybe

a staff engineer or an engineering manager, uh you can have a lot of you can do a lot of things during the day which are quite different. Now what about the tech lead role which I just mentioned? Well, there's a lot of things or I think everything in our in our industry as you may guess. It really depends. It depends on the company. It depends on the

industry. Uh in some companies, the role of the tech lead is just you know leading a team but it's not a a real role within the organization is just uh a person that is in charge of a team. While in other organizations uh like for example in earform a tech lead is a specific role. In this case uh just to give you the example of my company

in Near form the tech lead is doing a lot of different things and again we have a lot of different tasks. First of all we have to engage with the business. So we are we act as a bridge between the tech team, the business, the product and a lot of other teams. Then we have to engage with the team as well because we are also managers of

our team. Uh so you are going to have one-on- ones, you are going to have performance reviews. So you are the manager of your of your team of your development team. Then when you're a tech lead, you also manage delivery and risk, prioritization, a lot of things. And last but not least, which is again a quite important topic, uh architecture and infrastructure of the the software, the

tool that you are that you are creating. Okay. But this is one really important question to me. But we have like we are going to work for 40 years hopefully hopefully less maybe uh but we are going to work for a lot of years decades usually. Do I really need to choose what's the path that they're going to go with for like 40 years or 30 years?

Well a lot of a lot of people think that maybe that's not needed. Maybe you don't have to choose. And there is again this beautiful article from a few years ago actually which is the engineer manager pendulum. Not sure whether someone already heard of it but it's a very interesting article because there are some key considerations and one consideration that changed the way I can see this

this choice is that maybe you don't have to decide maybe you can move between being an individual contributor to a manager like a pendulum acting like a pendulum. So maybe in some moments of your career you want to help people grow and manage them and doing a lot of mentoring while in other moments in your career you just want to build cool stuff and you know you

want to go deep in in some topics. So the idea here is that you don't have to decide and as a side effect of this while you're working as an individual contributor you can strength your technical skills while while you're working as a as an engineering manager or on the management track you can increase a lot your skills on the on the leadership and on the communication.

So these two things are going to create let's say are going to improve you a lot over time. Now there is another framework another mental model another concept that I want to give you which is okay deciding what what's going to be our path is a one-way decision or a two or a a a two doors decision decision. So the key difference is that when you have

um a one oneway decision, it's very hard to uh you know change that decision or if you decide to change it, the cost to change it, it's going to be huge. And so like for example, when you have to implement a new architecture within our within our codes or within our product or when you choose a framework later on, it's going to be usually difficult to change

it. So this is for me a one-way door while a two-way a two-way doors is something that at some point you can just decide okay now I want to change and the cost of changing is not prohibitive. So at some point you can just say okay folks in let's say six months I'm going to change my job again. So you can do it and in my opinion

this this one this choice is just a two-way door decision. Now um I think this concept is important like this topic around promotions and how the promotion process works because it is different of course from company to company but there are some key aspects that are the same and if you know how it usually works you can avoid some uh issues with your manager you can avoid

a lot of different conver difficult conversations. So the earlier you know how usually works a promotion pro process the better. Now initially of course we have to talk about the antiper principle. So in our industry uh it's quite interesting because usually in order to be promoted to a certain level or to a certain role first of all you have to demonstrate to the company that you are

able to act at that level and then you are able to perform at that level. So assuming that for for example you want to become a manager usually what happens is that before being promoted to manager or before changing your role you have to demonstrate for I don't know six months a year sometimes even more that you can do it that you can perform as expected within

that role without being pegged like that of course but that's that's a different topic uh but this is the now usually how that works is that uh like every six months, one year, you're going to get you're going to have a um self-re. So after this self-re uh you are going to select three up to five up to seven peers and those peers are going to give

you a review a feedback saying hey you are doing well in this aspects you can improve a lot on these other aspects uh and of course your your manager as well is going to give you a lot of feedback. Uh how many people here are doing like uh reviews, self- reviews, peer reviews once a once a year at least? Okay, nice. That's that's great. Uh you know,

I come from Italy, so in Italy usually we don't have this this type of process. It's a little bit uh you know less formal, but it's great that you're doing a lot of reviews and and getting feedbacks from your managers. So after you have this conversations, what happens is that usually you create a promotion package. Now the way a promotion package works is that you you usually

say to your manager, hey I I would like to be promoted to this role. I would like to change role and now you have to build a document or a set of documents that explain okay why I'm the right person for this role and why I deserve to be promoted to this to this level. Uh which is usually a set of documents which can be like 20

30 pages. It really depends on the organization, but you at least have some documents. Last but not least, you're going to have the uh evaluation of your promotion. So usually on the C level or VP level or director's level um you're going to have a committee which is going to review your performances and it's going to review your promotion package and if they said they if they

decide that you are ready to be pro promoted uh usually you get you get your promotion otherwise in theory you should at least get a feedback saying okay you're not ready yet because you have to improve I don't know this three key items items and then you can retry like in six months or a year. There is one uh tool which I think might be really helpful

in case you would like to be promoted in the next in the next I don't know one year or two years. And this tool is super simple but super effective. is a tool that you can use in like I don't know you you can invest like five minutes of your time once per week or once per day which is basically called a brag document or work log

which basically uh summarize what you are doing and the impact that you are having over the organization over the product and the projects in general that you're working on just to give you an example let's assume that you have been able to I don't know decrease the latency of a quite important API or that you managed to ship a product in time, in budget and in scope

which is great. Um you have you can write what is the project, what are the key results that you achieved and some metrics as well which are you know usually quite helpful. Now um if you remember initially I suggested a couple of resources but I want to convince you that those resources are really really helpful. Um, and so I just want to u give you a summary

of what I learned like super quickly and what you can learn as well if you decide to read them and to investigate a little bit more. Now from the manager's part which again I think it's the best book on this topic uh you can learn first of all what you expect from your manager because as a manager you do a lot of things during your during your

working day and maybe as a person working with with a manager I'm not sure what I should expect from this person. I'm not sure how much feedback I should expect uh what I should expect within a oneonone. So uh then how to conduct an effective one-on-one which we usually have to manage our one-on- ones. Uh how to be managed because if we can make our manager's life

a little bit easier that's great for everyone. Um how mentoring works and how the management ladder works. So from engineering manager so managing a team to managing multiple teams to the entire organization or to multiple departments. The soft engineers path understand this is for individual contributors but I think that everyone can benefit from this kind of this type of book even if you are an individual contributor

or a manager you know understanding some some topics like the bigger picture like how is my organization uh structured how is my team structure how what are the relationships between my team and the other teams uh then define vision and strategy, manage your resources and lead lead projects and influence. I have just one last thing for you which I think is the most important of the entire

the entire talk. One more thing uh every career is different. Again, we are going to work for a lot of years and all our careers are going to be hugely Not like everyone is not late. We are never late. We are not wrong and we are all unique. Every one of us is unique. Sometimes we just should remember to stop for a moment, relax, see all the

things that we achieved and keep in mind to enjoy the journey. Thanks everyone.