Being a Leader is overrated

Eli Lopian    .NET Tests    

Reading a blog post about leadership versus being a boss, I started to think about this matter again. I honestly don’t think that we need any more leaders – we actually need people to execute tasks.

Speaking of leaders, I’d rather call them coaches; coaches are people who understand that their largest task is to grow their team. A coacher doesn’t depend on Good Will, nor will he fix the breakdown or say “WE” instead of I…a coacher will make sure that the team has the tools to find how, and to fix the problem themselves.

The coach is a role model: he never expects others to do what he doesn’t. A coach is the one that turns the triangle upside down and putting himself at the bottom helping  out.

A coach is the one that empowers and will guides. He is the mentor.

Typemock Patents- you’re missing the point

Eli Lopian    Product    

Roy just asked me to blog about a twitter-conversation on our Typemock patents. 
It is true, we do have a patent. Its number is: PCT/IL2007/001152 
It is natural for companies to file patents of their innovations and inventions.

We have no answers to the questions that where asked and we haven’t any policy about this as this is not important enough.

What is important and what we are focusing on is that less than 10% of the developers actually write unit tests! We are focusing on innovating to get the right tooling that will enable the majority of developers to unit test their code, becoming craftsmen and professional and take the whole software development community another step forward, not on delaying innovation.

image by ihtatho

Boss, Stop Delegating Work

Eli Lopian    .NET Tests    

My two year old daughter, Rona, is piecing together a puzzle, and she is really frustrated, as she is trying to join two unrelated pieces together. At one point she nearly tore the piece in two, when I saw that I really cringed, she is going to ruin the puzzle. I really have to hold myself back from just taking the piece and doing it myself. But I can’t because if I do, what will she learn? To keep myself from actually just solving the puzzle, I cook dinner and let her work it out herself. It’s frustrating, but I really need to be patient.

I am actually a control freak. Perhaps like many managers I hate the unknown, or to let someone else deal with our tasks. What if he doesn’t do it as well as I can or just the way I do it? What if he doesn’t understand what I need? From my experience, this is normally the case; I don’t get what I want from delegating. When I read about it I found many tactics and checklists like Johanna Rothman (The Delegation Check list)_ The checklist looks fine, but come-on, have you really delegated this way – it is so complicated and you are not guaranteed success if you use the checklist.

So what’s the point of delegating, if I am still worried if the work is being done and need to check every step they take? I’ll just do it myself and just get it done. Sound familiar? So how do I delegate work? Well I don’t, or I try not to, because you can’t really delegate work.

So delegating is critical to success. You simply can’t do everything yourself. But it is impossible to delegate, how I get out of this tangle; I am beginning to feel like Rona and her puzzle. This is where is hit me, you can’t delegate work, but you can empower people, you can delegate responsibility. Delegating responsibility is simple, but it required a lot of patience to empower people.
1. Tell the person the end result that you expect,
2. Ask them if they can be responsible for it.
3. Ask them when they think it will be ready.
Wait…

For example:
1. “To get more developer to write unit tests, we need it to be easy to write the fake statements”
2.”Can you be responsible for that?”
(Here you will get many questions…)
3. “When do you think it will be ready?”
(Work with them to break down and prioritize tasks, or wait till they do it themselves)

This way we turned things around, your staff member should come to you and ask you what he needs to do in order to get the project done, instead of the other way around. The employee needs to come up with the questions. You shouldn’t have to lead him.

Let them lead. I know it can be scary, and things will move more slowly at first. But as they build and execute their plan, they learn. A good manager lets his employees make mistakes as part of the empowering process.

It’s hard to let go. But when you understand that as a manager, it is your job to empower and grow your team, you will learn to sharpen your swords instead of cutting down the trees yourself. Sharpening the swords takes a lot of patience, but when you take a step back and look logically, you can see the need.

I still trip on the slippery hill of delegation. It’s really hard to stay out of their way and let them work.

The best delegation is when you give a responsibility that is a bit higher then what the employer himself believes that he can handle. As I say: I believe that my team can do more then what they themselves believe. The message you deliver is that you believe in him. They might fail once or twice but by the third time, you have another empowered employee that can do much more than he ever thought he could. That is, as long as he has the necessary abilities, he will not fail. But you will need patience just like I need with my two years old, and after all, I’m not asking my two year old to cook dinner, but to finish a puzzle.

Debugging Communication Errors

Eli Lopian    .NET Tests, Community, Debugging, Management for Geeks, Time Management, Unit Tests    

I couldn’t sleep all night, thinking that on the last company meeting, when one of my employees complained that he can’t finish his tasks because of personal issues that he has with other employees,  I basically told him and the rest of the team to help each other and be a team, I was managing them instead of empowering them, and knew that the issue probably remains unresolved…

For the next meeting, I decided that no matter what I do, I will make sure that my team goes back to work after they resolved their issues themselves, empowered to continue working and achieving  their goals.

I started the meeting by asking each of them to bring up a personal issue that he has with another employee and to resolve it with the other on the spot. It was amazingly interesting to see how they raised the problems, and found the solution at the same time.

One of the employees complained that he requested help via email. He sent the email, but didn’t receive any answers. He needed certain people in the company to fill out part of a form, but none of them did. Nothing but a simple communication problem; they all got the email but didn’t understand the call for action. His way to resolve the matter was to sit with each one of the people involved personally and to fill the form together, that way he will make sure that they understand their share, and he will make sure that it’s done on time.

One of the developers complained about having troubles with managing his time.  I explained that this is not an interpersonal problem, and asked him questions which led him to realize that his lack of time is because he is always helping people. He can’t say no to anyone, and he doesn’t want to look bad or disappoint anyone, so he ends up making everybody happy by helping them, but having no time to do his own tasks. When he understood, it was a major breakthrough, and he realized that he will have to start saying no to people or at least to say I’m busy now I will help you later; I would love to follow and see if he would really do it…

It’s only two examples out of many. The amazing and inspiring part was to see how each one of them was empowered and found his own way to resolve his problem without being told or managed.

Last, out of the entire company there was one developer that claimed that he has no personal issues with anyone in the company. When I asked him if others has problems with him, he was confident that their answer would be no.

On the second round that we did, each one of the developers needed to share their successful interpersonal communications, almost everyone mentioned him.  I guess that it was as obvious to them as it was to him.

One of the more gratifying surprises from the exercise was hearing about the successful communication routes that have developed that I did not know about.  For example, two developers found the time and were sensitive enough to help a third that was in major distress.  They simply encouraged him, but it was exactly what he needed in order to get back on track.   Another developer thanked the sales team for providing him with relevant historical customer support information.  Yet another thanked a team member in marketing for helping him with the wording in an important email to customers.

By the end of the process, it was clear that the team understood the power of effective communication and they now had better tools to resolve interpersonal issues with team members independently.  And at Typemock we know – your result (read: code) is always better when you’re working with the right tools.

When you know immediately when something is wrong, you are able to fix it, and get an immediate indication that your code is correct without the involvement of the QA. In other words, exactly like the Manager that empowered his team to resolve their problems without his involvement and without managing them, the unit testing helping the developers’ resolve problems on the spot and avoid QA involvement.