Critical Skills for Management

[00:00:00]
>> Talk about these these critical skills you need to build up over time. Basically, I'm gonna bucket them into four categories, communication, which I'm doing right now, written and verbal. The people side, that's a big one. The business side, the part you probably don't see a whole lot as software engineer, but you definitely do as a manager.

[00:00:19]
Then the technical side, we are engineering managers. There's a technical piece. A critical skill, you have to be able to communicate. Someone asked earlier about remote versus in-person versus hybrid. My team's hybrid. I go in the office about twice a week or so, and half of my team is in the office.

[00:00:40]
The other half of my team is entirely remote. That has its own challenges. If your team's all in the office, that has its own challenges too. If your team's entirely remote, totally different set of challenges in how you show up. But the common thread amongst all these things, it doesn't matter where you are in the world and how your team operates, you have to be good at communication.

[00:00:57]
If it's in-person, you use probably a lot more verbal communication. But what if all of your team's in-person but all your partners are remote, how do you communicate then? Probably more verbal or probably more written, but verbal in person. And I've done all these different scenarios cuz there's so many different things you can plug and play and there's no one way to approach it, but it doesn't matter what it is.

[00:01:20]
You have to be good at communication. I won't knock anybody, but I'm flabbergasted sometimes, the level of executives and then C-levels, the CTO and CEO, etc., who are poor communicators. I'm like, how did you get here? People that can't get up in front of an audience and explain things very simply or without passion, it's shocking.

[00:01:47]
It's a skill missing a lot of people. But the truth is, if you're gonna be a good leader, you have to be good at communication. I'll be honest, I'm good at verbal. Hopefully, you all aren't bored yet, and I'm doing a good job selling, doing well in the course.

[00:02:03]
Written, I'm terrible at it. I won't say terrible, but it's not my strong suit. I tend to overthink what I write down, versus if I talk, I feel a lot more comfortable just saying things off the cuff. So when I write something down, it takes me much longer to be how's this coming across?

[00:02:22]
Is this the right words? Is this too complicated? Is this too short? And I tend to overthink that a little bit. It's something I do try to work on over time, but written shows up in a lot of places that you probably don't expect, your Slack messages. If you're like, I don't know, someone on my team is like, hey, hey, Jem, I'm gonna be late today.

[00:02:41]
I'm gonna miss the team meeting. And I give them the thumbs up. What does that mean? Is that like a passive aggressive or is that like cool, whatever? There's a lot of ways things can be interpreted. And you have to think about that as a manager is how you're coming across.

[00:02:59]
I tend to come in hot on things. If someone's, I don't know, if someone's asking my team to do something or not treating them with respect, I tend to come in really hot, defend my team, but I need to back off from doing that. And I need to take a step back and see what I'm writing, how it can be interpreted.

[00:03:15]
And then when you send an email, you ever think about the audience of an email? Now we're getting into it. Most people don't know what your team does. Most people don't care what your team does. That's just the truth. You have to send your emails with that perspective of, they don't know anything about you.

[00:03:33]
What do they need to know? It doesn't matter who's reading it. And who's the audience? If it's a software engineer, you can probably more tactical. If it's meant for directors, executives, you got to be high level to explain things like basic stuff to people. That all that comes across, writing memos, project docs, a lot of the written communication, and there's a lot of it more than you think of.

[00:03:57]
And verbals, there's a lot of, there's one on ones, there's meetings, there's video calls, there's hallway conversations. There's presentations. So all that says the most important skill you work on is being an effective communicator, whatever the medium you have to use at that time is. And there's a lot of different channels you have to use and become good at.

[00:04:20]
On the people side, you have to be good at mediation, conflict resolution. You have to be good at growth. If you never grow your team, you'll be working harder and harder and harder and harder and wondering, why am I working so hard? Why is my team picking up the slack?

[00:04:36]
Well, have you asked them to pick up the slack? Have you grown them? Have you trained them? Have you kind of scaled yourself? You gotta be good at that, mentoring, coaching. Is the team meshing or are they a bunch of introverts who never talk to each other? Hiring, you gotta hire people.

