Thanks Roy

Eli Lopian    Management for Geeks    

I would like to thank Roy for the amazing time we had together, Roy has been working at Typemock for 3 years now and it has been a blast! Good times, hearty discussions and we managed to overcome great challenges together.
Now Roy is going on another journey and is focusing on Ruby.

Thanks a lot Roy for the great time, we already have plans to do some stuff together, and I am sure we will continue to do so. Good luck with your new gig.

I want loud disputes in our meetings

Eli Lopian    Management for Geeks    

We had a really high tone dispute in a few meetings about our coming breakthrough product. It was on the verge of getting hostile, both sides where trying to make a point but no one was really listening and the same questions where being asked over again with the same answers just with higher and higher tones. It was getting frustrating, and this had been going on for 3 meetings.

I believe that conflicts in discussions are vital to keep our minds open and are very productive and we normally get to great ideas, but in this case the conflict was not going anywhere. Trying to get others to talk about their views and trying to talk about it from different viewpoints didn’t help. We adjourned the meeting with bad feelings.

During the days that followed, each team member approached me alone and talked about how non effective the meetings were that they didn’t feel good about the situation. I asked them: So what are you going to do about it? and got a range of answers in the spirit of “I will make sure not to do it any more”.

After some time I talked to them one on one and told them that I had enough information to make the decision and explained the solution and how it fits our major concerns.

In the next meeting, I explained the solution once again to everyone. Everyone nodded. I hope I showed them:

• How to take responsibility and make a choice.
• How to make a choice with clarity even though there is no certainty.
• That it is possible to fix the frustrating behavior by talking to the other party in private, and not just promise to “not to shout in the future”
• How to solve differences outside the meetings so that decisions are easier to make.

I then thanked the team for taking a side, for showing that they cared. I want the team to continue to be passionate about what we do and to continue to fight if needed, this will help us reach a much better solutions. 

Thanks team! Great fight!

Top 5 questions to ask when checking references

Eli Lopian    Management for Geeks    

It has taken me some time to really follow the best practice of checking references,  both before hiring of new employees and of external contractors. Now I don’t move without it. The main reason that I didn’t check references is that it seemed to be a useless process, every reference I talked to always said great things about the employee/contractor and I never seemed to get anything useful.

Now, I get invaluable information from the references, at times it

This was because I didn’t ask the REAL questions, now I have found what questions to ask and the key is to LISTEN, but really listen, to the answers given.

The questions are:

1. How long have you worked together?

2. What didn’t go well? What were you NOT pleased about?

3. Would you hire him/her again today?

4. Did you ever think of leaving/firing him?

5. Try to help me out here, if we are going to work together, what would be the problematic areas? What is going to be tough? Where can I fail?

Tip: If you don’t get an answer, say, No one is perfect, unless someone is paying you, there must have been some things that went wrong.

(Make sure to keep a written record of all conversations to put in a candidate’s file.)

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.

Getting the Boss to get Rid of Himself

Eli Lopian    Management for Geeks    

Here is a short discussion I had with a Typemock employee a few weeks ago.

Employee: “Phew, We managed to purchase the last available ticket ”
Me: “That’s great…” after a pause “… Why do we keep on missing the early-bird discounts?”*
Employee: “That’s because you didn’t approve it until the last second”
Me: “Wow, I didn’t know that I was the bottleneck. But… we all knew about this 6 months ago, how come this didn’t come up”
Employee: “Because YOU didn’t tell us that we are actually going to do this”
Me: “Did you expect me to tell you that we should do it”
Employee: “Yes, we where waiting for you, we always wait for you, and then you normally come storming in at the last second and ask us if we are going to do it and what we need to do to it”
Me: “So lets see why this happens, how do I know that you are waiting?”
Employee: “We ask our manager if we are going and he says that you have to approve, so we asked you what we should do but you didn’t tell us to do it”
Me: “Why do you think that I know what to do?”
Employee: “?? What do you mean? You are our manager”
Me: “Ahh, here is where the problem is, you should know better that I do if we should do it. If you really believe that we should do it, you should just say so. Tell me that we should do it, I might ask you some questions but it must come from you and not from me”
Employee: “So… I am supposed to tell you what we should do?”
Me: “Of course, and explain why, you probably know better then me, and that way you wont be waiting for an answer that I don’t really have.”
Employee: “So how come you used to come at the last minute and tell us to do it”
Me: “When I found out that we are not ready to do it and we are nearing at the last minute, I ask what is happening, I learn the domain and make sure that we don’t miss the opportunity, but I hate doing this. I would prefer that we do it before and pay early-bird prices” **
Employee: “Ok, Now that I know, I will make sure that I tell you what I think we should do”
Me: “Thanks you, I feel that we made a great progress here”

I feel that I am managing to invert the command hierarchy

*  Some problem-searching

** Letting the team make mistakes

photo by Photoma’s World

Managing Rookie Managers

Eli Lopian    Management for Geeks    

Rookie managers have a incomplete perception of management and hold on to the idea that they are still reviewed by their personal performance and that there job is to keep things running.

Quite the opposite, it is a mangers job to make change, it is their job to search for problems and opportunities and manage the change in the best way. They will start with 90% keeping things running and 10% initiating change and as they are promoted the percentages will swap.

One way to get rookie to think in this way is to ask them strategic questions.

For example:

• What technology will the team need to know next year?
• How are we going to cut our waste by 25% next quarter?
• How can we measure and improve our quality?

If they just split out the answer, you might want to ask them how they know, but you could then just ask them what they are going to do about it?
If they don’t know that answer, ask them what they are going to do about that?

