Transcript
Nardon: My name is Fabiane Nardon. I'm here to share with you my path to the staff-plus engineer role. One of these days, I was reading The New York Times, and I found this article. The article said that tech companies are facing the biggest hiring crisis in history. You don't need to read The New York Times to know that if you try to hire someone, especially on the senior level in the last few months, you'll probably know how hard it is to find someone right now. I was looking into it, and I found these statistics. It said that 67% of the digital leaders think that the skills shortage is what is preventing their company from keeping up with the pace of change. That's a lot. We are living the biggest hiring crisis in the history of the tech industry, isn't it strange that most companies are still not encouraging people to stay on the technical path? For many companies, the only way to get promoted after the senior level is to become a manager. That was what happened to me.
I always wanted to be a software developer. I taught myself how to program at the age of 13. I worked on several very complex projects. In fact, one of the systems I built was considered the largest Java EE application in the world. When I became a technical manager, in the beginning, it was fun, because the team was small. I was doing technical work, coding, creating architectures, processes, and so on, and managing at the same time. As the team got bigger, and the company grew, I was more managing than coding. At some point, I was just managing. I was miserable. I have a profound respect for managers, especially for good managers. It's not an easy work to do. It's just not for me. I believe that for many of you, you would prefer to stay in the technical path instead of going through a manager path.
Lessons Learned as a Manager
When I became a manager, the company was prepared to help me to succeed. They offered me several courses. They had trainees. They had workshops. They had coaches. I had all the support I needed to become a good manager. Strange enough, when you become a staff-plus engineer, usually the companies are not prepared to give you the support you need. They don't know what trainings you need, or what things you should get better at. Since I became a manager, and the company was prepared to support me, I learned a lot. Most of what I learned was how to be a better leader. Most of the trainings were actually trainings on leadership. There were a few lessons I learned as a manager that made me a better technical leader. I want to share some of them with you, at least the ones I think made the difference in my life later.
The first one is be patient with people that need to explain their problem. As a developer, I just wanted people to tell me what I had to do, so I could go back to the code as fast as possible. As a leader, I realized that part of my job was listening to people. Not everyone is direct. Some people need to use lots of words to explain their problem. If you're patient enough to really listen to them, to pay attention to what they're saying, you're going to learn a lot about your team, about the solution you have to do. You're going to notice that engagement is going to be a lot better.
The second thing I learned was that it's important to make people feel the solution was their idea too. If you manage to do that, you're going to have a team that's more engaged. Your life is going to be a lot easier. How do you do that? You do that simply by acknowledging the small contributions of the team. It's as simple as saying, we are doing this solution because of the problem that this person pointed out the other day. As simple as that. Part of my job as a manager was to explain technical stuff to non-technical people. By doing that, I learned how to explain very complex things in an easy way. This helped me to explain more effectively complex architecture to my technical peers. This is something you can practice, just try to explain technical stuff to non-technical people and you'll see how you're going to get better at explaining things. When you're going to explain complex solutions to your technical peers, you'll notice how your communication is going to improve a lot.
How to Know If a Managerial Career Is Not For You
How do you know if a manager career is not for you? There are a few signs. The first one is if you are a manager but you keep finding excuses to code. For example, your team has a deadline, everybody is late, so you decide to code just to help them. You just find an excuse. The second sign is you try to automate everything. You have, for example, to do a spreadsheet, but you create all kinds of macros just for the joy of coding something. The third sign is that you secretly hate business meetings. If you check one of these signs, there's a good chance that the manager career is not for you. I checked all of them.
Back to the Technical Path
I was a manager. I was not happy. Eventually, I left the company I was in and decided to take a sabbatical year. My plan was to work for free on projects that were interesting to me during the sabbatical year, so I could experiment new things and decide what I want to do with the rest of my life. That was a good plan, because when you're working for free, you can basically choose any project you want. By the time, some friends of mine were starting a company, and they needed someone to do AI and data engineering. This was something that was interesting to me. I decided to join them. This was 10 years ago, and I'm still working with them. I managed to stay in the technical path since then.
Skills Needed To Be a Successful Staff-Plus Engineer
Over these years, I understood what skills you need to have to be a successful staff-plus engineer. It's all about the interactions you're going to have with your team and with the other departments in the company, especially with the non-technical departments. When you are promoted to staff-plus engineer, usually you are promoted because you have great technical skills. This is just the basics. You have to keep these skills sharp for the rest of your life. It's learning new things till the end of your career. That's not enough, to be a successful staff-plus engineer, you need also to understand the business needs. When you're in this position, it's not more about what you want to do. It's about what the business needs. For example, you are not going to do a huge refactoring in a code that's working perfectly well, just because you found out a new design pattern. If the business doesn't need that, if this is not going to bring any value to the business, you're not going to do.
Another thing that is going to be your responsibility is to make the team better. This means mentoring your technical team, making process that are going to make team interactions more productive. Reviewing code, things like that. Finally, you need to be able to communicate well with your other departments in the company. As a staff-plus engineer, you're going to be called to give the technical view on things. If you don't know how to communicate with people that have different backgrounds, you're probably not going to be a successful staff-plus engineer.
Tip 1 - Coding Solo Doesn't Generate As Much Impact as Making Team Code Excellent
Over the years, I discovered several tips that helped me to make this work. I want to share some of them with you. The first one is that coding solo does not generate as much impact as making the team code excellent. When someone has a problem, and you know how to fix it, you may be tempted to just get the code and fix yourself. If instead of doing that, you call your team member, and maybe pair programming with them, you teach them how to solve the problem, you're going to make the team better. This is going to bring a lot more value to the company than if you just had coded things yourself.
Tip 2 - Follow the Process You Created for the Team
The second one is that you have to follow the process you created for the team. For example, if you decided that everybody has to document the code, and then when you do the code, you don't document it because you are the staff-plus engineer, so you don't have to document your own code. If you do that, the team is not going to respect your process. It's important to keep consistent, to follow the process that you created.
Tip 3 - Block Your Calendar for Focus Time
When you become a staff-plus engineer, you're going to be called a lot to participate in meetings. You're going to do code review sessions. You're going to do meetings with other departments to provide the technical view. You're going to be called to do job interviews and things like that. If you just let people book your calendar, you may end up with something like the left calendar here. You have free time to work on code, the architecture and the complex stuff you have to do, but they're going to be small slots of half an hour or one hour between meetings, and it's impossible to concentrate and do complex work in slots of half an hour or an hour. One thing that's very useful is to block a good part of your calendar for doing new work you have to do, the code or architecture or process, anything you have to create, and let people just book your calendar in different time you leave for this. This is very important. If you don't do that, you're probably not going to get any work done.
Tip 4 - Be Sincere and Direct, but be Gentle
As a staff-plus engineer, you have to be sincere and direct. You also have to be gentle. I met some very smart developers that could be excellent staff-plus engineers, but they are never promoted just because nobody wanted to interact with them. They were rude. They didn't like to talk to people. They didn't have patience. They never got promoted. You need to have great technical skills. You also have to have good soft skills, if you want to be successful as a staff-plus engineer. Try to get the hard problems to code yourself, but also be a team player. If what your team needs right now is someone to solve a very easy bug, you solve the very easy bug. Show that you can do what the team needs, and that you're there for them.
Tip 5 - Deal with Leader Loneliness
You also have to deal with the leader loneliness. When you are a senior developer, you probably have several other senior developers in your team and you can talk to them, you can exchange ideas, frustrations, problems, complain about the boss, which is part of the game. When you become a staff-plus engineer, or technical leader, for example, you're probably going to be the only one in the team. It's very common to feel alone, and not having anyone to exchange ideas or your problems, or discuss your frustrations and so on. The best thing you can do is to find a pair, maybe another staff-plus engineer in the same company, and exchange with them. Talk to them about the frustrations, problems, and achievements you have. If you can't find a person in the same organization you are, maybe you can find a friend in a different company, someone you trust, but have someone to whom you can talk and exchange your problems and frustrations. This is going to help you a lot.
Tip 6 - Be Predictable and Reduce the Team Stress
You should also be predictable and reduce the stress of the team. Software development is already too stressful. You have deadlines. You have complex things to solve. It's not an easy task. You don't need to add stress to the team. In fact, it's your responsibility to try to reduce the team stress as much as possible. There is more things you can do. For example, if you need to talk to someone, and you just send a message saying, "I need to talk to you, can we talk Monday 9 a.m.?" If you just say that, the person is going to spend the whole weekend thinking, what did I do wrong? Am I going to be fired? You just destroyed this person's weekend. On the opposite, if you just say, "I need to talk to you about that bug you found, I had an idea. Can we talk on Monday 9 a.m.?" Then you just relieved all the stress because the person knows exactly what you're going to talk about. There is small things you can do to reduce the team stress, and it's important to pay attention to these small interactions, because when you are a technical leader, everything you say is going to have an impact on the team.
Tip 7 - Experience and Time Will Teach You How to Deal With Difficult Situations
Finally, experience and time will teach you how to deal with difficult situations. Just relax and let the time pass. Over time you're going to be more mature, you're going to learn how to deal with different situations. You'll get better. Situations that may seem impossible right now are going to get easier. Just take your time.
Creating a Staff-Plus Engineer Friendly Company
I told you I joined that startup in my sabbatical year. In the beginning, it was a lot of fun because it was just me and one of my business partners, doing all the technical stuff. We would code and create the architecture and the infrastructure and everything. We always thought that one day that wouldn't be possible anymore because the company would grow, and we would have to manage everyone. It wouldn't be possible to do technical stuff anymore. Then we thought, what if you create a company where it is going to be possible for us to keep doing technical stuff because if you're good at it, why not? That's what we did. We built a team that was very skilled, a team that required very little management. We created process and ways of working that would allow us to do very little management and still be able to code and work on technical stuff. That's how I became a CTO that still codes.
If you were to create a company that is staff-plus engineer friendly, what do you have to do? First, you have to incentivize people to stay in the technical path. You do that by providing the right compensation and status. It's not just about money, but it's also by showing that you value people that achieve a particular staff-plus status. This is very important. The second thing you have to do is to provide leadership and communication training for your staff-plus engineers. As I had when I became a manager, all those leadership workshops, and communication, and so on, you should provide the same kind of support for the staff-plus engineers as well.
The company also has to understand what really matters to technical professions, and value that. For example, very good developers value code quality. If this is important, the company should value that as well. Going to conferences, be creative in the solutions. Everything that's important to technical professions should be valued by the company, if you want to attract staff-plus engineers. If you manage to do all that, just let people know your company values technical careers, so you're going to attract more people. You will also be setting a standard for the rest of the industry. We need to have more companies valuing the technical careers and providing the right support. If your company is doing that, let people know, tell stories about it, blog posts, whatever.
When I was preparing this presentation and thinking about staff-plus engineer path, it reminded me a lot of a novel by Isaac Asimov called, "Profession." This novel was published in 1957. In this novel, there's this future world where when you turn 18, you go to a place and choose a profession. They have tapes with all the knowledge you need for each profession. You choose a profession, they get the tape and download all the knowledge you will need directly to your brain. You learn instantly everything you need to know to work in that profession. There is this guy called George who wants to be a computer programmer. When George turns 18, he goes to this place to be taped to learn everything he needs to know to be a computer programmer. When they try to download the knowledge to his brain, they find out that he is unfit. His brain is unfit to receive the knowledge from the tapes. George is sent to this institute where they send the unfit. In this institute, there are lots of books, and George learns that it's possible to learn things the old way, by reading books and doing experiments and studying.
In the end, George finds out that the ones that are sent to the institute are not the unfit, but are the ones that have a mind that is persistent enough to keep learning and learning for a long time. Because the ones that receive the tape, they can't produce new knowledge because the only thing they know is what is in the tape. The ones that are persistent enough are the ones that are going to produce the new knowledge that is needed to advance the humankind. In a way, this reminded me a lot of the staff-plus engineers because we are not people that are unfit to be managers. We are just the ones that are persistent enough to keep learning and to evolve the knowledge in our industry. We are living the biggest skills shortage in history. We have huge technical challenges ahead, see AI and data engineer and things like that. Lots of problems in these fields. We can't afford to lose our most experienced engineers. I believe the future of our industry depends on how we find and foster our technical leadership.
Questions and Answers
Ignatowicz: Sometimes as a staff engineer, you're busy doing a lot of glue work. That is work that you understand, because sometimes you are the most senior person in the team. You do some glue work here and there to make the overall team successful. Sometimes most of the companies, they don't value too much this glue work, they value more feature deliveries and measure impact over features and your impact in the business. How do you suggest to us to couple with the importance of the glue work between the trenches and also to drive your core impact if your company doesn't value too much the glue work?
Nardon: This happens a lot. Usually, there are lots of work that I do in my day-to-day. Usually, we have a daily meeting, and at the end of the day, it seems like I have nothing to report because the only thing I did during the day was doing glue work, like helping someone here and help someone there, and answer emails and things like that. Actually, one of my colleagues in the past, he's always oriented to the daily meetings, and he would start saying, it seems like I did nothing, but I did this and this and that. This became like something that we always say, like when you say it seems like I did nothing, it means that you only did glue work. What actually we did in our company to value that was just being open about it, just saying, it seems like I did nothing but I did this glue work that was important because of this and that. It's more about creating awareness in the company, how important is the glue work. It can be frustrating for staff-plus engineers, because before when you were a senior developer, you're always developing interesting software and you had a new library to show or things like that. Then when you become a staff-plus engineer, sometimes you spend a whole week without having anything very interesting to show because we just did the glue work. It's part of the awareness of the staff-plus role for companies also to value that, and you have to be a little bit clever in communicating what you do so people can understand how important is this work as well.
Ignatowicz: Who do staff engineers report to, in general?
Nardon: Staff-plus engineers' roles are still a new thing in the industry. There's not a standard in the industry on how this works, or how much you're supposed to receive, or what work exactly you are going to do. There are some archetypes. As a staff-plus engineer, you can be a technical leader, you can be what they call right hand with someone that's close maybe to the president or the CTO. It depends on how the company works. The staff-plus engineer reports to different roles depending on the company. For example, if you are a technical leader, maybe the company has a manager and you report to this department manager, but sometimes you report directly to the CTO. Sometimes you can report to the president. Sometimes you can have the VP status, so you report just to the president of the company. Sometimes there are companies that use this staff-plus role just as a way to give a raise to the person, but they are actually being a senior developer, so you're going to report to a coordinator or to a manager. The industry still has to learn to deal with these roles. We don't have standards right now.
Ignatowicz: How much coding focus time do you recommend for a staff-plus engineer?
Nardon: This depends on the kind of staff-plus engineer you're going to be. You're going to see several staff-plus engineers that basically don't code anymore. I don't think this is good, because if you don't code for a long time, sometimes you lose a little bit of connection with the code. You could at least try to get some projects to do yourself to keep your skills sharp. There are staff-plus engineers that just don't code. There are other types of staff-plus engineer that code half of the time. It depends on the company you are, the role you're doing. Remember that some staff-plus engineers are not coders. They can be, for example, infrastructure experts, and then they don't code. Maybe they create some scripts, but they don't code at all. For me, personally, I try to code at least 30% of my time. Some weeks this is not possible. Some weeks I can code more, but it depends on how things are evolving.
Ignatowicz: Do you think companies will be willing to pay manager-grade compensations to people who want to stay in technical positions?
Nardon: Yes. There are some companies where staff-plus engineers actually get more money than managers. This is because it's very hard to find staff-plus engineers or engineers that are very senior right now. It has to do with the moment in our market. There are many companies that have what they call the Y path where they are supposed to have technical roles and management roles that are equivalent in terms of status and compensation. The most advanced companies I know pay the same compensation for managers and staff-plus engineers.
Ignatowicz: I often felt I cannot code the important part of the code as a manager role overcome the dev role in crisis moments. Finally, I become a bottleneck for the team and you end up with a challenge doing overtime, or passing the branch to a developer to finish the work for you. Have you ever lived that yourself?
Nardon: Of course, every day. That's a little bit frustrating, actually, because there are sometimes, some things that you really want to do, because it's very interesting. If that part that you're going to code is part of something very important that has a deadline, and you know that you're going to be called to solve your other problems, you're probably not going to be able to finish it, and then you have to work overtime. This really happens a lot. What I try to do is when I have to do something that is very important for many reasons, maybe because I'm the most prepared person to do it, or there's not enough people in the team to do it. What I do is just, I block my calendar and I don't accept other meetings or I delegate some of my glue work to other people. I say, I'm not able to do this right now because I have to finish this part that's very important. Then I concentrate and do. There is a risk doing that. If you're not able to block the other work you have to do, you're probably going to become a bottleneck or you're going to have to work overtime just to finish what you promised. Just be aware what you promise to do, and be sure that you have time to do it.
Ignatowicz: How do you balance between giving an important task to someone that needs to grow and learn by themselves? Because it's really good when you have a problem that is tougher than your current experience. Also, how do you fit that you're not mentoring too much between the lines? How do you balance between letting people learn by themselves, and you assist them in the guidance for some tasks to make actually the group grow?
Nardon: Usually, what I say to people is that I give the task and I say, "Just remember that I'm here for you. If you need something, you just have to say. We are a team. We are together. If you are not able to finish, there are other people that can help you. Just do your best. We are here for you." I manage to create a behavior in my team that everybody thinks that they have to help the others. What I usually do is to let the person try, and I ask from time to time, how are you doing? Do you need to talk? If they are mature enough to ask for help, then I go and help. Sometimes people don't have this level of maturity, and they just try by themselves until they are pretty lost or something. Then what you do is you give feedback, "You know that when you are in this situation, you can ask for help sooner, because we are a team. We are together." It's a balance. You have to leave the person to try, but you also have to check with them and create this confidence that they can ask for help. It's not easy. Human interactions, it's always complicated. The most important thing is to create a safe space where people can ask for help when they need. That's usually what I do.
Ignatowicz: As a staff engineer and a CTO in your company, you have a lot of possibilities. You said already that you have a big team in a really important project in the company. How do you find time to keep up with the new technologies and development?
Nardon: I work a lot. I think for the last years, the thing that helped the most to keep up with new technologies is actually participate in conferences. Because I can go to a conference and just be focused in maybe a week or five days just learning new technologies and having ideas, and getting a little bit out of the day-to-day.
See more presentations with transcripts
