Check out a free preview of the full Engineering Management Fundamentals 101 course

The "Wrapping Up" Lesson is part of the full, Engineering Management Fundamentals 101 course featured in this preview video. Here's what you'd learn in this lesson:

Jem discusses various topics related to engineering management. He covers responsibilities shared between engineering managers and product managers, the ideal size for meetings, how to avoid micromanaging when individuals are underperforming, the frequency of one-on-one meetings with team members, setting a good example as a manager, and the key takeaways from the course. The lesson emphasizes the importance of effective communication, continuous learning, and the fulfillment that comes from being a manager.


Transcript from the "Wrapping Up" Lesson

>> Which responsibilities do EMs share with the product manager?
>> Good question. The overall delivery is shared. Product manager is an interesting one. I don't know if we have a course on. I think we actually do have a course on product management from Brian Holt. But that's another one where you don't directly do anything as a product manager, except you corral people.

But you're both responsible for the successful delivery of your projects. So I'd say those are responsibilities. Yours are generally gonna be status updates, keeping the project manager informed so that they can make decisions and see the overall picture.
>> What's a effective meeting size? Is it five to six people, or is there no such limit, but just all interested parties should go.

>> That's a great question. It depends on the purpose of the meeting. A brain summary meeting with 100 people is not gonna be effective, it doesn't matter how you slice it. There's a certain size where everybody weighing in just isn't gonna get you anywhere, you're never gonna reach consensus.

I don't have a good number in my head, but I think you know it. [LAUGH] When you see it, if you see 20 people in a room versus 5 people. The less people there are the easier, it will be to reach a decision.
>> How do you avoid micromanaging when individuals are underperforming, and you can't figure out why?

For example, items are estimated at an excessive amount of time, and they take even longer, and then shouldn't take that long to begin with. One, I'll lean on what Ryan said is, be curious, find out what's going on and dive in. Is that a personal issue, is it's a skill gap they're missing?

Project estimation is a skill that you have to build up over time. Maybe there, there's something you can do their training or just sometimes you'd be more hands on. But I'd say the other side of that is being curious and finding what's going on is set expectations and make sure that you agree on it.

It's an agreement between the two of you say, hey, you know, you've been missing all of your deadlines. You say something's gonna take two weeks and it's taking a month. It's slowing a lot of other people down. How about we have some expectations on, you can pad out things, just say it'll take three weeks instead, but I expect you to deliver that on time, and we have this agreement.

And if they don't meet that, then you have to escalate that into like, hey, here's what we talked about, and you agreed to it, I agreed to it, we agreed it's fair. It isn't working out, so now we need to have a unique way to deliver this and be more specific.

We didn't go that deep into it because that's more deeper into management, but there's a time when you have to be firm and have clear expectations. Yeah, the question first.
>> How often do you do one-on-ones with the people that you're managing?
>> I give my team the choice.

Max you wanna go is two weeks, so most people are bi-weekly. So it's every two weeks, I have a 30-minute one-on-one with them. My team meetings are an hour, once a week. But there are people on my team who prefer longer or more frequent. I meet with them weekly.

It's totally up to them, and kind of how much they're getting out of it. Sometimes you find out you have a regular one-on-one, and you're like, you know, we're just talking about movies or something like that. As much as I love doing that, let's give each other the time back.

>> I was just gonna echo, like you said, that planning and estimating is a skill. One of the teams that I work with that actually, John managed previously, we've had a lot of success doing planning poker. So whoever asked that question about estimating, planning poker seems to drive a lot of healthy discussion where you say, it's a 13 but everyone around you says it was a 2.

>> [LAUGH]
>> Let's talk about why those estimates are so out of whack and just have an open conversation. And if it happens week after week or sprint after sprint then maybe in a one-on-one you can follow up with them and say, you're always well higher than your colleagues.

Is it then you can dig into some of those underlying issues, as you mentioned?
>> Yeah, I've heard of planning poker, never done it, but I like your approach with curiosity too. If someone's off, I found taking in if someone's estimations are way off, it turns out they're like, we keep shipping a lot of bugs, and I like to add in that extra time to write tests and bugs, and the rest of the team is not writing tests, actually.

Or it takes so long, and it's so painful to write tests, but they're necessary, and you're like, it actually turns out we need a QA engineer. Because a lot of my team is spending time writing tests, and that's why our estimations are always way off. But that you only get that when you dig in and be curious rather than, why aren't you delivering on time?

You said you're gonna do this. You didn't do that. It's just not a healthy approach.
>> So today's a Thursday. Did you interact with your team today while you're out, or how did you take the day off or?
>> I'm out of office. I try to set a good example.

