How to kill a talent?

It takes many years to grow a talent with several skills. Yet there are ways to kill that in a short time. You can very likely achieve it by applying even just some of the methods below. Here we go:

Set blurred expectations

One of the most efficient ways to kill a talent is not setting the expectations clearly. Why then? Well, it is their responsibility to find them out. A developer should always be clear about what is expected from them by default.

1-on-1s are time consuming

We already have a lot of things to do in our daily work. There are tickets to implement, important crowded meetings to organize and a product to deliver. Why to lose time over 1-on-1 meetings? Everybody is doing fine and there is no need to separate time for something already working well. If a talent would have a problem, they would come to you anyway. If they do not speak out, that should absolutely mean all is good! No need to have useless meetings.

Giving feedback  = Shooting people

Give negative feedback in front of many people! That way, they won't easily forget and this will prevent them from doing their mistakes in the future again. And absolutely, you do not need to give any positive feedback. Whatever they do well and achieve is already their duty, of course they must do that.

Another opportunity for giving feedback is called "passive aggressive style". i.e. When you figure out a commit that created a bug, give praise openly by saying "Wow, that is really a very good job!"

Sending a long formal letter for feedback giving is yet another effective way. Text is a great! method to explain the negative points and give you the opportunity to keep away from simultaneous questions which can make things easier.

You are the best, no need to receive feedback

You know it best, you don't have to care about what others are saying. Anyway, they are wrong but you are right. When somebody tries to give you feedback, tell them that it is irrelevant and wrong, save some time.

Do not give credits

When talking about achievements, no need to talk about how good the team work is. Giving credits to team members that brought the idea, drove the implementation or delivered the solution is not necessary at all.  Getting into details! especially right at this point is boring and even just mentioning their names is time consuming.

One idea is enough

Diversity of ideas is just consuming time from the team. A single solution is enough and we do not need to discuss alternatives to improve our system, product or methodologies. You were right a couple of times in the past and you will of course always be right in the future as well.

Interrupt them constantly when speaking

When people try to speak their mind, just jump into talking before they even finish their sentence! You know before what they're gonna say anyway, no need to give them the space for efficiency reasons, save time.

Monitor closely

All developers need very close monitoring all the time. Ask them how the ticket is going every hour and make them feel how you work closely with them. This will create the motivation and help them finish the ticket ASAP. Tell them exactly what to do because you know the solution already. They do not need to think about it, you know better anyway.

No need for onboarding

A developer should figure out EVERYTHING on their own. Separating time for onboarding is useless and consumes time from people.

Tickets with no description

Tickets with a little information, no definition of done and no acceptance criteria are short and simple! Tell them test everything etc. In the end, they have to know it by default or figure it out.

Summary

In this post, I tried to highlight the anti patterns of leading a team that we should avoid. Otherwise it can cost up to low performance teams, losing team members and even more.

I hope the methods above sounded like a joke for you instead of an experience, but I can imagine that you may unfortunately have experienced some of them. If you wonder what I believe as the right approach instead, please check out my blog:

Creating High Performance Teams

Attribution

Cover Photo by Anna Shvets from Pexels