[00:04:58]
But you don't just go on the street and hire the right person. You have to be good at recruiting too. You have to be good at selling the role. There's a lot on the people side too, a lot of skills you have to get good at. The business side, these just some aspects, but you have to be good at budgeting.

[00:05:16]
There's not a giant pool of money you just shovel and give to people. It doesn't work that way. There's a budget. You decide what's the priority, what's not. Project management, you gotta know when to step in and be like, I'm gonna lead this project, when to delegate that out, what projects are important.

[00:05:31]
The long-term strategy, my favorite analogy for long-term strategy is you're walking down the road, where are you gonna end up? You're gonna end up somewhere. It doesn't matter if you have a plan or not. You're gonna end up somewhere. There's nothing you can do about that, but you can alter where you end up.

[00:05:49]
That's how I think about strategy and vision. It's like setting that for a team, yeah.
>> Like you said earlier, you go where you point yourself and that applies similarly to business.
>> Yeah, exactly right, and someone has to do that, someone with the, what do you say about career ladders?

[00:06:04]
The perspective of doing that, and that's hard to do as a software engineer often. But you know how my strategy is formed by my team? I ask them, I talk to them, and I share my perspective. And then I aggregate all these opinions together and say, here's what I think we should do.

[00:06:19]
What do you all think? But someone has to do that. And that's part of the business and it has to mesh with the business too. It's not just, I'm really into WebSockets and WebAssembly. Let's figure out a way to do that. I would love to do that. But that's for the business?

[00:06:35]
Maybe, maybe not, I don't know. Actually, I do know [LAUGH] but that's something you have to figure out. You have the technical side. This one is really hard. Quick show of hands, what percentage, or actually what percent of time do you spend reading versus writing code, do you think?

[00:06:57]
>> Like 20%.
>> On the?
>> On reading versus writing.
>> Wow, that's a pretty high ratio, actually. I'm surprised, pretty good.
>> I've got a lot of pull requests. [LAUGH]
>> That's true. You do maintain a really popular open source package. What percent of time do you spend reading versus writing code?

[00:07:16]
>> Outside of pull requests or?
>> In general.
>> In general. Maybe 60% reading, 40% writing.
>> Yeah, that's pretty about right. The truth is for most people, you spend more time reading code than you do writing it. We don't focus on that, though, as software engineers. We focus on our own personal achievements.

[00:07:42]
But most systems you're working on are not new. You're not building things from the ground up. You're using other people's code. So take whatever percentage you spend reading versus writing code. Now imagine that's 100% reading code. And then imagine you're not reading code, you're just reading cliff notes of the code.

[00:08:01]
And that's what you have to do as an engineering manager. It's like you still have to understand what's going on without actually writing code. And that is an entirely different skill of software engineering that you need to be good at. You have to understand what your team is talking about.

[00:08:13]
You have to be able to make technical decisions or at least ask the right questions without actually writing code. I don't know, it's like a video game where you're like next level, you're a code writer, you're really good at it. Next level, you don't write any code at all, but you've still gotta get to the end of the level and that's how it is.

[00:08:30]
And you have to be able to explain the nuances often to people either above you or partners and things like that. And again, without writing the code yourself, this is a difficult skill to pick up, but you have to be good at it. Yeah.
>> Is domain knowledge kinda one that spans maybe all four of your points here of it's really important to understand the goal, the business, and the domain so your team can execute that technically?

[00:09:00]
>> Yeah.
>> How that plays a role, is that a big part of the business and the technical side?
>> I'd love that point, yeah, the domain. What does your company do? What's your role in that? We have an exercise on that a little bit later. So I'm glad you brought it up.

[00:09:16]
But yeah, you got to understand, what exactly do you do? That's a question I never actually thought to ask myself until really late in my career. And that spans technical in business and it's applying the domain on the technical side to achieve business outcomes. That's if you wanted to sell it down, great point.

[00:09:36]
Question.
>> Yeah, there's a comment from chat. When I read pull requests, it's more from the approach of are my engineers catching things? Are they writing comments? Are they providing valuable feedback? Is this PR process effective?
>> I like that. That is what your your role ends up bubbling up is looking at the proceeds of the team.

