Enterprise Engineering Management 102

Building a High-Performing Team

Enterprise Engineering Management 102

Check out a free preview of the full Enterprise Engineering Management 102 course

The "Building a High-Performing Team" Lesson is part of the full, Enterprise Engineering Management 102 course featured in this preview video. Here's what you'd learn in this lesson:

Ryan discusses the importance of building and maintaining a high-performing team, and defining a high-performance team as one that exceeds expectations, delivers work efficiently, satisfies customers/stakeholders, and has a positive impact on the business. He also addresses the need for continuous improvement, consistency, and open communication within the team. The lesson concludes with insights on how to address team struggles and give feedback to team members who need to improve in certain technical areas.


Transcript from the "Building a High-Performing Team" Lesson

>> Now, we talked about hiring, that's absolutely a form of building a high-performing team, but I think building and maintaining a high-performing team is just an ongoing thing. Even if you're a new manager taking over a new team, whatever it looks like, there's existing people there. Or even if you've hired those folks, there's existing people and there's things that you can do to help build a high performing team.

So let's start by what does a high-performance team mean? And to me, it's like your team is exceeding expectations. I mean, at least you're meeting them, that should be a bare minimum. But hopefully, you're really impressing people. You're like, that team is dependable. They're doing the work and delivering.

You have some sort of high degree of efficiency. So that can show up in many ways. But I think of even just effectively, I hate using the word resources, even though I have it on the slide. But you're effectively using the engineers on your team and that they're doing the right things for the job, and sometimes that can change.

We talked about the charter and things evolving over time. Maybe your team, they have some deep level expertise in GraphQL and you stopped using that. Maybe it's like that person should shift to another team or things like that I think about, and that you're effectively using what's there for you and you're thinking about, do I have the right people for the job that we have at hand?

Your customers/stakeholders are satisfied. They're happy, and how do you know that? Well, ask them, how's my team showing up? Are we collaborating well? Are we meeting your expectations? What could be better? And that's where I think that as a manager, those are the types of things that yeah, absolute, my team can do that.

But I'm gonna be meeting with the partners as well, and just checking, getting a pulse on that. What's not working? How can we do better? That helps me, and I can work with my team. Maybe I disagree, too. It's like, well, that's actually not part of our charter to do that.

So I can also clarify with the partner that you actually have the wrong expectations. Hopefully, your leadership team above you values the output from your team. And those should be ongoing conversations as well. I hope that if there's problems, your leader's telling you, but if they're not, or you wanna know, ask.

Make sure you're asking those questions and making sure there's alignment there. Your team should be having impact on the business, right? At the end of the day, we're paid to do a job for a reason, and there's outcomes. It varies and shows up in different ways, but you wanna make sure that you're doing the right things and having impact on the business.

Now, you'll make mistakes. Let's not forget, that's a good thing. You can evolve and learn from those mistakes. And I don't think anyone's gonna fault you for that, but you ultimately do wanna be delivering something for the business. And this kinda gets to that making mistakes. I'm a big believer in continuous improvement.

It's like, yeah, own those mistakes, what could be better? This worked, but what would we do different? I'm a fan, I don't know, anyone do retrospectives in their companies? Yeah, that's good. You don't have to do them just cuz there was a problem. Sometimes my favorite question is, what's working?

And just continuing that. But evolving the processes that you use and saying like, wow, yeah, we spent way too much time on stand ups. Next time let's not do that, let's try something different. So you wanna continuously improve and try something different and figure out what works best.

This is a good one, too, that I often kinda maybe don't think about, but it's, how does your team show up? Are they being consistent? Are you being consistent? So, people, partners, other people in the company know what to expect of you and your team, that goes a long way for building trust.

They know how to operate with you. I mean, I guess you could show up poorly and be consistent on it too. Hopefully, you can change that but people know what they get, and that is absolutely an important factor. So those are kinda some of the things I've been thinking about as a recap on high-performing teams.

What else? What have I missed? You all have suggestions.
>> One of mine is, how often do I have to step in for, I think, smaller decisions? And how often do our problems getting solved without me even knowing about them is a really good strong indicator the team is functioning well.

Where I just get feedback from somebody who was was like, hey, someone on your team solved this thing. I was like, that was a problem? I didn't even heard about it. And that's that's where I like to operate at, is they're just doing that cuz they know how to do it without me.