In either case you can now turn the strategic view to a personal integrity, and coach the rookie.

picture by teliko82

Never promote to a management role

Eli Lopian    Management for Geeks    

This post is to remind myself what to do what promoting first time managers, based on the final tip in the Myth and Realty Check Post.

Eli, Remember to Delay the Promotion

Here is why. When promoting a manager, I normally promote a high performance employees. These employees are excellent at doing their job well. They are talented, have a good time management, can work in a team. But they are most likely to have a wrong perception of management, this will lead to problems. The new manager will most likely still think that he is being reviewed on his personal performance instead of the teams performance

Its a catch 22 problem, the rookie manager can not get the new job because he needs to change his perception, but the perception cannot change until he jumps into the water.

My solution is instead of promoting, give that person a task that he can succeed only if he uses influence, a task that he cannot do by himself. For example to gather a group of people, that he has no authority on, and convince them to do a task together. A task that they will need to volunteer for. Explain that this task is about completing the task, but also about teaching him to use influence, a trait that is a requirement for a management role. Review his progress, help him out with interpersonal issues. Once he passes this task, he will find it easier to take on the managerial position.

Rookie Manager #3: Myth vs Reality

Eli Lopian    Management for Geeks    

Rookie Managers, including myself, often fail in their new role. Now looking back at my first managerial job (10 years ago) I think that the reason for this was misconceptions and myths that I believed in as a new manager that lead to neglecting key responsibilities.

Myth #1: Authority.
I used to believe that as a manager, my new position gives me the power to be on top, to tell my direct reports what to do and that I have the freedom to implement my own ideas.
Reality: The reality is that I was not in control of anything, I learnt to sit at the back of the bus and let my direct reports drive. I learnt that I need to negotiate interdependencies, build influence by creating strong relationships based on trust and credibility, throughout my team and organization.

Myth #2: Control
I believed that I had to control my direct reports early on or they will walk all over me.
Reality: Compliance is not the same as commitment. I learnt (and still am learning) to create an empowered, committed and accountable organization. The more power that I am willing to share leads to more influence.

Myth #3: Lead by Technical authority
I thought that I needed to lead by example, and to be the best technical employee.
Reality: I had to learn to take the back seat and allow the team to come up with the technical solutions, even if I thought that they where not as good. I had to learn that it is the team’s performance that is important and not my own personal performance.

Myth #4: Keep everything running smoothly
As a rookie I though that it is my job to keep everything running smoothly.
Reality: Although keeping things running is really difficult, it is problem finding and initiating change that is required, even if this means going against the organizations structures and processes.

Final Tips

If you are a manager that just promoted a rookie, please remember these myths and try to explain the reality.

If you are a rookie, remember that you have to make your own success, become proactive, ask for help, your success depends on this.

photo by bernardhoa

Rookie Manager #2: Problem Solving vs Problem Finding

Eli Lopian    Management for Geeks    

There is a big difference between problem solving and problem finding. This is one of the differences that a Rookie Manager must learn quickly. A Rookie manager that has been promoted from the firing lines, from software development is trained to solve problems. Normally the best problem solver who is promoted to the team-leader or manager of the team.

But once you are a manager you are on a transition from a problem solver to a problem finder.

Suppose we have to solve the problem of heating a room to 25°C (77°F). This is something that a problem solver can wire up and and create a system that heats the room when the temperature falls below a certain degree. But the problem solver stops there. The problem is solved.

The problem finder, goes one more step and asks: “Why 25°C?”
As a manager you must start thinking in the Problem Finding Paradigm and once you get there you must start thinking in the Opportunity Finding Paradigm. What opportunities does the team/company have?

Try to find problems in your team/company.

• What is the bottleneck of my team?
• How can we handle external pressure better?
• How can we communicate better?
• How can we code faster? better quality?
• What does the team need to learn?

Remember that your team knows how to solve problems, so ask for their help in solving them, but it is your task to uncover them.

photo from alachance

#1 tip: What I expect from managers and team leaders

Eli Lopian    Management for Geeks    

It is very natural for new Managers and Team leaders seem to think that once they are given the responsibility over a group they have to ‘Claim their territory’ and guard it with all their might.

Things that can really tick off new managers are others telling specific team members what to do or how to do things, and not informing the manager.

If this is happening to you, here is a tip:

Chill out, cool down, everything is ok. You colleges believe in you and know that you can do the job. There is no need to protect your territory, you don’t want to become a bureaucrat [1].

• You WANT your team to communicate with others
• You WANT others (including your manager) to be able to cut the red tape and talk directly to the team members
• You WANT to be your teams leader, You DONT WANT to be the teams protector
• You DONT WANT to become a bureaucrat

To do this you will need the team to be mature enough to solve problems by themselves, your job is to get the right people in the right places and to enable them to solve these problems.

If these things tick you off, it’s a great opportunity for you as a manager to grow. Just realize that the problem is trust in your own team, not with the outside world. Teach your team how to deal with these things. Work with Integrity.

• If the team can still complete all its commitments then everything is ok, you will know about this in a clearing session and be able to praise them on how they solved this issue.
• If a team cannot complete its commitments, the team will notify you about this and you can decide how to continue
• If the team doesn’t know what to do, they will come to you and ask you, they will present their dilemma and you can help them choose the correct solution.   

This is what I expect from my managers and team leaders:

Be a growth agent and a empower you team, focus on taking the correct risks not on protecting your team or territory.

[1] My definition: a bureaucrat says “No we can’t”, a leader say “Yes we can”.
Image: by rob surreal