Transcript
Brad Grantham: My background is C++ and Python, just so you know where I'm coming from when I talk about things that I do, technically. My position, I'm the CTO of GFXReconstruct, because I'm responsible for product direction, but I'm also responsible for some execution. I wanted to set the tone for what I'm presenting in terms of who I expect the audience to be. You are here. You have a strong technical game. You know your IDE, the tools, your editors, how to produce code, how to produce content, how to get stuff done. Lately, either you are involved in things that are more than technical, or you want to be. Things like talking to clients. Our firm is a software consultancy, so as well as working on Vulkan, we take on work that's just requested and paid for by clients. Supporting a business goal, if you find yourself thinking, I understand something about the business, and I want to make sure I have an impact there.
Representing your team in a meeting. If you're the only person and you have to suddenly speak for your team, that's a whole new skill. If you're being consulted by business leadership. This is where you are. You either want to or are starting to be involved in these things. Who here is an individual contributor looking for more leadership opportunities? Who is already in a leadership role and looking to sharpen your tools? My talk is a little bit more beginner, but I think I do have some stuff to offer if you're already in the role.
Growing From Code to Influence
I want to say synthesizing this talk was interesting, because I feel like I understand my journey, but I don't really know the perspective of people around me. Some of this story is from my personal experience, and some is pieced together by friends and what they've said, and also my management team and leaders that I follow. This is what I'm going to present. You have to be the right person in the right place and time. You have to expand your skills. This is to say more different skills than you'd have as an individual contributor. Sharpen your communication, which is basically just people skills. Once you start having a position of leadership, you all of a sudden have to deal with people stuff a whole lot more. Get past your own ego. It's all about lifting up the team. Finally, I'm going to talk about how reality is messy, and you need to have patience for yourself.
Right Person at the Right Place and Time
You have to have the right staff, and the opportunity has to be present. It's a little chicken and egg. Leadership doesn't really develop in a vacuum. You can't just imagine how it works and make it work. Someone with responsibility has to see you and see that you have some skill, and identify that you can fill a bigger role. You have to have some spark, like a desire, an ability to help others, an ability to adapt, that's super helpful. Taking initiative on something. All of this makes sense to someone who is looking to fill larger roles of responsibility in their organization. Sometimes an empty role is a catalyst, and it was for me. I don't know if that always has to be the case. If you're showing a lot of initiative and skill, I think people will sometimes try and make space for you. Very important, having a good mentor.
For me, I have a mentor group. When I started this, I had a very conscientious and aware manager, basically the CEO of the company, Karen Ghavam, who tracks people's skills and strengths and areas for improvement. She knew what she needed, and she measured me and other people about where they can fit into the organization. My CEO was also my mentor, but I don't believe that the person who selects you for a role that is new to you has to be your mentor, but you want someone that you can ask questions of, someone you can bounce ideas off of, especially someone who's already done this kind of work. That was me. In 2021, I was the sole individual contributor. I wanted to know more, wanted to do more, and found myself being asked to lead a graphics capture-replay project. We had one client, and there were two other engineers working on it, and I had shown some initiative.
I had shown that I could summarize detail in client meetings. I had an ability to balance our company's goals and also the client's needs. I keep saying client, and I think it's possible in a larger organization, instead of thinking clients, to think of other groups in the organization. In retrospect, I accepted this because I had a sense of obligation, but also a little vanity. I thought, I can do this. It'll be fine. It turns out, totally different skill set. My job stopped being about the code that I could write every day and started being about how I could get work done through others.
Expand Your Skills
Expand your skills. These are going to be mostly new kinds of skills. I have some examples, and I hope that some examples will take the place of a generalized roadmap and recipe, but AI, it's all the rage. I'm sure you've heard. Who's actually used an LLM to generate code? We weren't doing that because we're pretty conservative. A lot of our work is based on an agreement with clients, and that agreement said that we had to assign copyright. We were pretty sure that we could not assign copyright to things that we couldn't copyright at all. We really need to understand, how can we move forward? Because I felt like we were being left behind. I spent some time on my own, talked through with the CEO, can I spend a little bit of this work and then come back to you and present what I've discovered?
She said, yes, that sounds like a great idea. A lot of this work I had to do on my own time because I already had a job. Read up on legal issues. For me, that was a new skill. Again, the theme of all this is, you have a skill, you're a coder, you're a programmer, you're backend, you're frontend, you're TypeScript, you're whatever, but these are new different kinds of skills, not coding. I want to reflect, I think, what Pauline said earlier. She talked about applying your engineer mind to new domains which aren't code. People, in this case, it's legal structures. We had to go find LLM plans that we could use and how much they would cost. I drafted and stuck with an AI policy through legal review and then got it into the personnel manual, and that's a persistence that I needed to sharpen as a skill as well.
My challenge is, what is a domain that's slightly outside your expertise that you see your organization needs support for or some expansion, and can you take that on? Another example is identifying a new business opportunity. This is a little easier for me because the organization is only 30 people, so if somebody comes up with a good idea, it's relatively easy for them to just flag it and say, I would like to talk about this new possibility. We have a bunch of command line tools, at least that was the case a couple years ago, and we thought our software was mostly command line driven, but we were getting scattered because we were getting these questions about what people could do with our tools, we didn't know the answer to. I think when you hear that, when you hear questions that are like, how do I do this?
You think, it doesn't do that. That's an opportunity. You have to squint sometimes. You hear stuff and you think, what does that mean exactly? You have to dwell and let it soak. Doing the identification is more of an art sometimes than science. We gather requirements from clients, synthesize a whole new aspect of our software, and that allowed us to get in front of the problem. We retooled to allow some components of our command line tools to be incorporated into other tools. I say we. I drove a lot of this, but it's not in my nature to say I. I will say that there is a driver, there's a person, and that was me. You need other people because other people bring really great perspectives and they can do extra work, and they have additional things they can say, and that's very powerful.
I worked on standards bodies for several years. I don't do that quite as much anymore, but I still end up having to answer questions about standards. I recommend it. It's different. It requires a kind of clarity. That is a key thing to define and strengthen. It also requires tact. You have to be diplomatic because you're going to work with those people over and over again. Firmness as well because you're representing your company's goals and the organization's needs, and you need to be able to stand up and articulate those. Another small detail is that standards work requires building logic and skill with language. How many here have ever read RFC 2119? When you read a thing, a standard, and it says must blah, blah, blah, and shall blah, blah, blah, and can, those have real meanings, and this is a structured language. You can read this talk to find out what that means.
It's a form of forcing yourself to understand yet another way to program, which is in structured English. I'm not sure how much of this we're going to do going forward because AI might take that job away partially, but we'll see. Just a handful of last examples. These are things that I drove. A pull request process checklist. Who's responsible for signing off? What are the things you have to do before the PR gets filed and then also before it gets merged? An architectural principles document. Architectural principles are important because it allows you to state the why you do things. I've been thinking about this a lot working on these slides, that why is very important because when you can answer why, a lot of other things become clear. This is all in the service of taking the knowledge that you have as an individual contributor, your strong knowledge, and projecting it outwards and allowing it to be part of experience that you can share with the team but also allow other people to contribute so they can share. It just strengthens the whole team.
Sharpen Your Communication
I've been a little bit surprised how much I've had to sharpen my skill for communication. I thought I was really good at it, but it turns out as an individual contributor, our job has been to provide detail about a solution, to really understand it in depth and focus on how it works, and that's your job. When you become a tech lead, your job is now to provide that information to people who aren't necessarily engineers or they're engineers in a different facility, so you need to have the right level for the audience to enable them to make decisions and understand what to do with your team and focus on how it meets business needs. This one is particularly important because some people and myself may struggle to understand emotions in meetings sometimes. As an IC, your job is to ignore emotions and to sit and understand technical facts, and be able to explain those things.
Once you start being a tech leader and you start being in conversations with people who say things that are emotional, you need to understand why those things are being said. It could be fear of falling behind. It could be schedule pressure. If you understand why someone says something, it allows you to respond in a way that helps them and helps you and enables addressing the actual issue. How many people have been in a meeting where they said what they thought was the right answer and it was a technical solution, and then afterwards they found out someone else was really angry? I think the process for me of being a tech lead has been a little bit of not taking things personally. I'm going to come back to this slide later. Part of that is learning people's communication styles. I'm not going to endorse any particular one of these frameworks, but there are lots of frameworks that describe how people engage in language and the kinds of words they use and the way they deal with conflict, and how you can communicate with them.
There's one called DISC that's got four quadrants, and the quadrants are direct and collaborative and evidence-based. That seems very froofy, and you look at it and you think, that doesn't represent anything, but then there's an additional piece which is a matrix, which is if you're in this quadrant and you're talking to someone in this quadrant, here's how you can engage them and make them feel bought in. I just recommend looking into it. A key piece of the quiver is one of these frameworks. In fact, I will call it an example. My boss is very direct. I think she has just a lot of stuff to do, but she's learned to be extremely direct. When I learned to be direct back, I started getting a lot more traction, and I realized that her being direct wasn't a challenge for me. It was really just the way she expressed what she needed. Once I could do that back, things got a lot smoother.
Get Past Your Own Ego
With great power comes great responsibility. What that means is once you have these skills, you can help your team members succeed, and that means you also succeed. Your job is not to look smart anymore. As a tech lead, your job is to get something built. You still may feel looking at a problem that you're the only person who can solve it because you know the content, and you're pretty sure if you just dive in, you could solve the problem. Growing into a tech lead means you have to be available for different kinds of work, for lead work, for building roadmaps, for doing things that other people can't do. If you do that work, the individual solving a problem, then you're removing another team member's opportunity for growth, that they could learn something new. Just to say all this again, fixing a thing by yourself is no longer your contribution once you rise to TL.
If you give people a space to show their strengths, you give others a chance, you have a little bit of faith that other people will succeed if you encourage them and give them the framework that they need to be in, they'll step up. One thing that I'm still trying to internalize here is, you can take credit for a task, "I drove a task." That does not diminish the work of the person who did the work. You helped. You built a framework, you built a structure in which they could get the job done. Then they did the job, and you both get to have credit for that. Pauline was talking about the silent work, the hidden work, and I think that's part of it. It's very difficult to see, there's no GitHub Issue for it. A more specific piece of this is stop fighting fires. If you have these strong technical skills, then fighting a fire feels productive.
It feels great. You can dive in. You can get it done. It looks good on your review as an IC. As a TL, your job is to try and find symptoms of structural problems. This is a realization that I've had lately. If you are fighting fires, you may be procrastinating. Growing into leadership is hard. It requires feeling like a beginner a lot of the time, and that growth is painful. You may be just hiding from it, and that's important to try and understand. I'm still working on the guidance for that too. I mentioned having a good mentor team earlier, and that's important the other way round too. Providing guidance to people is powerful leverage. It doesn't have to be formalized. When I was told before, like, you should mentor more people. I thought, ok, I have to sign people up for a program. I have to have weekly meetings with them.
I'm going to have to have a back and forth. That's not really true. There's a lot of informal mentoring that happens when you're in a pull request. When you don't just say, change it to this, but instead you say, I would like this to look more like this, and that's because, for these reasons, it's a better idiom, it reads better. The performance is going to be better. That once you provide why, then someone else can internalize that why, and that becomes something that they carry forward. Not to go back to the boss of the company too much, but she said to me, as part of the feedback for this talk, that she feels like she's at the service of the engineers. As a leader, your job is to give others an environment where they can be productive. It's this kind of thing where you're providing guidance. I'm going to give you this feedback, and here's why I'm giving the feedback. I'm going to explain to you why I came to this decision, and hopefully you can internalize that and go forward.
Reality is Messy
One size does not fit all. Generally, I discussed earlier, from my point of view and my experiences, that the circumstances have all lined up. Someone identified that you have the potential to fill a role. Most of it will take time and practice. You will make some mistakes, and that's ok. We talked about psychological safety, which depends on the organization, but if you give yourself room to try things out, you may find that your management has a vested interest in your success. Often, the reason that they chose you to fill a role was because they saw a potential, and they've spent some time in that, and they want to support you. They want you to be successful, because then the organization is successful. I mentioned earlier, as a communication style, understanding the reason why people show emotions in meetings. You can tell I'm more of a calculating, evidence-based person, so this has been a little bit difficult for me to internalize.
You don't have to take things personally. You can take a deep breath. Don't send that first email. Ask others in your organization what's going on. We had a pivotal client a couple of years ago. Repeated praise, repeated five out of five, everything's great. Then I spent two days in person at a meeting, face-to-face, giving my technical feeling about what can be done with the design, and then on the way to the airport, I was told by someone else who was at the meeting, they're not happy with our performance. Not happy with the amount of work that you're putting in and the amount of work that the other engineer is putting in. We're going to have to step up, or maybe they'll move on to another provider. I thought, that's that. They hate me. They hate my skill. I have answered all the questions wrong. That wasn't really about me.
Thinking back, the meeting was very positive. Letting it soak and intellectualizing this, when someone says they're very unhappy, that is an opportunity. That's a chance to stop and think about why that's happening. If you can provide feedback that lets them get forward, then that's a much stronger relationship. They've been working with us for two years since then. My wish for you, if this is what you want, is to be able to do this. I interact with business leadership on a regular basis. I work with the engineering team as well. I interact with clients, and I take their input and I put it on our roadmap. I still focus on architectural consistency and quality, and that comes through in pull request reviews, in meetings where we talk about what software to write. I take a share of responsibility for the team and the company and our progress, and that's very worthwhile.
It requires reframing what you're satisfied by every day. Rather than just, I wrote a bunch of code, it works great. To, I see progress in the organization. I see movement. I see momentum. That's increasing the scope of your boundaries, increasing what you see. My perspective is mostly tech lead. At a small organization, it's also possible you may have another hat. My hat has been a little bit giving other people tasks, and that's been interesting, too. Some of what I've said through all of this is informed by that.
Going out on a limb here, how many people have heard of The Hero with A Thousand Faces? Now is my time to do the xkcd thing where I'm like, I'm so excited to tell you about this. This is great, you're going to love it. There's a book called "The Hero with a Thousand Faces," and it's about the hero's journey. There are 17 stages in it with things like, Call to Adventure, The Supernatural Aid, The Ordeal, The Return with the Elixir. It doesn't have to be that dramatic. This is all basically a framework for understanding people's journey through growth, every person's journey through growth. It's fractal too, we experience it over and over again in our lives. I use it to help me understand where I've been in this journey, but also other journeys in my life. It's not a blueprint, it doesn't match exactly, but it's been a helpful book. It's really a survey of mythology as it relates to human experience, and so it's the hero in all of us.
Conclusion
Summarizing everything I've said, you can strengthen your skills. That's taking all of your tech lead skills, keep them strong, and then build new skills. The skills are about extending your reach, including other people. Target your communication to the audience. Understand that you're entering a new realm where you have to say things that are about the business. They're about organizational topics. Get past your own ego. You're really working through other people and lifting up the organization around you. Don't be too hard on yourself. It does take time.
Questions and Answers
Participant 1: One question I had in this team building movement is how do we deal with other peers who are also looking to grow? I think with the whole AI [inaudible 00:26:57], opportunities for growth are small because we're competing with AI for growth and that means we might have somewhat toxic, competitive peers and more than one person is competing for growth. Do you have any tips?
Brad Grantham: Did you say competing with AI for growth?
Participant 1: Yes.
Brad Grantham: What do you do in a situation where you're competing with peers but also possibly AI for growing and filling up more roles? AI is kind of like dealing with other people. It's the same kinds of things. You have to understand that your clarity is what improves your ability to communicate with an LLM. This is a little bit new to me and I don't really know if I have a good answer for how to compete with an LLM.
Participant 1: Maybe the people aspect, compete with a peer.
Brad Grantham: Then competing with a peer, I like to think of it as more as cooperating, if you can. I know that in organizations, often there's a rank order. I feel like it's a little contrary. If you help other people, that will raise you up. The more you try and help other people go up, you'll be visible as a person who's doing that. That's one thing I have to offer about that.
Participant 1: I feel like there's a few times in my career where I felt like I was competing with, especially when leadership is like our priority this year, is portability, or our priority this year is Windows. The time that I've made the most success in my career is when I walk away from what I call a shark swim, so that everyone is fighting for their piece of portability, or Windows, or whatever it is that year. Walk away and look at the situation, and use my own judgment to say, what is the important thing, what do I think is going to be important, and then do that.
Participant 2: My question was around effective communication where you mentioned you had to change the style of communication as you were making that bridge gap from IC to a lead. What were your takeaways of what you have to change? Because now you only have to communicate with technical peers, but also the non-technical peers as you do in your leadership role.
Brad Grantham: What are some takeaways from having to change communication styles? There's two pieces to that. One is understanding what other people need in order to make decisions. I think at the base of that, sometimes you just have to ask, what do you need from this meeting? What do you need from this document? What's the best way that you're going to be able to go forward? I think asking questions is very powerful. Another lesson I've had to learn is sometimes just say, I don't know. Can you tell me more about what your goal is here? That's one thing. Another is these communication styles that people have, where sometimes people are very enthusiastic and they want to run ahead and they want to solve a problem. That's great. Those people are very important to have in the conversation, but it's not my style. I've learned to just say, that's great. You really have to translate from your internal feeling to basically an internal language that someone else has. I think that's been helpful for me to just always be like, I have the way I communicate, but I am communicating with them so I should match styles. I should torque convert to them.
Participant 3: How do you view like different archetypes of like staff or senior staff impacting how you communicate, or how do you, based on your own path, even if like the whole doesn't have that kind of archetype that you do?
Brad Grantham: I've been part of this organization for six years now and it's very flat. Mostly I've been called to do a thing. I want to repeat the question as I understand it, it's about communication. Like when somebody in the organization has a communication style, when they have a flavor of a thing that they have, how does that get reflected? I will say that our organization is pretty flat. Our CEO's style is very direct. It does make it so that everyone else excels when they can work within that. It's a little bit obvious, but once you know how to communicate in that style, once you know how to respond in that way, it makes you more effective.
Participant 4: Once you're in a leadership role, how do you keep up with updating technical skills?
Brad Grantham: I've been a little bit lucky that I have just enough time to spend writing some small PRs and reading other people's code in depth. I have time to do that. I think I have two things to say. If you don't have time for that, if you have an engineer's mind, if who you are really is curious and you ask questions and you internalize why things happen and the structures, that doesn't go away. Even if your hands aren't in code every day, you'll find yourself asking questions of those people whose hands are in the code every day. That'll give you a kind of, people will trust you because they'll hear you ask the right questions. Once you have that information, you can also offer that up to your management chain to say, I've talked with the team, I asked these questions, here's what the answers are. They think, great, I can rely on you to talk to the team and digest what's going on. It's great if you can find the time, but if you can't, it's probably still ok because if your origin story is engineer, it'll stick with you.
Participant 5: Talk about getting your ego out of the way.
Brad Grantham: Tell you more about getting your ego out of the way?
Participant 5: Yes, what was successful, [inaudible 00:34:17]?
Brad Grantham: Mostly it's been somebody else telling me, you need to understand how much value this other person has. I have been told a couple times, not that frequently, but every now and then I hear someone say, you're intolerant. I think it's because it's easy for me, and this is a character flaw, to project like, you should know what I know, and I don't understand why you can't come up to speed as quickly as like, just instantly read my doc. When you think about another person, basically put yourself in their shoes, you think about what they can bring and what they can offer. That makes you work for them. It makes you work because you want them to succeed. It also gives you a chance to think, is there something going on with them that I don't see? Maybe there is. People always have stuff going all the time that's distracting.
Language issues or whatever. Once you have that in your mind, you think that person needs this. Ok, now I'm in a position where I can help us both succeed. That's a piece of getting your ego out of the way. I put leadership is service on a bunch of drafts of the slides, but I could never really make it stick in my mind. Leadership is service. You're trying to help everyone else support the organization better.
Participant 6: Can you talk about your approach toward assigning work to other people, in particular making sure that your intent is not just specific requirements is communicated effectively through something like [inaudible 00:36:19] or written communication?
Brad Grantham: In our example, a fair amount of our work is communicated through GitHub Issues. Like, ok, your next thing is this. Otherwise, we write technical documents, specifications that say this is what the work is. Some of that is often collaborative, like this is what we have. Then, I think you're going to do the work and you talk to us about how you think you'll do it and what that looks like. That's very collaborative and it gives people a chance to own it too. They could say, this doesn't seem to make sense, but if I did it like this, it would make sense. You say, ok, great, do that. We do a fair amount of that back and forth in documents. In our case, it's much clearer often because we have clients. We're just like, this is what they want. Part of my job also is we have the software package and it's very important to us.
It's a source of a lot of our business. My job is to be in meetings where a client says, I need XYZ. I think, ok, in order to do that, we're going to have to solve some technical debt that we had around that. That's going to mean that we do work over here. Sometimes that's me. Sometimes it's someone who's in a bucket that we have, which is not client work. Just like, can you go look at this? Because we need to solve it in order to solve that problem.
Participant 7: How do you manage balancing tech debt among the team? If you had to sell tech debt or mentor someone to say, go and work on something. Sometimes when you're in a leadership position, everyone wants to work on the cool, shiny object. Right now, I'm left with all the tech debt, so I do all the tech debt myself. I'm trying to understand how do I sell it to people so that they can do it.
Brad Grantham: Fixing technical debt raises the entire codebase. It's very important. It sometimes doesn't feel that way. If someone's off writing a feature, great, but they're not raising up the rest of the codebase. If you can remove tech debt, it'll probably help more people. As much as you care about that, as much as you care about the organization doing better? I recently had a moment where I needed to tell an engineer, I would like you to work on this thing. It's basically cleaning up this thing, this feature. I said, why don't you take a look at it? I feel like it's becoming difficult for us to add code to it. Spend a couple of days just reading through it. Let me know what you would do. I already had some ideas. I thought I'll do better if I have my ideas and their ideas. Now we both own it.
It's a chance for me to say, those sound like good ways to go forward. Can you do that? Also, while you're doing it, can you do this thing that I need? It's strange. In my mind, I'm like, is that a bait and switch? It's totally true. If you go fix like string compare, that is a bug. String compare is like, everyone uses that. Everyone's going to see it. You can tell people on their thing like, you should write down, you fix string compare, because everyone uses that. It's a flip of like, no, the tech debt stuff is the important stuff in some situations.
Participant 8: You mentioned that communication is a key part of being a leader. There are different communication styles and how people have to communicate. You need to actually understand that and be able to communicate the same way they would like to. Do you have any tips on communicating with a person who is hurt and is not actually ready to open up or have a conversation? How do you break ice with them and make them open up to you?
Brad Grantham: Are you responsible for them being hurt? It's really less about technical stuff all together, and it's more about people. That's a whole communication style. For me, I think it starts with, I apologize, and let me explain why I took a position. Now you tell me what you think. You can also just say, "I need you to tell me what you think. This is your chance. Just explain to me what's going on." I think this is a little bit weak sauce, because I'm still not very good at it either. I've had this experience lately where someone said, you're giving all this bad feedback, this negative feedback. They want to understand why. I was like, no, I have to talk to them in person. Then it changes your mode to, that's another person I'm going to talk to, and I have to justify some things I'm going to ask them to do.
You put them in their shoes, and it makes it clear how what you're going to say will sound. There's a little bit of the stereotype of you go in with two beers. You say, have a beer with me and explain to me what I need to do. Which isn't really practical. It's more like that. Just like, I'm going to treat you like a person and I hope you treat me like a person. We need to solve a problem. Another thing I'm really still learning. I've been doing this for about four-and-a-half years, and I still have lots of things that I figure out and learn. I'm reminded of, it takes time. It takes practice. You have to be ready to stand back and say, all right, I'll come at it again.
Mason: There is a lawyer whose name is Jefferson Fisher. He's got a YouTube channel. He gives all these immediate responses. You're in a situation and someone insults you, or they undermine your intelligence. Where they, how do you respond while still sounding professional? I love his stuff. He's got a book.
Participant 9: I have a question about how you will trust in your team that they are comfortable enough in giving open feedback.
Brad Grantham: I think it is a process of building. It's a little chicken eggy too. If you have a big enough team, you'll have somebody who will just provide feedback. If you encourage that and you say, "That's great. Thank you very much. Here's what I'm going to do with your feedback." It makes other people think, good, I will be able to do that. There are some people who are just shy and they're never going to feel comfortable. I'm not really sure what to do with that. It is that long-term process. I've tried really hard to learn to give kudos to people in meetings. Just remind people like, this person did this job for this customer. It makes people feel like, I'm worth something and I can say something valuable. It's just a long-term process.
See more presentations with transcripts
