"That item is nearly done. I just need to run it past the team lead to make sure it's good to go."
Have you ever heard a phrase like that? What about something like this?
"So, I had that finished and then I ran it by the team lead and he made some great suggestions to make this more reusable. Unfortunately I'll basically have to rewrite the entire thing, but it should make it easier in the future."
Do you see anything wrong with either of these scenarios? What about this one?
"The team lead is out of town, so that item will have to wait until she gets back so she can look it over."
Situations like these come up every so often in development. There are some simple solutions to each of these. With the last one, the team lead should have designated someone to act in her stead while she was out. In the second one, the poor junior developer should have worked closer with the team lead from the start. The first one, though, isn't really an issue, right?
... Right?
Or is it?
Is there a bigger issue here that all of these have in common?
I'm suggesting that there is a common issue all of these situations (and many others) share and this issue is hurting your team. The issue is that the tech lead is a bottleneck.
Technical or Team Leaders are often told that they're responsible for everything the team produces. If they make good stuff, it's because of the tech lead. If they make bad stuff, it's because of the tech lead. While those perceptions can be true to a point, these thoughts often encourage a tech lead to want to see everything the team does. This may seem reasonable, but it's actually doing more harm than good.
Taking this mindset will slow the team down. Instead of a story needing to be accepted by someone in a business role that can represent the customer (eg. the Product Owner), a story will also need to be accepted by the tech lead. Instead of developers and QA feeling empowered to make decisions and do the right thing, they feel that they need to involve the tech lead in every step of the process and in everything they do. Instead of the tech lead enabling, training, and empowering the team so that the whole team performs at a higher level, the tech lead is stuck in a lot of meetings about the details of this or the ramifications of that while trying to micromanage everything the team has in play.
Hopefully you never encounter something as counterproductive as that last paragraph makes it seem. In reality, most teams aren't that bad but they still suffer from the bottleneck of poor technical leadership.
Have you ever heard a phrase like that? What about something like this?
"So, I had that finished and then I ran it by the team lead and he made some great suggestions to make this more reusable. Unfortunately I'll basically have to rewrite the entire thing, but it should make it easier in the future."
Do you see anything wrong with either of these scenarios? What about this one?
"The team lead is out of town, so that item will have to wait until she gets back so she can look it over."
Situations like these come up every so often in development. There are some simple solutions to each of these. With the last one, the team lead should have designated someone to act in her stead while she was out. In the second one, the poor junior developer should have worked closer with the team lead from the start. The first one, though, isn't really an issue, right?
... Right?
Or is it?
Is there a bigger issue here that all of these have in common?
I'm suggesting that there is a common issue all of these situations (and many others) share and this issue is hurting your team. The issue is that the tech lead is a bottleneck.
Technical or Team Leaders are often told that they're responsible for everything the team produces. If they make good stuff, it's because of the tech lead. If they make bad stuff, it's because of the tech lead. While those perceptions can be true to a point, these thoughts often encourage a tech lead to want to see everything the team does. This may seem reasonable, but it's actually doing more harm than good.
Taking this mindset will slow the team down. Instead of a story needing to be accepted by someone in a business role that can represent the customer (eg. the Product Owner), a story will also need to be accepted by the tech lead. Instead of developers and QA feeling empowered to make decisions and do the right thing, they feel that they need to involve the tech lead in every step of the process and in everything they do. Instead of the tech lead enabling, training, and empowering the team so that the whole team performs at a higher level, the tech lead is stuck in a lot of meetings about the details of this or the ramifications of that while trying to micromanage everything the team has in play.
Hopefully you never encounter something as counterproductive as that last paragraph makes it seem. In reality, most teams aren't that bad but they still suffer from the bottleneck of poor technical leadership.
Avoiding this Pitfall
So, what can be done to avoid this pitfall? How can the technical lead not make himself or herself a bottleneck? Here are a few ideas.1. Trust your team
If you take a moment to look around yourself, you've probably noticed that you work with some incredible people. Sure there are outliers, but there are a lot of people that are incredibly smart that you work with. Some of them may be on your team. Regardless of where these people are, the people on your team have the potential to be those individuals if you let them. So, trust them. Let them design something without your input and see what they come up with. Let them voice their opinions first in a meeting. As a leader, take a back seat for a few meetings and see what the team comes up with. You'd be surprised at some of the brilliance they show.
2. Empower your team
This is very related to trusting your team. Along with trusting them, you should empower them to make decisions and to do what they think is right. While doing this, you might also encourage them to seek second opinions before implementing something, especially if they're unsure or doubting in any way. The truth is that your coworkers are professionals just like you are. Maybe you have more experience than they do, but each of them also has unique experience and knowledge to draw from. By stifling them until they get more experience, you're not only hurting their performance, but the performance of the team as a whole.
3. Train your team
As you put more trust in your team and try to empower them, there will likely be times that you doubt they can do what they need to. In these situations, resist the urge to tighten things up again and bring more things under your control. Instead, take a minute to identify why you feel this way and if there's something you can teach the team that will enable them to do what they need to. The more you can train the team and turn them into leaders in their own right, the more effective your team will be and the less of a bottleneck you'll become.
Conclusion
As you build your trust in your team, empower them, and train them, you'll slowly start to notice the dynamic of the team changing. You'll see hard problems solved with elegant solutions. You'll see people you doubted before stepping up and taking responsibilities you never would have thought they'd enjoy or even want to do. You may even start to feel that the team doesn't need you. While that may seem true at times, it's not. Even if it were true, it's actually a good thing. That means you've done your job very well. You have a very high performing team now and you can all focus on getting the work done. In addition to that, your leaders will likely notice the changes in your team and your efforts in bringing those changes about.
So, next time you want to have someone run something past you or next time someone says they need you to sign off on something, take a minute to think of how you can change it. What training can you provide? How can you lead this person or the team so that you're no longer a bottleneck for the team? As you do this, the whole team will slowly perform better over time.
I remember trying to code review everything a few years back. I learned quick it wasn't going to work out! :)
ReplyDeleteYour post has lots of good points I think many tech leads have to learn after trying to approve everything.