[00:10:02]
Like me, I don't read pull requests. Why? I'm not technical enough to contribute. My team are all much better engineers. I say it all the time, I'm the worst software engineer on the team. So if you explain things to me, you explain it in the way that I just don't know what I'm talking about.

[00:10:17]
I do to some aspects, but me being in a pull request is not helpful. If I'm like, hey, there's a bug here, why aren't there tests? That's a sign that we need better processes, not that I should be stepping in, cuz that's just not efficient use of my time.

[00:10:34]
Yeah, question?
>> Yeah, question, if you're an engineering manager who just joined a fully remote company, what would you do to engage people? Would you follow? I don't know what, yeah, what would you do to engage people?
>> Yeah, look at one, where's the code located? Where are the code bases?

[00:10:54]
Are there multiple repos? Is it just one? Following along with pull requests is good, good use of your time just to read. I don't mean interject into them. Don't make comments. Just okay, generally here's how people are working. Some people like really large pull requests. Some people like really atomic pieces of work.

[00:11:14]
People work differently. It's very surprising about software engineering is how that shows up and how they code. The other one is and this is a secret, ask everybody on the team the same questions in your one on ones cuz they don't know. You don't know what goes on other people's one on ones, ask them same question.

[00:11:33]
What's the vision for the team? What's our long-term strategy? What are our priorities for next year, next quarter? Ask everybody that. If they have different answers, that's something you should solve pretty quickly, or at least figure it out. If they'll have a good answer, step back. You're lucky, they're flowing, they're grooving, don't interfere.

[00:11:52]
But definitely, getting involved in the technical side, just understanding the core technologies. If there's, I don't know, it's a new library, new framework, say you're using React and they're all using Angular. Maybe take a course in Angular, so you at least know what you're talking about. You can contribute some of those technical decisions.

[00:12:15]
So we talked to these skills you have to build up. There's different ways of doing it, and being a manager means you're immediately gonna have to build up your skills, but you can do it ahead of time and make your life easier. So one way of doing that, talk to your manager about your goals.

[00:12:30]
And this is true at any level of if you're a software engineer or manager or director, whatever. Talk to your manager about what you want. Again, it's like we're saying you're gonna end up somewhere in a direction. It's better to help tell people, here's where I'm headed. Can you help me along the way?

[00:12:46]
And your manager can help you find work, ideally, that kind of builds up the skills and builds up that work towards your goals. Talk to other managers, learn from them. I learn from Ryan almost every time he talks about people leadership, one of the best people leaders that I've ever met.

[00:13:04]
I learn from him all the time. But you got to talk to other managers cuz they will have either similar experience or different, but there's something there that you can just pick up, and maybe a mistake that you don't need to make. Then ask your manager or other managers on how to move to management.

[00:13:20]
I did that. I had a lot of one on ones with people, with friends I've built up over the years. Look, hey, how did you move to management? What are the things you wish you knew? And you will learn a lot there a lot faster than trying to just blindly apply, throw your resume out there.

[00:13:37]
Books are useful again, but pick the right ones. I've read some bad management books or ones I didn't agree with my personal philosophy. But I still learned something there, just people approach problems differently. This one's controversial. Everybody's like, Jem, you got to read The First 90 Days. Have you read that, heard of that book?

[00:13:54]
I did not agree with that book. I don't like the style. To me, it's too focused on self and your own personal success rather than building people up around you. But that's just my opinion. So even this course, you may not agree with everything I'm saying. That's totally okay too.

[00:14:11]
But it's good to educate yourself. Conferences are another good one. You know that there's conferences for managers. Did you know that? You probably didn't even think about that. What managers at conferences? There are. Those are really helpful places to learn. Observation is one of the most powerful tools that you have.

[00:14:30]
How does your manager behave? How do they show up? The managers that you like, you're always like, yeah, they're cool. I like the way they show up in meetings, even if they're not your own team. What can you learn from them? You just watch them and see. How do they deal with those kind of spicy questions that people like to throw at them?