People slack me, I just ignore them, because I said in there, I'm out of office. You wanna set a good example? I don't like to say I'm out, and I'm still responding to emails later in the day because whether I like it or not, I have to be better about it.

And I don't want my team to feel like, hey, I'm on vacation in Hawaii, but Jim just messaged me, so I need to respond immediately, because I'm setting a tone for the team. So I try not to respond when I'm out of office unless it's an emergency. I don't send emails late at night, right?

Again it sets a bad tone. I try not to put comments and documents late at night. Even if I am in there, I'll just save them for the next day because I don't wanna set a bad example for my team. Yeah, if I choose to work late, that's fine, but I don't need visibility into doing that.

Yeah. So at the end of this course, we've now reached the end. Let's talk about the course takeaways. One, what do we learn? Software engineering is more than code. Remember that giant list of people that contribute to your product you may or may not have thought of until now, there's a lot more to software engineering than just the code.

In software engineering is the management, is a role change. It doesn't mean more control. It doesn't mean more money. You do have greater impacts, but it's just a different role on your team. Not more, not less. There's a lot of ways to get into management, some are easier than others.

We found out the accidental path is probably one of the more common ones, but that doesn't mean it changes how you think about management. At the end of the day, responsibilities are the same. But you have to have the right motivations if you're gonna stay a manager. It's really important because again, management is very lonely.

And you have to dig deep internally and figure out what's important, because there's no one there to help you. They just can't at the end of the day. And we live in an engineering management, it's difficult. There's a lot of things you're juggling all the time, and no one can tell you which ball is heavier.

Sometimes they come down, and they're a little bit heavier, when did that happen? I need to put this one down, or I need to pick these up, and actually do need to do a lot right now. It's a really tricky job balancing all these things and the people who change every single day every single week.

You need a lot of skills to be a good leader. But more importantly, you will not be good at all of them, and that's okay. Don't beat yourself up about it, but at least try to do something, try to fix it, try to learn to paper over some of the things you're not as strong at.

And build up your skills in advance if you're not a manager yet. It will make the transition easier. We talked about a lot of the deficiencies around communication, those are things you can work on today actively, and you'll just be better out. It'd be more comfortable where that chart of conscious of competency, going from unconsciously incompetent to consciously, unconsciously competent, that's where you wanna be.

But the only way to do that is exercise, you have to try and keep working towards it. And take advantage of opportunities when it comes to transitioning from manager to not. If something pops up, and it's perfect for you, go after it, go after it then. If you wait until, well, I'm not quite ready, you'll never be ready.

Sometimes, you just got to go for it because the fact is, you don't know. You won't know until you do it. If you wait until I'm ready, it'll never happen. And then the interview is a measure of potential. Treat it that way. But come in as you are a manager, but understand you're probably gonna be wrong about a lot of things.

Your perspective's gonna be incorrect, and that's okay. Don't try to have the perfect answer. Just share your philosophies. And in the end, management is when you're good at something, it is very difficult. And when you do it, it's so powerful. It's so fulfilling, and it's really hard to talk about.

It's hard to describe until you do it, but think about the last thing, think about something right now that you found a lot of pride in doing, that you've accomplished. Take a second. And whatever that thing is, was it easy to do? No. Sometimes, the harder something is, the more satisfaction we get from it.

And that's like a weird, perverse relationship we have as humans, if we don't enjoy the easy stuff because it's too easy, and that's a lot of management. It is difficult, but when you get it right and the team's functioning, you're delivering, people are happy and growing, it is a very satisfying job.

And obviously, besides being a parent, it's the most satisfying thing I've ever done, and I get a lot of joy from it. You do get a lot of joy, but you have to look for it. It doesn't come to you, and it doesn't come easy. It's not cheap.

But it's there, and you talk to someone who's been a manager for a long time, asking why they do it, and you'll get happiness. At the end of the day, when you see people grow, and you build them up, the question at the end of the day is you're like, did I actually do anything?

They're all good people, and did I actually impact that? And you'll always ask yourself that. And you can only look back and see like, I did do something. I did impact the team for better. They are better. I'm not that bad manager, they see people talk about, hopefully not.

But it is such a great and rewarding job. If you can master these skills, if you accept that things are gonna change, you're gonna learn a lot. It's the end of the course, it's a long day, but thank you so much. If I didn't dissuade you from management.

I didn't do my job right, I'm kidding. But if nothing else, hopefully if you say, you know what, management's not for me, totally fine. But hopefully, now you understand the perspective that your manager has, and you can become a better software engineer, and better at the business, and you can move up the other side of the ladder as well by knowing all these things.

Thank you. [APPLAUSE]

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now