>> That is the best kinda problem, I love those and they just get solved. And you're, yeah, this is great. And then that's a good point for you to make sure you're giving positive reinforcement on, yeah, that's exactly what I wanna see on this team. Any other suggestions?

>> What this raises in my mind is when you're having a team that is struggling and you're in this constant cycle of you're trying to add features and solve problems but bugs come up. And then it's just a cycle of you're trying to fix them, cause more bugs kind of thing.

And what I'm curious about, I guess, and maybe you'll go into this. But how to fix that cycle. How to try to get to be high-performing when you're not.
>> Yes, I love that question. I've totally been in that case, too. And you need to take a step back and evaluate.

Maybe your team is trying to do too many things. That could be it. It may be that you need to actually pause on some stuff too, and that can be hard to have those conversations, too. Especially, if you're working with a product management team who's expecting certain things, you've got to put an end to this cycle, right?

And so it might take taking a step back and going, we don't have the right processes in place. We haven't paid tech debt down, and there's ways in which you can quickly change those behaviors, but you have to be very explicit. So, let's say I had an application that had no tests at all.

That's happened, right? And that's not great, we're probably shipping and there's a lot of bugs that are happening and that might be a solve to fix the quality that's going out. But how do you write tests when you're constantly trying to keep up or maybe for new features able to write more tests, but you still need to go back to the baseline.

So I'll set aside time. And it may mean that my team moves slower. For the next quarter, we're going back and we're writing tests, that's what we're doing. I'm telling my team that, we're focusing on that. But I'm also communicating that to my partners, and they might be frustrated.

I wanna talk about it, let's have that conversation. Maybe we can't spend as much time on it. All right, let's talk about that. So I think about it now is that you kinda have to do something a little bit more drastic. You can't just expect that it's gonna change.

>> And kinda related to that. How would you tell a person or a member of the team that they need to improve in some technical area?
>> It's a good one, we do get into some feedback later in the sections. But I think being honest with someone, too.

If I'm talking to an individual on my team, I'm gonna say, like, I'm a little worried about you not having this technical skill. How do you feel about that? Do you feel the same? Are you struggling in this area? And then the two of us can work through that.

Maybe it's that I need to help, maybe I put them in the wrong project, too, right? That's not something that they're passionate about or it is the skills aren't aligned, that could be it. Maybe it's they're like, I do need a little more depth in this area. So maybe I can help pair them up with someone else on the team or someone else in the company.

Maybe there's going to courses on something like Frontend Masters, that might help them. So it's things like that that you just think creatively and trying to how to solve that is what I would approach. Question.
>> I was just gonna say, on teams I've been on, if you have a great structure, the team just cares.

I think it's really simple, if they care about the work and they care about the product, a lot of things fall into line.
>> Yeah, passion, and they're really bought into what you're doing, right, and excited about it. That can go a long way. I think about that, even if everyone on my team is like, I love what we do as a team.

There's certain projects that speak to them even more. Lean into that, right? Everyone works on exactly what they wanna work on. But as a manager, you might be thinking about that as like, yeah, you would like that type of project. I'm gonna keep an eye open for that kinda project coming up.

And that definitely keeps people happy and more driven on that work. That's a good call out.
>> Ryan, if if your team's consistently performing, how do you know when to adjust processes? Cuz you don't wanna mess up their flow but you're always like, things be optimized. So how do you strike that balance?

>> That's a good question. Yeah, don't fix what's not broken, right? It's working. I think it is recognizing maybe it's from those retrospectives where there's, everything's so good. Okay, cool, but maybe there was something that we could have done a little bit better. And so maybe you as the leader taking a step back and saying, what could be better and just maybe optimizing or making small adjustments or suggestions.

Or even just asking the team, too, for suggestions on that. But I don't think you need to take a full swing, like I said, where you're having to pay down tech debt or something, where you're like, we actually need to pause on some things or cut scope in an area to really go deep on it.

It might just be trying some incremental improvements just to constantly get a little bit better. I don't think anyone's perfect, right? And so it's, how do you adjust? But you don't need the pendulum to swing too far the other way. And maybe you do, and you accidentally do that, and you're like, it was actually better the way we had it before.

That happens, and that's okay. You've actually learned something, that it was working better before and stick with it. It can be painful if you're constantly doing that to your team, but I think if you can try different things and evaluate, you're gonna get better and better for it.

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