Led Zeppelin didn’t ask for more time.

Eli Lopian    Management for Geeks    

Seth Godin has a post: I need more time.

It is a great post, short and to the point. I talked about this in the past.
Basically, you don’t need more time to make a decision, once you have collected a reasonable amount of information, just make the decision, take a choice and do it. As Led Zeppelin sang

Yes, there are two paths you can go by, but in the long run
There’s still time to change the road you’re on.

This tip alone made me so much more effective, and even better – less anxious.

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.

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.

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

Losing your best people

Eli Lopian    Management for Geeks    

I have just read First, Break all the Rules by Marcus Buckingham. I highly recommend it. There are many pearls in the book:

Here is a sure way to lose your best people:
Spend all your time helping the strugglers.

If you want to excel, invest in your best. Learn from your best, discuss things with them, understand what they do that makes them excel.  Don’t spend all of your time investigating failures, study what is working really well. Challenge your best, leave the average, acceptable level of performance, push a little every day.

This doesn’t mean ignoring the weaknesses, handle those, but give you biggest focus to your best people.

Who are your best developers? What do they do that others don’t? How do they excel? Spend time with them.

Matrix Communication not Matrix Management

Eli Lopian    Management for Geeks    

Working in a Team is more then just allowing each team reaching there own goal. I talked before about Team work and how it is possible that by completing your own goal you will hinder the teams goals.

Lets see an example.

Team A wrote an encryption library some time ago, now team B needs encryption too.

Team A wrote the library without the use of an interface simply because they never needed one (they only use one encyptor).  Team B now needs an encryptor which is slightly different from Team A’s.  What would be the best way for the organization to proceed is for team A to modify their code and have an encryptor interface – something that wasn’t needed before.  Team A has no real incentive to help by modifying their code.

Question: How does team B even know about the encryption? Does the organization facilitate this? How will the organization do what’s best and have team A modify their code.

How does your organization facilitate this?
This is really hard as there is too much pressure to do the opposite. As a self organized team trying to reach its own goal, Team A, will always put this rework low down on the list. I am sure that team B will then decide to just write it themselves instead of trying to convince team A to do the job and become dependent on them for maintenance. I know of many organizations where team B will just copy team A’s library and work from there, what a waste, how un-lean.

Integrity to the rescue.

Here is how it can work with integrity management:

At the team leader weekly meeting:

Team leader B: “the team will commit to writing an encryption.”
Team leader A: “we already have an encryption”
Team B: “great, can we have it”
Team A: “sure, but we will have modify our code”
Team B: “so can you commit to modifying your code?”
Team A: “well, we have other things to do”
Team B: “This is critical for our development, but we can use it only for ourselves”
Team A: “The company will benefit from it, so sure, we will modify this code”
Team B: “Do you know, when can we have it ready?”
Team A: “I will get back to you and tell you”

After Team A’s weekly meeting, Team B is told:
”We intend to complete the rewrite by the end of the week”

By Wednesday, team A understand that it will take some more time, they tell Team B:
”We need to change that, We intend to complete the rewrite by Monday EOD”

Monday EOD, Team B gets the new library to work with.

Notice that team B, doesn’t need a daily meet with team A just to ask for the status (all other tasks that they are doing are not really interesting), they can spend their time working. The end result is that the the organization did what is in its best. The communication is clean.

In the following week, while talking about the status, team B will say.
“We had a dilemma, we didn’t know if we should wait for team A or write an encryption library ourselves , but they committed and we never had to ask them about the status and even though there was a glitch, we knew about it and managed to do other things. This worked out really well!”

Integrity in Google

Eli Lopian    Management for Geeks    

When managing integrity, the manager never talks about what to do. The manager can talk about goals, or even better ask the team what they think their goals should be.

Doing this makes delegation seamless as each employee commits to what they think will be in the best interest of the company. 

Do Google get it? I think so, see this post

"Seems like many things at Google, are voted on, or managed by peer reviews. An example are their quarterly objectives and key results. They are done bottoms up with very little top down input. Google’s approach is to hire the smartest people they can and then ask them what they should be doing."

Although I don’t think that smart is necessary the trait to look for (although if you have the privilege to hire only the smartest, go for it).

I think that passion and integrity is all you need. Having the passion and managing your integrity will eventually lead you to being smart, more then just smart, becoming a star.