I want solutions not problems

Eli Lopian    Management for Geeks    

Jurgen wrote a post: Empowered, Whether You Like It or Not about decisions being backfired to management.

I agree that a good manager cannot afford to have a team that needs to ask the manager how to solve problems. It has nothing to do with influence or control, it has to do with flow.

Just imagine what would happen if a football/basketball team needed to ask the manager what to do in each situation, the game will stall to a halt and become really boring.

As a manager we must empower our teams to make decisions themselves, we can guide them but we must not answer the problem ourselves. We need our team to grow, and they can only do that if they leave their comfort zone, grow up and make decisions themselves, taking full responsibility.

This is really hard to do when you start managing, so I use this trick.

My team knows that I want them to grow, so when a problem arises this is what I say:
I want a team that can solve problems, we are not being paid to find problems we are being paid to solve them. So I don’t want to hear about problems only about solutions. So lets take the problem at hand and please tell me 3 possible solutions.

Amazingly I have never said this and heard no solutions at all. After there are a few solutions, I ask which one is the best solution and why. Here I can guide them, here I can solve dilemmas and make choices when the team can’t make them, but only after I have several solutions.

The nice thing about this is that the team will solve things differently and perhaps better then you could solve it yourself.

A note for those who are going to try this. It is very important to give positive reinforcement when your team does the right thing. That is why I make a point of listening to the dilemmas that the team made and congratulating them for solving. You can not do this kind of delegation without proactively tracking the times that the decisions are being made within the team.

Stop Designing for Testability – Revisited

Eli Lopian    TDD    

I just received an email about a comment on my article on Code Project, Stop  Designing for Testability. After nearly 3 years it is still getting comments.

The article is about the tension and balance between TDD/DI and OOD.

While looking at the article I am excited to see how much we have progressed, with the AAA syntax, thanks to .NET 3.5. Our recursive fakes and features that help lower the fragileness of our tests.

I am being followed

Eli Lopian    Fun    

I received an email from a few people who want to follow me on twitter. The problem being that I don’t have a twitter account.

Instead of letting them down, I creates an account and followed them back. Now I have to start twittering.

My twitter is http://twitter.com/EliLopian

Create Exceptional Developers

Eli Lopian    Management for Geeks    

A lot has been talked about how to become a great developer. They are all good ideas. I think that as a manager it is our job to grow our team and create great developers. I talked about creating challenges to do this, in a previous post. But what exactly are those challenges?

Here is a summary of what others say:

• Migael posts 15 tips to becoming a better programmer.
• Andrew says that we have to become a software engineer
• Oren Ellenbogen has 10 rules to become a great developer
• Ayende talks about a big leap and then about doing stuff
• Phil talks about programming better
• Jeff says that you have to stop programming and “Learn about your users. Learn about the industry. Learn about your business.”
• Joannes Vermorel talks about being smart and getting things done.

So how as a manager do we create better programmers? I don’t think that having a list of tips is the correct answer, I don’t think that as a manager you should give a list of tips. I think it is deeper and Ayende’s “doing stuff” and Phil “programming better” are on the correct path.

I found a great post on how to become an expert from the Creating Passionate Users blog. (the graph is from that post)

Most of us want to practice the things we’re already good at, and avoid the things we suck at. We stay average or intermediate amateurs forever.

Phils references Scientific Americans “The Expert Mind” Study.

In this study they take chess players and research how to become an expert player. It comes down to the fact that both a professional and a non-professional player do the same amount of analysis (how many future moves are calculated) and they both spend the same amount of time playing – so they practiced the same. It is just that the expert always raised the bar and practiced harder and harder games.

The bottom line, is that we must leave our comfort zone. We are comfortable avoiding the things we suck at. We must tackling those parts. As a manager we must notice the places where developers are avoiding and challenge them to do them.

If they avoid writing the help, they must practice doing it until they get good at it. If they avoid a complex module, they must practice doing just that module. If they avoid helping the QA people, they must start helping the QA people. If they avoid understanding your users, start interacting with the users.

