When I was younger, I had misplaced conceptions about what it meant to be a senior engineer. Even today, I see a lacking in consistency about what it means to be a senior engineer. I am a tech lead senior engineer, and being one is fundamentally different then being a good or great engineer. I want to take a moment to illustrate what leadership in technology means for me now.

I will break down leadership in technology into four areas. First is achieving the technical bar. Second is exhibiting and applying agency. Third is influence and inspiration. Fourth is mentoring and growth.

The Technical Bar

The technical bar is fairly simple to define. Reaching this bar means that you can do the work and ship the products you said you were going to ship. A critical aspect of this is knowing when you are unable to ship and communicate that up. This field is so wide and diverse that it is impossible to a master the universe, but you can master two things.

You can master the basics and fundamentals. These are writing clear and concise code, documenting, communicating what you are doing, working on a team, writing tests, and being responsible to your customers. I think of this mastery as reaching practitioner status, and you can do the work in front of you.

You can master an area of expertise. Mastery here means a couple of things. First, it means being in the know about a bunch of specialized topics and having some deep experience in shipping these systems or products. Second, it means that you can evaluate ideas on a variety of dimensions and engage in meaningful discussion of pros and cons. You need not come up with an industry defining ideas, but you should be able to evaluate the ideas.

Agency

Agency is the ability for you to execute on what you believe. The field is wide open, and there are many things to be built. I had a defining moment in my career at Amazon where instead of waiting for permission to build, I went and built. There are multiple ways of achieving agency, and I want to illustrate two methods.

The first way is communicating value proposition. This is where you use a touch of persuasion and sell what you need or want. Software is all about people. If you have a good idea, then you need to communicate it. You should be able to front-load why your idea is good. Communicate the what and why, and educate those around you. This is minimally achievable by writing brief design document with an FAQ and a few pictures; the key to execution is then meeting with people and hashing it out. The goal here is to inspire everyone that you can deliver value.

The second way is to bet your career. You engage on a project, and you are prepared to get fired if it doesn't work out. This is hard-core mode and mirrors an entrepreneurial mindset. This is not the card to play at the beginning of your career, but this is a card to be played when you achieve critical mass of value to your team. The stronger you build a track record, the more freedom you have to fail. The weaker your track record, the more risk you take on by taking the bet.

A good way to think about this is that you have a karma with the people around you, and you are constantly building it up with wins and success. For instance, if you have deep experience in operating a critical system, then wielding that allows you to experiment in new areas because you have karma to spend. That is, you have immediate value to the people around you that is demonstrated by history.

I caution that spending karma with force is not ideal, but it may be needed. It is definitely needed when your leaders are closed minded, then getting fired is probably an OK outcome and you should experiment regardless.

Since communication dwarfs technical complexity, your inability to communicate the value proposition can hold you back. When you are holding yourself back, you have to decide if the value is worth it for you to make the bet and spend your karma.

If you spend a bunch of karma and execute, then the most important thing is to listen to feedback. If your bet was a success and you have happy peers and customers, then two things happen. First, you get more karma to spend later, and this will help you more down the road. Second, you will have an opportunity to connect your mental thinking with the happiness of the people around you. As stated before, communication dwarfs technical complexity, and understanding how to convert your ideas into value proposition is hard. The key here is to pay attention to what makes people happy. Understanding how people communicate their happiness is the key to understanding how to communicate value proposition.

If the bet was less then successful, then you learn from the failure and understand what feedback makes people unhappy. Depending on the failure, the key here is to listen all feedback and understand the inverse of value proposition.

Influence

Here, what you do and say matters. Real leadership is not a title. Real leadership is doing and dancing in a field, and I strongly believe that you need to be the best version of yourself.

You aim to be a role model. This means that you need to always try to execute in the best way you know how. For instance, if you say that tests are required, then your code should always have tests. The recipe is fairly simple: “If you say that $X is important, then you need to do $X all the time.”

The implicit aspect of being a role model is that you need to speak up and communicate what you think is important. I value testing, and I make this a priority. I do not let things ship or leave my hands without some form of testing, and I communicate this up and out.

Exercising influence in this manners requires building up a set of values that define how you function and how you get things done. Once you have your values, then you broadcast them and let other people use you as a buffet of ideas. We learn from each other, and some of my values came from others. Some ideas, I have evolved from others. Some ideas, I drop and then communicate why I drop them.

The extreme end of influence is to inspire. I find this quote applicable as I am inspired by this quote often.

If you wish to build a ship, do not divide the men into teams and send them to the forest to cut wood. Instead, teach them to long for the vast and endless sea.

The lesson here isn't to use people as machines or “resources”. The lesson here is that a leader will point and say “hey, over there, it's pretty awesome. Let's go there, I am going, who is with me?”

Mentoring

I look at mentoring in two ways.

First, there is the explicit one on one relationship that is intimate. Get to know each other, and talk about stuff. This stuff could be about life, the field, challenges, people issues. The goal is to share experiences, perspective, ideas, and strategies.

Second, there is an implicit apprenticeship. I utilize this on new hires, and I tend to actively lead a new hire project directly with an idea of mine where we work together on all the design details. The goal here is to setup the new hire with a great project with a reasonable scope. The project is probably already designed either in the back of my mind or some short design document, but the project should be a platform to push tribal knowledge asynchronously and get people up to speed with the team.

At the end of the day, mentoring is about helping people grow. A key aspect of this is communicating the growth goals. Ask your mentee how they want to grow, and then help them. You can help them by sharing stories, giving ideas on how to experiment, and asking questions. The key is to make sure a conversation happens, and it is not a one way street.