[00:14:49]
How do they reflect on things? You can learn a lot by just watching how someone behaves. Becoming a mentor or getting a mentor is a great way of doing it. Mentoring itself is a great way of building up these management skills, mentoring junior managers, mentoring senior managers, or sorry, not managers, mentoring junior engineers and senior engineers.

[00:15:14]
Different skills required, different things they need. You will build up a lot of people skills, learning how to mentor cuz you'll hear the problems that they have. And those problems you'll just see repeated over and over again. And then the last one is take on proximate roles. Team lead is a good way to start building up the skills.

[00:15:33]
Even becoming a staff engineer and thinking about more of the business is a good way of building up skills. There's a lot of roles that are, some aspects of engineering leadership that you might be able to pick up.
>> How do you ask for or how do you know when to ask for mentorship yourself?

[00:15:51]
Cuz you're saying asking managers for tips but then that becomes its own skill, right, how to especially dealing with managers that well, micromanage, for example. [LAUGH]
>> Yeah, the reason I say mentor, and that's different from a manager, is a mentor is someone who is not directly, hopefully, in your chain of management, or even a partner.

[00:16:20]
You want them to be divorced from your day-to-day problems. So you have to explain things in a way that they don't, from the perspective of they don't know what you're talking about. And they could take things objectively, versus your manager is gonna be, or take things subjectively. Your manager is gonna be very objective.

[00:16:36]
Hey, if you're like, hey, I'm not happy with my manager, [LAUGH] tell your manager that. They're probably gonna take some offense to that. It's not helpful but if I want to, say, mentor at a different company who doesn't know my manager at all and I can only describe the ways they're behaving.

[00:16:51]
One, that forces me to communicate better, and two, there's someone who's invested in you and not the business side. And that's kind of the distinction between a manager and a mentor in this scenario.
>> You mentioned that being an engineering manager is quite lonely compared to being an independent contributor.

[00:17:09]
Are there any communities or meetups or Slack groups that you'd recommend?
>> I don't know of any Slack groups per se. Brian, you're nodding your head, you know a few?
>> Yeah, there's a couple of good ones. There's engineering management. I believe there's literally that's what it's called.

[00:17:26]
But my favorite one is Rands Leadership. It's engineering leaders from Slack, a couple other companies. He runs a whole Slack group. It's definitely one to check out. I think that's a very useful tool.
>> Wasn't there a conference you spoke at, Jem?
>> Yeah, LeadDev is a great conference for managers.

[00:17:46]
It's not just for managers, it's for managers and team leads and people who exist in the staff-plus kind of world, really helpful conference. Totally different styles of leadership you see represented there, and it pushes my thinking. I'm like, I've been thinking about how to solve this problem one way and here's a completely different solution to it.

[00:18:06]
So there are a few. There's not nearly as many as there are for tech or specific tech, but they're out there.
>> That's managing conflict or managing brilliant jerks.
>> [LAUGH]
>> [LAUGH]
>> I'll talk a little about it. Ryan touches on this in 102 on managing conflicts.

[00:18:27]
He has a few scenarios he's gonna work there. And later today, we have an interview question on that very same. But the easiest way on brilliant jerks, don't hire them. I'm laughing, but it's true. Just don't involve them. It's not worth the output you may get from them, from one person pulling down an entire team, an entire org, being toxic to work with.

[00:18:51]
It's one of those, you just cut it off. And so if they exist, you have a conversation with them. But you have a conversation with others cuz a lot of people won't see it, but they're so good. Their output is so high. And it's like, well, there's more things I value, we value as a company than just having high output.

[00:19:07]
So managing conflicts, I'll definitely let Ryan handle that one. But in general, be curious. Don't come in with an opinion in mind. Don't come in with a solution already in hand before you've heard what people have to say. People will respect you a lot more if you ask a lot of questions and don't do anything than if you come in like, here's what we're gonna do, I'm gonna be a strong leader.

[00:19:29]
I'm gonna be authoritative here. And I've definitely done that, and it's a mistake I've made probably too many times of trying to come in with a solution rather than being curious. But yeah, we're definitely gonna dig in more on the conflict side.