The developer will NOT like this at first, but only by trying, by raising the bar and by practicing will your developers become experts. Even if your developers are satisfied with where they are, as a manager your can’t afford to let them be stuck, you should push them to become experts

Managing the support

Eli Lopian    Management for Geeks, Product    

We take our support really seriously here at Typemock, our customers see and talk about this great value. But there is much more to support then fixing bugs.

We learn from our support how our customers are using the application and what are the pit falls. From every case we proactively try to find out how to create a feature that no one asked for, but that has great value. We change the application so that the user falls into the pit of success

This is how we came up with the Recursive-Fakes. By seeing how users write their tests we saw that a lot of their time is spend writing a fake, running the test and then seeing it fail because the fake was part of a call chain [cat().tail().wag()] and doing this recursively (hence the name) until all calls are satisfied.

We supported the call chain scenario for quite some time, but we didn’t understand the pain that our user has to go to setup his tests. After Recursive-Fakes was created, the user falls into the pit of success and gets it right the first time. Once an method is fake all the chains from that method are fake too. This feature was so strong that it became the default and both other frameworks have partially implemented this feature too.

Comfort Zone

In order to do this, we have to leave our comfort zone in our support. We can not just close a case after the customer is satisfied, even though we would really love to. We have to take responsibility that it won’t happen again. That users will fall into the pit of success and not need to look it up in the documentation or search the forums. To do this we must think of a feature that will do this and feed it to our backlog of features. This is where we must use loads of creativity, and although it is difficult, we must do this to excel.

Measuring Support

There is a problem measuring support. On one hand once the product gets better, we should be getting less and less support. On the other hand, because more people are using the product, we should expect more support cases. So I would like to see a trend of our product getting better, but we have to make sure that there is enough people in support.

The current important metrics are

• Cases that one support reps can handle in a week
  This is a derivative of the time it takes to fix an issue. This metric is important to see if we need to add another support rep.
  We expect this to raise as we get better in answering issues and as our product evolves and become more maintainable
• Cases open per week
  Are we getting more support cases?

Other measurements for the quality of support are

• Time to fix issue
  Our customers want their issues solves, so we should measure the time it takes us to solve the issues.
  We expect this to metric to become faster as our product becomes better
• Time to first treatment
  We know how agonizing it is to send a support issue and not get any answer. We care about our customers and strive to answer them as quick as possible
• Number of pit success features
  This is how we can tell if our support is effective at creating customer features, and not just repeating the same issues.

Although it seems easy, these metrics are actually hard to extract from most issue tracking systems. But these metrics can be used for integrity management. Each rep can ‘commit’ to the number of cases he will handle, the time for first treatment, and the number of pit success features he can create.

What metrics do you use?

Presentation at the Tel Aviv Entrepreneurs Meetup Group

Eli Lopian    Management for Geeks    

I gave a short presentation to the Tel Aviv Entrepreneurs Meetup Group. It was great fun. I wanted to share one tip: To build a great team you cannot bring in someone who can do things that you can’t. This lead to many passionate people saying exactly the opposite. “You must hire people who are better then you”

I know, I was told this in the past, this is what we were all told, but I don’t think that it can really work without the first magic step. The first step in bringing in people who are better then you, is to leave your comfort zone and do it yourself, then and only then, after you know what to do, can you bring in someone who is better then you.

Accountable and Responsible

Eli Lopian    Management for Geeks    

Jurgen is debating the difference between Accountable and Responsible.  It is great to see that we are thinking about the same things. There must be a reason for this.

I think that the debate is important because there are many times when a discussion with an employee ends with: “Yup, I didn’t reach my goals, I am sorry, I take full responsibility”.

So what does that mean? Where exactly are you taking the responsibility to? Is there a place where you keep all you unmet responsibilities? What would happen if your child ran onto the road and was hit by a car? Would you still just say “I take full responsibility”?

That is why at Typemock we use these two words as follows (I found the same definition in wiki answers)

• Responsibility can only be used for future actions, that is why we have a 200% responsibility rule.
• Accountability is used after the fact, and there is a debt to be paid.

