What I can share with you is that following the great success of the Isolator, we weren’t sure what our next product should be. We wanted to help the developer, and yes the first time we got it right, but what next?!

When I first got my iPhone, I was so into it that I found myself using it all the time. One evening I sat in the living room, playing with the apps when my wife said “you are always on the iPhone. I don’t know how to communicate with you anymore.” Before I could reply, my 7 year old daughter said with a huge smile, “through the iPhone!!” What a young marketer, She quickly identified the need and its easiest solution.

We tried to emulate that kind of straightforward thinking when we decided on our next product. It wasn’t easy but eventually we understood that we must actually know and not just assume what the market actually needs.

We conducted marketing research FOR THE FIRST TIME. Leaving the Echo Chamber, we had to check what our target audience wants and what products and services they need.

The process was not easy. A trusted advisor said “I can do that” and then she and I had to convince our team that this was the right step. Convincing everyone was very hard, even when they went to see the focus groups about developers and what their pains are. When we saw the developers’ needs, each one of us saw them through a filter of our preconceived ideas, seeing only what we wanted to see, and reaching individual conclusions.

Finally, we compiled the conclusions to develop THE idea to solve a problem or a pain. Only after we started writing it, we started to understand the power of what we were doing.

A key learning was that we don’t have the same needs of the developers that we develop for. There is a difference between those who build features for developers and the developers themselves.

But if you are reading this blog you have probably already “seen the light”. You probably want to learn how to connect your developers to their customers. They don’t necessarily think or act like you. We are all developers but with different needs.

Breakthrough breaking a wall…

Our here-on-earth mission is to help developers write unit testing that help developers and respect the occupation of development.

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.

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

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.

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.

We are growing and we need to recruit an Online Marketing Wizard, just as we only get the best people for our development team, we have to get the best people for our marketing.

I found out that the best developers where ones that came from our networks, friends of friends, so I am going to try to use my LinkedIn network to find our wizard.

I posted the job description in a few groups that I follow, and I send a message to 50 of my connections asking them to help me find the marketing wizard. I hope that they will forward the message.

So far I already received 3 CV’s from the group job posts.

Just in case you know someone here is the job description:

Online Marketing Wizard

• Knows Marketing
• Experience in internet presence + online marketing activities (at least 2 years)
• Experience in marketing internationally (at least 2 years)
• Some knowledge in offline and general marketing strategies.
• Knows how to define and establish marketing strategies & campaigns – advantage
• Team player and the ability to lead, encourage and motivate people.
• Creative mind
• Specialize in:
  o SEO
  o SEM
  o SMM (social media marketing).
  o Online Traffic Reporting and Analytics services
  o Google AdWords and PPC Services (Pay per Click)
• Experience in working with out-source suppliers
• English Mother tongue – advantage

As a present my friends gave me a Tandem skydiving, I am waiting for good weather to see why my friends want me to jump out of a flying plane 4 km in the air.

My birthday always falls close to the end of the year, so it is also a good time to see what happen in Typemock last year.

Typemock in 2009

We have had 4 new babes in Typemock from Roy Osherove, Doron Peretz, Shalhevet Segal and Dror Helper. Congrats, First timers: Welcome to parenthood

We have welcomed 4 new employees this year.

We have invested over 15,000 hours in our products and we now  have 6 great products to make unit testing easy

• Isolator
• Isolator for SharePoint
• Isolator for ASP.NET
• Isolator for Silverlight
• Racer
• Tracker

The development team has made a breakthrough with Intellitest, to guide developers into writing good tests easily.

We have started This Week in Testing podcast.

The company has a FedEx day, once every 2 weeks, in which developers can work on their pet project.

Our development process has evolved and is a hybrid between scrum and ToC.

We sold over 100% more licenses, showing us that more developers are jumping on the unit-testing wagon.

Our sales team has managed to help developers successfully implement unit testing in their company. Our site has received a facelift and we have a new coffee machine.

In short, we have had a breakthrough year in our development, our products, our sales and there is much more to come.

To reach these result I have to thank the Typemock team, they are a great team and our amazing customers and partners who made this happen.

Best wishes and a happy new year.
Eli

1. Curiosity
   To start this adventure in the first place you will need a load of curiosity and a passion to learn.
2. Courage
   You need to have an adventurous nature and the courage to go on this journey to the unknown.
3. Drive
   You must keep on the journey and not turn back, this requires drive to keep on when things look bleak.
4. Integrity
   You must know by now that I am an integrity freak
5. Empathy
   You will be meeting and needing other people on the way and must respect them help them.

photo by Werner Schnell (1.stream)

What is interesting is that I keep on seeing these pattern. I was making Schnitzels (breaded chicken) for dinner today and my kids where helping me (and fighting over who gets to stand closest to me, but lets ignore that part for now).
Making schnitzels, has a few stages.

1. Cut chicken breast into small pieces (I did this)
2. Put beaten eggs in a bowl of (my kids did this)
3. Put bread crumbs and spices on a plate (my kids did this)
4. Heat up oil in a pan (I did this)

Now comes the fun bit, each piece must be dipped in the egg, then in the bread crumbs, then cooked in oil until it is ready. My kids started to dip and coat the chicken and I put it in the oil, but very soon the pan was full and the coated pieces started piling up.

I started teaching my kids about lean and about not having any waste and I showed them that the piled up pieces are making it harder to cook, they where taking up room and where in the way and basically making a whole mess out of it. So we decided that we can only have 8 coated pieces (enough to fill the pan) waiting and that once we get there we just stop (and play with the tap water or quarrel).

Then I used the second step of the Theory of constraints and tried to exploit the constraint. By moving the pieces closer and by adjusting the heat we could get 12 pieces in the pan. Now we can change our lean constraints and allow 12 free pieces. I explained this and quite soon we completed the cooking.

So Lean and Theory of Constraints play well together. We had a great meal and learnt some process theories on the way.

.

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