Communication for team leaders - Trust

The second part of a three-part"Communication for Team Leaders". This one is about trust, letting go and delegating. I think it’s the hardest one for new managers.

You can find the first post here: https://frederickvanbrabant.com/blog/2024-10-11-communication-for-team-leaders-context/

These posts are based on a part of my talk, “I just became a team lead, now what” (https://www.youtube.com/watch?v=oWtSbTded0o).

Letting go is the hardest part

You don’t always realize it, but when you transition into a leadership role you are expected to (at least partly) move away from the operational stuff and into the more long-term/bigger picture stuff. Normally, someone who’s managing a team can’t keep doing the same type of work as the team that person belonged to. Leading a team comes with a lot of extra work (staffing, more meetings, coaching, …) and there are only 24 hours in a day. Yet this is in reality a big challenge. How do you find a good balance between delegating everything and working yourself into burnout by trying to do everything yourself?

There is also the topic of micromanaging and on the other hand expectation management. You don’t want to use the person you’re offloading work to as an extension of your mouse but at the same time, you want to make good on the quality of the work you promised to the powers that be.

How I choose what to take on and what to delegate

Let’s try and tackle that first part; what to take on and what to delegate.

Chances are that you are pretty good at what you do. Otherwise, you wouldn’t have been promoted to manager ¹. Some might even be the best at what you do among your previous peers. That also means that if a new task comes in for the team, you would be a prime candidate to take it on. After all, it’s been this way for you for a long time now. You’re proud of the skills you developed and it produces great results, why stop now?

That line of thinking makes this entire thing so hard. It also makes it a straight road to burnout city.

It is not a bad idea to have a connection with the work that needs to be done, but that connection needs to be sensible. Be involved in the kickoff meeting, maybe be involved in the handoff, check in during demo’s, … ² But don’t try and follow up on everything.

I’m also not saying that you shouldn’t take on anything. Especially if your team is a bit smaller and not too spread over different disciplines. As said before, you are probably pretty good at what you do so you can take off some work for yourself. You can keep your skills sharp and at the same time see what your team is facing day in and day out. Sometimes we get a bit out of touch with the work if we only delegate, doing some tasks yourself can keep you grounded.

So how do you decide what to take on? Well, it’s not an exact study. The default should almost always be: Give it to someone in the team. In the case of doubt, I like to go over these:

What is the workload of the team?

This one should be fairly obvious. If the team is overwhelmed you jump in. Just be sure that you don’t create extra work for them. You have to take an honest look at yourself at this point: are you still enough in the game to keep up with the team when the team is at their highest speed? If not, you will only create more work for them. If the answer is no; try and find other ways to support the team like handle communication to other departments.

If you notice that this situation happens all the time it might be a good indicator to ask for additional people in your team or to look at why there is so much more work versus the amount of work you can provide.

What is your workload?

Well, don’t take on more work than you have room for. The obvious question that not a lot of people seem to ask themselves. The hard thing here is mainly saying no. I’ve met a lot of new managers that are people pleasers. Nothing bad about it. But learning to say no is a very important part of being a good manager.

Is this a learning project?

These are so hard to let go. You just got a project that requires a lot of research into something that you or nobody in the team has experience with. The reality is that you probably don’t have the time for full days of study and then fully commit to implementing the solution. Those days are gone. I would recommend being very involved in these projects: attend meetings, look at the diagrams/documentation (don’t study them) and speak with the team. But don’t fully take it on you.

This is a learning project for people in your team. It can also be used to make some eager people in your team happy that might be a bit burned out in doing the same task over and over again. Just make sure you give it to the right people. Not everyone likes this kind of work.

How to hand over the work

Getting a good head start

You’ve obviously read the previous post about Context so you know the value of context. So lead with this. If you hand over work try and make it a small kickoff meeting. That might seem like overkill but it helps to create a place to ask questions for the person that needs to do the work. In these meetings, you should cover:

• What we want to do
• Why we want to do it
• What the end state should be
• Who is impacted/involved
• What the timeframe is and if it’s fixed or not
• Who should be in the loop (RACI can help here)

Don’t forget to ask if they have questions and if everything is clear. Getting a good start will help the result.

Once the project has been going for a while it’s a good idea to have some checking moments along the way. This can be a water-cooler talk or a full-on meeting. That would depend on the scope and importance of the project.

Handling the results

Now what if they come back to you with something, you look at it, and it’s full of small mistakes? Here is another big pitfall. The reflex is often to point out that “it could use some work” and quickly do it yourself. This is the fastest option. Don’t go for the fastest option.

I’ve found that the best way is to sit together with the person go over the document and talk about what you expected versus what you got. This takes time and can be unpleasant but it will pay dividends in the future.

This feedback moment is a thinly disguised coaching moment. Next time that person has to do a similar job they know the points you pay extra value to and how you would tackle them.

If the next time they work on it it again comes back less than ideal, you have this moment again. Don’t lose your cool. Some people need more coaching than others. Also, make sure you give the same feedback as before. If you told the person in the first feedback session you want it X don’t be disappointed that they didn’t do Y the next time.

If bigger projects have been completed it’s always nice to have a lessons learned moment. It’s best to only do this for big projects, successful or not. Every project has something to teach, don’t only go over the failed ones.

The last thing I’d like to discuss is celebrating the wins. If a project fails there are angry emails and “how can we make sure this doesn’t happen again” meetings. If a project succeeds there is often nothing. Make sure to also congratulate the people if the project was a success. I’m not saying you should rent out a ballroom if someone sets up a small automatisation flow, but you can at least tell them they did a good job.