So we don’t allow “taking full responsibility” for past actions, if you didn’t reach your goals, you are accountable, you have to pay.
You can pay by taking responsibility and find a way to fix the mistake (note this is a future action), or by paying you dues in salary or bonuses (and if you are not up to the job, leave it for someone who is)

So you take responsibility of your child and make sure he never runs onto the road, if he does, you are accountable. You can now take responsibility and rush to the nearest hospital, you now must pay the price.

This is why we all take 200% responsibility and everyone is accountable for his own commitments (see how integrity management works). Managers are also accountable their teams commitments and goals.

Retrospectives should not be about sharing pain

Eli Lopian    Agile    

Jason Yip has a great post: Retrospectives should not be about sharing pain

Retrospectives should not be about sharing pain and venting.
Retrospectives should be about getting better.

So true.

How do we make sure that we are a problem solving culture and not a complaining one? We use the clearing technique. Every problem must be followed by a controllable action solution and commitment. Dilemma’s are used, if there is a need for the manager to decide, but the team member must give 2 or 3 possible solutions.

Once the team gets used to this, they start coming prepared to the meeting and come up with solutions in advance. After the team gets comfortable with that, the next logical step is to solve the problems as they happen (Lean anyone?) and not waiting for the retrospect.

Manager – Create obstacles for your team

Eli Lopian    Management for Geeks    

I asked before about how to manage self directed teams, most responses where that the manage should remove obstacles in the way of the team.

I think the opposite. A great manager should never remove obstacles, big or small, on the contrary, a great manager must create obstacles and challenging his employees to grow every day. A great manager helps his team grow, this can be done only by raising the bar.

So to answer my question: How to manage agile teams?

Spend most of your time with your best people, Show them that they can do better, show them that they can become experts, raise the bar and create a place where employees grow.

I love taking examples from sports. Team Sport is mostly made of self managed teams. Think about it, when the team is on the field – they are self managed and they take decisions without the manager. So how would you manage this ‘self directed’ team?

Here is how I would. I would raise the bar, practice and make sure that the players are in shape. I would use integrity to help the players commit to working out, commit to kicking/throwing the ball 100-200 times so that they practice and work on their best shot. That is what separates the pro’s from the Joe’s

Home Movies and Integrity

Eli Lopian    Fun    

I have been taking home movies for over 10 years now, I now have an HDD camera, but I still have loads of Mini-DV’s hanging around the house. I have always wanted to edit the material. I have searched for the right tool ages ago, but the moment that I chose my tool (Sony Vegas), I have been stuck. This was over 5 years ago

What I told myself is that I don’t know what format to save the files? Should it be 17GB/hour raw dv? Our perhaps 4GB/hour Mpeg-2? Or maybe 700MB/hour XVid?

The truth is that I have no integrity with the movies, although I did search for the right tools (that was really fun), I never really use them. I felt like someone who is looking for a job, but who just spends his time looking for a job, and not actually taking one, and just keeps on looking for a job. I spent my time looking for a tool instead of actually editing the movies.

Having no integrity with the movies, made me stop even thinking about editing (I never succeed so I might as well not try) and eventually film less (what will I do will all the tapes). Like a chip on my shoulder, I keep on reminding myself that I have to do something with the tapes.

So this week, 5 years later, I decided to clear the slate and work with integrity to solve my tape problem. I started by intending to talk to 3 people about the format that I need. I managed to talk to one and I finally decided: I will go for the 4GB/hour Mpeg-2.

I then intended to look for someone to do it for me, so I talked to 5 shops, but they where either too expensive or not professional enough (they could only convert DV to DVD, or they never answered my call)

So I then intended to do it myself, I plugged in all the hardware, and I started by capturing 1 hour onto the disk trying different Noise Reduction Filters and Mpeg settings, the clips are looking really good, and now I have written an automating script to render all the clips. (1 DV hour takes over 3 hours to convert end-to-end)

So now I intended to do 1 DV a day (when the computer is free), this way I will get all the clips on disk and they will be more accessible.