 All right, so there we go. I'm Kathleen Vigno, and I'm a senior engineering manager at Twitter. And I've spent the bulk of my engineering career as a full-stack web developer. But now, as a manager of internal web tools teams, I have the pleasure of coaching many full-stack web developers. And recently, oh no, it's not advancing. Don't you hate that? Oh boy. All right, so this is a question that I recently posted on Twitter. What made you want to be a leader on your team? I asked people on Twitter. And I would like to know, before I show you what my favorite response was, how many people here are interested in being a leader? Leader manager types a few. All right. If you raise your hand, you've probably given some thought to leadership skills. And you might even be currently pursuing a leadership role. But here is the answer that my friend Taylor gave. I didn't want to lead, but nobody else was doing it. And this really resonated with me. And I imagine it resonates with some of you. Because a lot of times leadership happens, you get thrust into a role that you never really asked to do. And then you might find yourself not equipped with the skills that you need to do it. So this talk is actually for those of you who didn't raise your hand. It's for engineers who find themselves kind of needing to shore up some things that turn out to be leadership skills. So when I have one-on-ones with engineers, I hear people wanting these things. They want recognition, compensation, promotion, respect, influence, and to help other people. But they really struggle with how to do some of these things, especially as they get into the higher leadership roles, like tech lead or staff engineer. So generally, those people are really focused on technical skills. And so I find myself coaching people to equip them with the tools and the strategies that are leadership-related. OK, so now I want you to get out your phones, laptops, whatever you have handy. And go to this URL, polev.com, slash ICD team, which has nothing to do with this talk. So it's just that it's my friend's polling account. Anyway, so go to that URL, please. And if you could start entering, what is challenging for you about being or becoming a leader on an engineering team? I'll give you like a minute, and we'll kind of see what develops here on this word cloud. So far, contribution, developers, balancing. Oh no, disconnected, what? That's no fun. Suppose if I, oh wait, oh, there we go. Hey, it's starting to build. So curious to see what you guys put. All right, I see mentoring, I see trust, people, consensus, skills, time, technical skills, time is getting bigger. People, oh my god, how do you deal with these people? These people in code are kind of different. Awesome, this is right. So here's what I did. I wanted to come up with the top leadership skills that we need, that we find that we need. And I didn't want to just pluck them out of my head. I wanted to pull out some data. So I had access to a survey of over 100 senior software engineers. So I pulled all the, there were basically five questions that I boiled down, and I chose three. And took the columns in the survey responses, dumped them into text files, and I used a little Python library. Has anybody used word cloud? It's really fun. It's easy. So word cloud is a Python library that makes word clouds, which is super fun. And so I cloned it and had those text files are ready to go. And this is, I barely had to modify the example file. I just added some stop words. I didn't want to get things like team and leader and stuff like that. I wanted to extract that out. And then it just generates these awesome word clouds. So I'm going to show you three. The first one is the worst qualities, because a lot of what we learn about leadership is from people who do it wrong. And so what we see in this word cloud is not giving good feedback, lack of empathy, lack of communication, lack of trust and confidence, micromanaging, arrogance, lack of technical ability. That's really big, that inability there. And oriented to who? Self. It was lack of orientation to others and more oriented towards self. So then the next question I analyzed was what are the best qualities of people's favorite leaders? And we see some of the opposites, right? We see empathy, care, listening, trust. There's feedback and humility and honesty and technical ability is really big. We want our technical leaders to be competent. And oriented to who? Others. Finally, I saw the question that was very similar to one I asked you here today. And we'll see if there are some similarities here. So what people really struggle with and those things look like they were emerging to be time management, having those right technical skills, that ability, giving feedback because it came up all the way through, communication, and developing trust. So many of these skills appear on purely technical engineering promotion letters. That's the thing, right? You don't have to be on the manager track when you're looking at those higher levels of being a tech lead. People are starting to expect you to lead. And so you can only get to a certain level if you don't start to pick up these skills and learn how to work with others. So now I'm going to fly through the top five. And it's just a high level touch point on all of these things because I have 25 minutes with you all. I'm hoping you can kind of take these ideas and go do your research, read some of these books, and see where you get to. So the first one is communication. Here we're going to talk about written communication. And so first we're going to think about emails and technical docs and then show you this email. And if you can read it, I hope it's big enough. Basically, this is an email to me from Sam, a fictitious dude named Sam. And the subject is Doc. And Sam's telling me that Claire is concerned about the schedule and there's some stuff about the time. And we're maybe going to have to change the widget service and move it in relationship to the loader. And there's just a lot of information. And then there's an attachment. Anybody have any thoughts about what's not great about this email? No cold action. What else? That's awesome. Yes. What's that? The subject is useless. I don't know about you. I get 1,000 emails. I run four teams that'll have different stakeholders and different projects. And if I got this email, like, oh my gosh, I have no idea what it is. And even when I read the email, I'm not really sure which of these four projects and which person. I don't know what we're talking about. There's a lot of words in here. Like, oh my gosh, what am I supposed to do? I have no idea. I'm probably not going to do anything is the thing. And Sam's not going to get what he needs. So I'm going to break this out into two ideas. One is going to be I just think this email could be one idea. And then this technical problem he's discussing could be another idea. So let's take just the email. What if it looked like this? What if we could say that the subject was the image cropping feature requirements? And what if we could say that there's a draft of the product requirements doc for the image cropping feature? There's the context. And that he needs comments and questions. And he needs them when? By the end of the day, Thursday. Oh, now I know what I'm supposed to do. And now there's actually a chance I might do it and give Sam what he needs. So in terms of the wordy technical explanations, how about a diagram? Wouldn't it be great if we could show the current state of the widget service, which is at the end, and the proposed solution, which is to put it at the beginning? And I can understand that instantaneously from a picture like this, which might be a design doc. And then also I get some other information in a list, which is really easy to parse instead of that big blob of paragraph of who authored it, who the reviewers are, what the estimate of time is. So it's easy to scan. It's easy to understand. So I give you a communications checklist. Emails, docs, some things to think about. So who's your audience? Is it a non-technical person, a colleague, a junior engineer? That'll help you understand how much detail to go into. I find engineers going way too far into technical detail with customers who don't care. What about the context? Does the audience have the necessary context? Doc, what doc, for who, for when? I don't know anything about what you're talking about. Assume I know nothing. What is the intent? What do you want the person to know? What's that call to action? And what do you want them to do, and when do you want them to do it? Length, TLDR, too long didn't read, that's all of us, all of the time. So can you say more with fewer words? Can you use bullets, bolds, lists? Make it skim-able, skimmable or scammable? And then how about visuals? Oh my gosh, please add a visual. I find myself, like, draw it on a whiteboard in the meeting, or please draw it in a visual on the doc. Don't use all those words. And have a customer service or teamwork attitude too. That really helps. It just, if you react with customers in a way that says we're all on the same team, we're going to figure this out together, it really makes a big difference. OK, and then I'm only going to say one thing about code review. Don't be a jerk, right? You just follow that one rule in code review? Instead of saying, this is wrong, this is stupid, you shouldn't do it that way, why don't we just say things like, you might want to consider this framework, or have you checked out these docs, or this is the preferred syntax using language that's not so corrective and not putting people down. Corrective and not putting people down. Because I find that the more we put people down and make them feel stupid, the more they close up, the less they ask questions, and the more mistakes and problems they have. All right, we're moving on to time, because time is a big thing that comes up for people, and we're going to talk about estimation, and we're going to talk about time management. So first, time management. Almost every single person on my team that gets more responsibility says, I don't know how to manage my time. And it comes down to ruthless prioritization. You can't do all the things, and we hear that, and we know that, but we still try to do all the things. So we have to choose the things that we're not going to do. And so that's about saying no, which is a little bit of a practice, practicing disappointing people, practicing saying no to things, figuring out what to say no to, choosing like, okay, this is not important for today, I'm going to do the thing that's really important today, and I'm going to worry about that tomorrow, and also what to say yes to, just being really deliberate. The book, Essentialism, says more than I ever could in this talk, I really highly recommend it. I think I'll probably read it again soon. It was good enough, I want to go back to it. So I recommend that. I have another question for you all, phones, laptops. This is about estimation of time, and I'd like you to try to guess, and maybe you know some people who contract or might have a better sense of this. How much time do you think you spend doing heads down coding and development? Like actually coding or designing the thing you're about to code, and just that activity, not testing, not building, not messing with your environment, not setting up your sublime packages. Cool, we're coming in around 25 to 20, you guys are pessimists, it's pretty low. Where does F work? Yeah. Cool. Awesome, okay, so you guys are coming up at 20 to 25%. So there was a survey in 2013 of by a software development services vendor called Electric Cloud, and they surveyed over 400 people, software engineers, and these are the estimates that they got from the survey. So they found that people said they were spending 6.7 hours brainstorming and collaborating per week. 5.8 hours doing emails and meetings. 3.7 hours waiting for tests, right? We have a puzzle area in my office, so people bring their laptops over when they're running tests or doing builds, and they like go and do the puzzle, and wait for the, you know how that is, right? So there's another 3.5 for the builds, and then 2.7 environment management, right? And like new OS, you gotta upgrade, new packages, what have you. So that's a grand total of 22.4 hours out of a 41.5 hour week, just for administrative stuff, not doing actual coding. So you guys were really pessimistic. This comes out to 46% of time is actually spent doing design and coding, which means that when we estimate things, it's gonna take twice as long as you think it's gonna take. And that's if you really know what it is, right? There's a whole nother issue. So if you really know what the task is, and you're pretty good at assessing, like, okay, I gotta build this module, and I think it's gonna take me four hours, it's gonna take you eight hours. The other piece of it is really knowing how to estimate when you don't really know what something is going to be. And that comes down to breaking things down into smaller pieces and understanding all the different parts of a task, writing very detailed technical design docs help us do that a lot better. And agile t-shirt sizing, we don't ever ask any engineer to give us an hour estimate for things. This is more of a theoretical idea of it's gonna take twice as long as what you think. And by that, I mean size. So we do agile t-shirt sizes at work. We say it's either small, medium, large, extra large. We use Fibonacci numbers to assign points. And then we kind of get a sense of how many points people can generally do. So the more we do this, the better we get at kind of estimating at the front. The tech leads are the ones who are often trying to do this estimation. The better we can be at setting up customer expectations and the better tech leads are at leading. So what about feedback? Feedback is a very challenging thing. And again, as we're talking about people who are more senior, they're starting to have to give their teammates more feedback. And they're having to give them critical insights into what other people could be doing better. So whose job is it to give feedback? It's not just the manager's job. It's not just my job. I'm always telling my team. Like I need you guys, you guys observe each other and you work with each other in ways that I can't even see or view. And you need to be honest and help each other get better because otherwise it's Bob who's like, what? I got fired and no one told me that thing I was doing wrong. And now I have no job because I had a chance to get better and nobody told me how I could. So you wanna be that person who can give people feedback that they need to get better. My best advice for this is to use this concept from Radical Candor. There's a book by Kim Scott. I have a picture of it later. Her way of thinking about feedback is there's these two axes. One is to care personally and the other one is to challenge directly. So if you care a lot about somebody and you never give them any good feedback you're getting into this ruinous empathy area where they're never gonna get better and they kinda get ruined. They don't grow. And if you're a total asshole that's the challenge directly but don't care at all then you fall into this obnoxious aggression area and nobody likes working with that person. So you wanna hit that combination of I care about you, I'm gonna give you this feedback because I want you to grow because I like you because I want you to succeed not because I wanna cut you down and give you bad news and make you feel bad about yourself, right? So you can get more information about that from RadicalCandor.com. The other feedback mechanism that's been really helpful for me is this SBI framework. I use this at home with my kids. I use it at work. And the breakdown is basically describe the exact situation that you were gonna tell somebody some feedback for and then talk about the exact behavior you observed the words they use, the scenario, exactly what they did, the way they looked, the way they touched someone or I don't know what the problem is, right? And the impact, what was the impact that it had? So here's where we were, here's what you did and here's what the effect was. So the example would be at yesterday's meeting, you interrupted me several times when I was sharing my design with a customer and the impact is that I wasn't able to effectively share my designs and I think now the customer is not gonna have faith in me, we're in us or our team. So that gives a person something to work with. They know exactly the words they use. They can think about the scenario and remember what they said and think, okay, how would I do that in the future? Really, really super helpful. I use this all the time. Some more information. There's the Radical Candor book and then difficult conversations because it's not just the how you give the feedback but it's also like it gives lots and lots of examples of what types of difficult conversations you might need to have with people. These are very helpful resources. All right, then we get into the area of building trust. Sometimes we think about this as soft skills. So this is about empowering other people. So I would say that the more you take on leadership roles, the last thing you should be worrying about is yourself. I know as a manager, one engineer on my team is valuable to me but the engineer who can empower and multiply five other people is five times more valuable to me and the way they do that is they teach, they listen, they coach, they give credit and they solicit ideas from everyone and everyone gets better. So this is that others, very other focused is something we need to be more and more as leaders. And in order to be focused on others, we need to listen to them. So some ideas around active listening. Again, people tend to think managers are the only ones who should have one-on-ones with people. I really encourage my tech leads to have one-on-ones with people too. Because then they can, what I notice is that when a tech lead has a one-on-one with a junior engineer, the junior engineer feels safe to kind of be like, I'm really struggling with this thing and I don't know what to do and they can get some of the advice that they need. It's easier to do that in that small context than like in a big meeting or something like that. So it can be coffee, it can be lunch, it can be meeting, whatever works. And in those one-on-ones to give people our full undivided attention with eye contact and no distractions and no phones and really asking the person questions and being curious about them and what they wanna learn and how they wanna grow. Paraphrasing back what you think you hear, I have one very wordy person who gives me lots of information and it's hard for me to understand exactly what he's getting at. So I just come back with like, it sounds like you're frustrated with that. And sometimes he'll say, no, no, I just wanted you to know. I'm not frustrated, I just wanted you to know. Okay. Or it sounds like you're upset, you're mad, you're angry and we can kind of get to what is the actual thing you're trying to convey to me? Because sometimes it's hard to understand what someone really means. When I paraphrase back, I know if I'm understanding them properly. And I would like you to try this at dinner tonight. It will challenge you to, when you go out afterwards and you meet some people at your table and you get their name and you find out where they work and maybe hear about a project that they work on and then you go home or to your hotel room. Can you remember the stories that you heard? If you can't remember a single person's name that you met, you need to be doing a better job listening. Here's a book about listening and crucial conversations. It's a different type of conversation book, but again, how do you really engage with people? How do you really coach them, connect with them? And so finally, let's talk a little bit about increasing your technical competence. So you can have all these things, you can be a great leader, you can have great soft skills, vision and communication, time management. But if you're not technically competent, people are not going to follow you. And you might have a hard time understanding the challenges that your engineers are facing. So, and you're also expected to see some red flags in architecture and decision making. So you do need to have this technical competence, right? So usually what we think about is, and we think more about this. So expanding your skillset, especially for juniors out there, pair program as much as you possibly can with anybody who will pair with you. You will learn so much so fast. I try to get people to validate their approaches. I think there can be a lot of pressure, especially as you're more experienced, to have all the answers and just have it all inside your head and know how to build everything. But even the more senior people can validate approaches with everyone on the team and learn new things through that process. Or even with other teams, sometimes one senior engineer on this team will validate their approach with another senior engineer on another team. And that works really well too. You're here, you're attending a conference. Yay, you're expanding your skillset right now. You're reading articles probably, and anytime you can apply a higher level design pattern or framework or that first principle thinking to your problem instead of taking the problem by itself and trying to problem solve it, thinking about it in the larger span of things like design patterns and maybe programming design theory. Seven languages in seven weeks. Doing that sort of an exercise can help you kind of see the strengths of various different languages and maybe even think about what we saw earlier, like combining Fortran and C and Python to see which one is best at what. And maybe even taking some ideas from the way Fortran is good at loops and maybe you can build that into or pull in libraries in other languages that will help. So those are technical resources. But also I find that getting to the why of the reason we're building the thing in the first place is not the thing that a lot of people think about. So there's one mechanism called Five Ways. I included the link here from Six Sigma. It's all about how do you get back to the root cause? And the example they give is there's a car. Someone's got their car in that it broke down by the side of the road. And why did it break down? That's the first why. The alternator broke. Well, why did the alternator break? Because it hadn't been maintained. Well, why hadn't it been maintained? Well, because I didn't know I was supposed to maintain it. And then the moral of the story is that drivers need to understand a maintenance program and they need to be taking their cars in every six months and then that will avoid the broken down car on the side of the road. But it's just this idea of like, how do you get to the root cause of a problem or how do you get to the reason why we're building the thing? Another resource I really like is the start with why Simon Snack Ted Talk. He talks about Apple and why Apple products are, you know, they're doing pretty well. I got one right here. I got one right here. I got one right here. And they build products about why, you know, they start with the why instead of the what products we're gonna build. He does a better job explaining it than I can. And once you understand the why of what we're building and we're not just gonna ship a thing. We're gonna try to move a needle. We're gonna try to make an impact on our company or on our team or on our business. Then you can get to the purpose and then you can get to the how we're gonna build it. All the details of that. So these are the skills we talked about. I would like you to choose one of these skills because you're gonna have to ruthlessly prioritize. Pick one of these skills to try to work on this week. Maybe using some of the resources that I've shared. We just scratched the surface, but hopefully this gives you some starting points. And just remember, leadership is not just for managers. It's about influencing and directing others for positive impacts or positive outcomes and high impact. So thank you very much.