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

Manager – Shut Up

Eli Lopian    Management for Geeks    

One of the hardest things for me to do as a manager is to shut up!

When I see a flaw in our product or web site or in a plan session, I have to give my thoughts and ideas in order to make the best product.

Although I am making the product better, I am de-motivating the team. There is a simple equation that I forget to calculate when I give my (brilliant) ideas. I must calculate the value added to the product versus the motivation of the team. I am finding this very hard to do, but I must learn to shut up more often.

(picture from je2fs)

Things they don’t tell you about management – part II

Eli Lopian    Management for Geeks    

In my previous post, I talked about our web site team problem and the solution that we reached. I though that we solved the web issue, I only managed to make things worse…

The following day, I was talking to my managers about the difference between Victim and Responsibility and about discussing this in our weekly company meeting.

After the discussion, one of my managers came up to me, and told me that a developer, one of those who was always complaining about the missing resources, and the one who just yesterday the management gave all the resources that he requested, decided to quit.

Wow!

This employee had been crying out for this resource for a few months, we just didn’t have them, and the second that he got all the resources he required – he just quit. This is a classic example of the pit of death. The employee was spending all of his energy in complaining and wasting all his time in creating excuses instead of just jumping in the water and working.

What a surprise. I learnt that sometimes when I just give in and give the employee all he asks for – we get the the root of the problem.

The way I see it is that the company has managed to solve this issue. Having a frustrated employee is no good for anyone. And if he is doesn’t want the job after he got all the resources that he wanted, then the company hasn’t found the correct place for him to be, the best thing that we can do is to enable him to shine and grow in another environment. It is a pity as the employee is very talented.

Aftermath

A few days later, the employee wanted to come back. I asked: What has changed?

After several iterations, we decided that we can work together, and now that person is growing at an amazing speed and comes to work, positively with a smile…

(picture by Brian Landis)

Things they don’t tell you about management – part I

Eli Lopian    Management for Geeks    

Here is a story of a situation that we had to solve back in February. The background of this is our web site and our web site developer. Our web site developer was frustrated that he didn’t have a complete upfront design but the management take is that we have to be agile, get some parts done, time box the design and rethink as we go along, facilitate change and be lean with a YAGNI approach.

This is a typical Agile vs Upfront Design argument.

But the developer was frustrated, and kept on complaining – complaining is really bad, its an energy killer, completely opposite to our Integrity management and our Agile/Lean company culture.

Raise the issue

The first step is to raise the issue as one we need to solve, this is an important step as sometimes these issues can be ignored by the team and the management.

With the help of my coaching, I ask myself the following question.
Although I know that Agile is the better way, perhaps the signals we getting are true? Perhaps we do need more upfront design meetings? This was a breakthrough on my side, as I always thought that I was right, and now I opened the possibility that the developers are correct.

So, in our weekly Integrity Meeting I raise the issue, we had a small discussion and then we asked the developers to join us in the meeting and we asked them:

“We know that when we put our forces together – we can do the impossible, so how can we solve this? What do you need to complete the new web site? We are here to help, what can we give you to help you?”

When the developers started to complain, I explained, that the company doesn’t pay anyone to complain, it doesn’t help, we are paid to find solution. Please tell us exactly what you need and we will give it to you.

They told us the following list:

• Meetings – we need kickoff and brain storming meetings
• Page designs – we need page designs
• Who chooses – who has the final choice
• Text content writer – we need a content writer
• Graphics  – we need graphics
• Back-office – we need someone to handle the Back Office
• Test  – we need a test web site

We gave them all they needed.

• Meetings – we setup two meetings
• Page designs – we gave them the page designs (we had them already) 
• Who chooses – we told them who has the last choice
• Text content writer – we told them who will write and when
• Graphics  – we gave them the number of our graphic designer
• Back-office – we told them who our back office developer consultant is
• Test  – we set up a task to build the test site.

Now I asked if they need anything else? If they have everything to create the new web site?
The answer was yes, they had all they needed to complete the site.

At the end of meeting everyone felt that we are doing the right thing – and that we solved it correctly.

(Picture from mrs_brownhorse)