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

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

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.

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

This will be my first time in Vegas, I am sure going to have loads of fun, and you are invited to.

Just follow #typemock and get ready for loads of surprises.

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

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

Before I go into the details of the gaps, I must point out that all these features exists in the older API’s (that are still available), but they are missing in the newer lambda-API’s (called AAA) that are much better.

Firing Events

This is not an Isolation feature per-se, but it is needed to simulate how our unit under test reacts to external events. In my case I needed to test the TestDriven.NET integration, the TestDriven add in can raise events when ever a test suite is run, and whenever a test completes (Thank Jamie).

Verifying the arguments of a constructor

One of Typemock Isolators unique features is the ability to fake objects that are created within the production code, we call these future instances. There was one case where I wanted to test that a constructor was called with a specific argument. The instance was a class that watched a specific directory for new files and load that file. I tested that class in another test, now I just wanted to test that the class was watching the correct directory. i.e. that the following was called

var watcher = new FileWatcher(testOutputDirectory);

I could of course change my code to have an empty constructor and to set the output directory after that

var watcher = new FileWatcher();
watcher.WatchFolder(testOutputDirectory);

But this felt unnatural, there is no reason that the FileWatcher be called without the directory – leading to more logic – testing that the user called WatchFolder – and complicating the application

Custom Argument Verification

Although we do have an API to verify if a call with exact argument was made, I needed to test that a specific argument was passed, but I couldn’t use the exact arguments API. The reason is that the argument was a class with 2 properties, but the Equals method was overloaded to test only one property, and I had to test both properties. I needed a custom checker. Ohad, told me that this existed but is undocumented in the NonPublic api (Api’s for private members)

Sequencing

We have put a lot of thought in the sequencing logic of the Api’s to make it easy to read and write the test on one hand, but keep the test Robust on the other (Robust as in, the test passes when the production implementation changes, but not the logic). In this test I needed to call an API to setup the data, but the date needed to be yesterday. Then with the data acting as normal, I needed to call the code and verify that a new record was added.

// pretend we started yesterday
var yesterday = DateTime.Now.AddDays(-1);
Isolate.WhenCalled(()=>DateTime.Now).WillReturn(yesterday);
var underTest = new DataModel();

// back to today
Isolate.WhenCalled(()=>DateTime.Now).WillCallOriginal();
// This should add a new record for today.
underTest.Update(); 

This didn’t work and I had to put both the Isolate lines together:

// pretend we started yesterday
var yesterday = DateTime.Now.AddDays(-1);
Isolate.WhenCalled(()=>DateTime.Now).WillReturn(yesterday);
// back to today
Isolate.WhenCalled(()=>DateTime.Now).WillCallOriginal();

var underTest = new DataModel();
// This should add a new record for today.
underTest.Update(); 

This is bad since changing the implementation to call DateTime.Now twice in the constructor will fail the test.

Assert the times a method was called

While testing the save logic, I need to test for a race condition and make sure that the save is called only once. The save logic is called from the calculation logic that is periodically called (say once a second). Once the auto-save interval is reached a save is performed in another Thread (to make sure that the application is responsive).

var saveInterval = OptionsSettings.Settings.AutoSaveEveryMinutes;
if (stopWatchForSave.Elapsed.TotalMinutes >= saveInterval)
{
  stopWatchForSave.Stop();
  ThreadPool.QueueUserWorkItem(new WaitCallback(t=>
  {
    Save();
    stopWatchForSave = Stopwatch.StartNew();
  }));
}

But if the Save takes too long and the method is called again, the save will be called again.

To test this I need to make sure that the Save method is called only once, but this API is missing.

Bonus points goes to those who know how to solve this.