Is that what you really want?

This is a very simple thought once you figure it out, but it appears that most team leaders and managers didn’t figure it out yet. So, I’ll write explicitly and hope that some of these people out there will read it here.

In order to achieve a goal through team work[1], the manager, or whoever is responsible for that, has to make his team understand three things: what exactly they are supposed to do, why they have to do it and what is the unacceptable result or, in other words, what they can’t do.

It’s really simple, but I only realized that this is an universal truth one year ago when my first agile attempt failed. After that, I spent a lot of time thinking why it went out that way. My first thought was that my team really sucked and because of that they were unable to do what I expected them to do. But after some time I realized that my team was very good technically and that the problem was my failure to properly communicate with them. I was unable to communicate them these three simple pieces of information.

Since that, every time I need to lead people, I try my best to make sure that they really understand what’s going on. Because if they don’t, the best result I can expect is that they’ll follow my instructions as a monkey will do and, hopefully, I’ll get the job done. I don’t want that. I don’t want to hope for something. I want to be sure that, at least,  I’ll have the best that these people can offer and don’t have to review their stuff all the time to make sure they got it right.

In this whole last year, I gathered some thoughts from my experiences on how to communicate these simple pieces of information and here is what I came with:

• Explain how it’s going down, present the context – Before any movement, present the general idea of the project[2] to everyone that’s involved in it. Don’t simply tell them which tasks they are supposed to execute. Understanding the context (technical, business and political) is very important.
• Make sure they understood – Ask some questions, have them presenting some ideas and thoughts about the project. If they really understood it, they’ll look excited (unless the project sucks!) and you will quickly notice they got it. This feeling of understanding will be presented to you as shinning eyes. That thing we all have when it rings a bell inside our head.
• Tell them how/why it works – Talking specifically about software now, if we need someone to solve a problem by coding something we can’t just tell them how a screen or a procedure should work and expect success. To achieve it we need to fully explain why that thing should be made in this or that way. By explaining how things work we get two main benefits: 1) The act of explaining is the best way to make sure we understand about the subject ourselves and 2) We can use other’s knowledge and experience to make it work even better.
• Show you trust them, share responsability and authority – Akita described it very well (it’s in portuguese, sorry) in his blog post. It’s vital that who is going to execute something has the authority to fulfill the responsibility he just received.  You should trust and believe that the responsible person is going to execute it in the best way he can and give him all freedom he needs to do his job.
• Make a plan – Planning is a very important thing. Not because of the final plan, but because of the act of planning itself. When you plan you have to think about the subject. You have to think how it can be done, what are the risks, what more should I know that I don’t know, etc. Do it together, with all team members.
• Also, give limit boundaries – Last tip, it’s important to define some boundaries to everyone that is involved, borders that they can’t cross. If for any reason they can’t do something or you don’t want them to do something you have to explicitly tell them no to do so. Otherwise there’s no way they’ll know it. And of course, you have to explain why they can’t or shouldn’t do it.

I believe that these five tips can increase the success chances in almost all scenarios we face everyday dealing with teamwork and I also hope that it will help you the next time you ask for something and get it different than you imagined.

[1] It doesn´t have to be a big team. I consider team work when more than one person is engaged in the same project to achieve the same goals.
[2] I’m using the same definition for project that David Allen does. Project is anything that needs at least two steps to be done.