Building the Management Team

Eli Lopian    Management for Geeks    

I have read an article about Building the Management Team on Entrepreneur. It gives a nice outlay of the management team, but I don’t think that it really helps with the real hard stuff. How do you know who to get and how do you make sure that you got the right person?

I have heard from many successful startup Entrepreneurs, that the one single, most important factor that they can point to, that lead to the success of their company, was their team. They all said that they where very lucky to get that team.

I don’t want to rely on luck! (I tried to do so in some friendly poker games, and it doesn’t work.)

So how do you build the right team?
Even after rigorous interviewing I have a hard time, really knowing it that person will succeed or not. Sometimes it worked, but most times it didn’t. I had to deal with amazing people that are just used to a different mind-set, some were used to huge budgets, some were used to off line marketing, some were used to being told what to do, some just loved making excuses.

After failing with this for too long, I noticed that I stopped interviewing, because I felt that this doesn’t really help me. I understood that I had to change in order to get the right people.

Using Integrity Management, I made it my number one priority, to find the right people. I had to take the risk of doing uncomfortable things to find these people. This meant that for every job I looked for, I learnt exactly what actions are needed to be done to get the job done, I got experienced by doing the actions and not just reading about them. After I found someone, I managed the employees integrity to see that they are actually doing their jobs. If they had no integrity, they had to go elsewhere. This is a slow process, but I am obsessed with succeeding to build the management team.

I can say that currently the Typemock team is an amazing team, we still have a long way to go, but the one single, most important factor that has made Typemock what it is today, is our amazing team. Thanks.

(Cylon picture from Jeff Pidgeon)

Throwing the Boss Out…

Eli Lopian    Management for Geeks    

Jurgen Appelo has a post: Optimize Communication, Throw the Boss Out. It is great that Jurgen is writing about this topic, as I have been trying to tackle this for some time now. Here is what Jurgen asks

How do you align many teams to work towards a common goal?

My take is that you just have to tell them what the goal is and ask them what they can do to help.

Your employees are clever enough to figure this out themselves. We don’t need managers to point us in proper direction, we need managers to show us how to grow, that can show us that we can do more then we even thought that we can do.

Here are my requirements for an ideal organization:

1. Everyone is 200% responsible for what they have to do on their own, but they have to commit and have integrity to the team.
2. Teams are formed around goals (not expertise)
3. The manager must have full understanding of the type of work being done. (I talked about this in the past)
4. The hierarchy size is less important then the flow of information. All dilemmas (not problems), must reach management.   

This way will lead to an organization where the managers are servicing (helping solve dilemmas and helping each individual grow) the employees and not the other way round.

There is no need to have functional managers, if the team need technical help, they will have to find a way to get the guru to commit.

We need managers to help us reach our own goals not Bosses.

Beyond Scrum and Lean

Eli Lopian    Management for Geeks    

Both Ron Jeffries has commented on my Event vs Polling ideas and so has Travis Illig about having fun with status meetings.

They both use the same argument: We use Scrum standup meetings, we ask what we did, what they are going to do and what is stopping them. This is enough information.

I am all in for doing Scrum. I have had my fair share of waterfall development, XP and Scrum, and Agile is far better then the waterfall ways.

The stand up methods and scrum are great for putting some order in a complex and changing environment. But there is a small but important issue, it is too easy to focus on giving excuses.
Why didn’t we do what we promised: Well the build server didn’t work and we waited for IT to install our system, but they didn’t come. We can always find reasons for what is stopping us.

Stop giving excuses

I hate excuses, they don’t help at all.

I call focusing on solving problems and living up to your word: growth.
Its the ability to do get better and better at what you are doing. It is not waiting for IT to do things but learning how to do something about it ourselves (notifying management of the delay so that they can help is also doing something about it).

Lets see what happened to Travis (you can read his comment, I am going to use Travis as an example here, but it could be any team lead). Travis is on many teams, and he needs to go to many different stand-ups, so Travis is polling the teams, to do this the standup have to be as short as possible because it takes up valuable time, so no problems are solved, just raised. Also notice the complexity that is happening here, the standup now have to be synchronized so that people who are on a few teams can be there.

Turn the tables

Lets see what will happen if we did something else, lets do it the other way round. Instead of polling and trying to get information and finding different ways to share that information. Lets have a system that the relevant information is pushed to the right place at the right time, and solved swiftly.

Here is one way how. I call it Integrity Management.
The hands on employees are the ones that have the most knowledge of what is working and what isn’t. We want them to choose what information is relevant to push.
In the weekly meeting each team lead commits to what they will do that week. This is a commitment, not a “we will do our best” or a “we will do the highest priority” but a weekly commitment.

There are daily standup’s within each team, but Travis doesn’t need to be there, because once a team knows that it is missing its mark, they tell all the team leads. Travis as a team lead gets the ‘event’ and can help the team find a solution (Call it a Just In Time Information, why poll all the time?). Travis can then mentor the team on how to solve these problems, and can even ask them commit to doing those actions. In our example, there is an event that team A is behind schedule because of an IT problem. We can ask the team what they can do to solve it, and they might come up with a few solutions: (Note that they are all controllable actions)

• We can nag IT again
• We can do it on the old machine
• We can install it ourselves

We can then help choose the correct way. This helps the team grow because they actually brought up the solutions themselves.

This is great, but Travis still has missing information, suppose the team decided that instead of waiting for IT, they go and do it on the old machine. Here is where talking about Dilemmas works wonders. Once the team lead says in the following meeting, “We didn’t want to wait for IT, so we decided to do it on the old machine”, Travis can point out that there is a better way to do it, but hey, they did manage to do their job! And now other teams know how to solve these problems too.

Using Integrity we focus on solving problems, not raising them. Did you know that 90% of the problems we raise in Typemock Management Meetings are solved in under 10 seconds. Either some other team member helps out, or if it is complex we meet later but we have to come with several solutions too, and these are solved quite quickly. Sometimes, the complex meeting never happens because the team solved it already while thinking about the different solutions.

Become a solution oriented organization. Focusing on solutions, will help your team grow. Integrity Management helps you focus on solution making.

Safe is Risky

Eli Lopian    Management for Geeks    

These are the words of the original Purple Cow himself, it’s risky to be safe. I love it. It is really risky to play it safe!

So why don’t we take risks all the time?

Taking a risk means that we know that we have a chance of losing something. So we refrain from doing anything because of fear of losing. So we don’t ask the girl of our dream out for a date because we fear rejection, we don’t bring up our great idea in our company meeting, because we fear of being laughed at.
We know what this will lead to: Your dream girl will never go out with you, because you never asked her. You will feel that your company never listens to you, and that they might fire you, because you never bring good ideas to the table.

Playing it safe is risky. You will lose if you play it safe.

There is a small experiment that I do, to make sure that I am not playing it safe. I do the annoying, uncomfortable things.

Staying in my comfort zone eventually leads to non-comfort. Safe will lead to risk. So I do the annoying and uncomfortable things that will eventually lead to comfort.

When I feel that I am not confronting an employee because I don’t feel comfortable doing it, I go and confront them. Think about it, if I don’t confront them, they will keep on doing the same annoying things, this will lead to me becoming even more uncomfortable. When I do confront them and take the risk of upsetting them, then they probably will stop doing the annoying thing.

When I feel that I don’t really want to unit test a specific piece of annoying code (because it is hard to test), then that code will have bugs, and I will be uncomfortable fixing it, because there are no unit tests. When I do the uncomfortable and unit test the code, then the code becomes maintainable and I become comfortable.

Where have you taken a risk, where have you left your comfort zone today?

Status meetings can be fun

Eli Lopian    Management for Geeks    

Status meeting can be really boring. Actually they are normally a waste of time. I have been to many long status meetings where the manager drags everyone through everyone else’s tasks, task by excruciating task. As some people say: Status is for Reporting not Meeting. 

On the other hand, as we are working as a team it is important that each member know where the team stands, so that we can work better. The sales team must know if a promised feature will be implemented or not. So when I asked the team if we can do away with the status meeting, I got a big: “No, we need it.”

I have also noticed that some people like to show how much they did, so when asked what is the status, they just go on and on about all the micro-tasks that they managed to do. It has taken me some time to reach my current thoughts (together with my coach) on how to spice up this meeting, and we are still experimenting with it, but here is my current take.

Discuss dilemmas

Explain your dilemmas, go beyond the normal “done/not done” status.

So when we talk about statuses, each member says if it is done/not done. (If it is not done, the group should have known about it already). Now we talk about one dilemma, here come the juicy part, the interesting part. The team learns from this story, how we make decisions, what challenge we have overcome, what breakthroughs we are making, and this gives a lot of insight into our processes. Remember we have no tolerance for excuses, as those don’t help at all, so the dilemmas are always about solving our challenges.

I have tried many different ways, currently this way changes the status meeting from a waste of time to priceless. How do you make your status meeting priceless?

Why do we ignore your arguments?

Eli Lopian    Product, Release    

With the release of Isolator Version 5.3, we have added the ability to simulate external components based on the arguments passed to those components. We called this Conditional Behavior.

Our default is to ignore arguments, to fake a method without taking the arguments into consideration, neither the number of arguments (overloads) or the values of those arguments (conditional behavior).

There is a reason for this.
Lets see the values with which we create our API’s, taken from Roy’s post

• Consistency
• Discoverability
• Explicitness
• Single point of entry
• Readability
• Single way to achieve things
• Backwards compatibility

The value that I want to discuss is Explicitness: we decided early on to be as explicit as possible about the API, so that the least guessing needs to take place by the user

So how do we decide on our defaults?
We fight about them, we find out what will need the least guessing, but keep the tests short (Readable)?

We talk about what most users mean, what most users expect.
We talk about failing fast when writing the code and we talk about Brittle vs Fragile when running the code.
We argue about what default usage will break if the user changes (refactors) the production code, without changing its logic. We want those tests to succeed.

This is ultimately why we ignore the arguments, so that changing a value passed to a method or using an overloaded method instead, will not fail the test.
Those cases where the difference is required, are discoverable while writing the test. The test will fail fast, if an overloaded method needs a different behavior, or if the method acts differently based on its arguments, and that will allow the writer to add the conditional behavior.

The journey from an Inventor to a CEO

Eli Lopian    Management for Geeks    

When I started Typemock I was the Inventor, it was great fun, I did everything from developing to marketing to sales. I worked until 4:00 am learning and discovering and it was an amazing time.

Typemock started to grow and I had to bring in more people to help me, it started with support and then development.

But bringing in more people didn’t really help me, it didn’t really clear my time to do other things, the opposite, I found that I was the bottleneck of the company.

This is what I thought a company should look like, the manager is on top, he tells the employees what to do, and they do things that will help our customers.

But it didn’t work this way. I had to tell the employees what to do, the employees kept on asking me for help, because they didn’t know how to solve their problems, which in turn made me solve the problems.

The company actually looked upside down, I was at the bottom, the customers where requesting my help in making unit testing simple and the employees where asking my help to finish their tasks.

The employees where managing me, and although I was telling them what to do, they kept on returning the problems to me, I was doing code reviews and support and sales.

Lets take a salesman for example. At one point, there where so many sales that I needed help. I decided to employ a salesman. I had the notion that I must employ someone who knows how to sell, so I must get the best sales person I can. It took me 4 months to find a sales person, and once he was on board, I told him. “Ok, here’s your quota, go and do your job”. This never worked, the sales person spend a week on our CRM system, and after a week he said. “I can’t work with this system, it is really bad”. When I asked why, the employee told me that he can’t add the products to the sales. So I went and showed him how to do this. But this didn’t really help, the guy kept on coming back with problems, some where really simple, some where complex, but instead of taking the load off of me, I found myself in his office helping him all the time.

This was about the same time that I decided that I need coaching and the first thing that Moti the coach told me was that the company is upside down. And that I have to build a strong supporting system to make sure that the upside down pyramid does not topple down

I needed to build a strong management and to learn how to delegate correctly.

I started using the Integrity techniques to try and turn things around. I started asking the salesman, what can you do to help Typemock? Can you commit to this? Are these Controllable actions? But because I didn’t know myself what actions where needed to reach the goals, the salesman also didn’t as he was used to a completely different sales cycle. After much frustration, we departed. I sent 4 months searching for this person and 2 months working with him, and it didn’t work. This was really depressing.

I had to learn how to do this correctly. I had to do the sales myself, I spent a month doing all of the sales and learning about it, learning about what works and what doesn’t. Only after I understood what actions are required to make the sale, did I look for a salesman. Now that I knew exactly what was needed to be done, I could get the right person for the job. With that person, the knowledge of the sales process and Integrity, I have the right tools to build the management, and create an amazing company.

200% Responsibility

Eli Lopian    Management for Geeks    

When something is really important to us we must have at least 200% Responsibility. 100% responsibility is just not enough.

With my children for example, 100% responsibility is not enough, when I cross the road with them, both myself and my wife are on the look out.
This is because when 2 people are responsible for something, it is too easy for both parties to let loose and tell themselves that “The other party is responsibility” leaving no-one responsible.

The same applies to other things in life. Unit tests for example, is very important that is why we need at least 200% responsibility. Everyone is responsible for all the tests to pass. If someone sees a failed test – fix it, don’t look for the responsible person.

I think that the opposite of a Responsible person acts like a Victim:
”Oh, the tests failed. That is because: The build server is faulty, Bob in not professional, My PC isn’t fast enough. It is not my fault, I am a Victim of the circumstances, its their/his fault”

Lets see the difference in behavior between a responsible person and a victim.

Check yourself. How many times have you heard other people, or yourself, say: “I Must lose weight”,”I need to stop smoking”,”I must write unit tests”. Lets read between the lines, what they are saying is. I don’t intend to do it at all. “I Must stop smoking… but not today”

You have probably met advisors, or you might be one yourself: “You must sell your stock now, you should buy now, you should do this, you should do that”, these are victims. A responsible person will check the stock market, learn how it works and decide how to save himself instead of telling others what to do.

A victim will complain all the time, while a responsible person will check his boundaries, learn and try new things.

200% responsibility

So how can you become responsible. Ask yourself, what can YOU do, and tell others what you indent to do. Live with integrity. The only way out of being a victim is by taking responsibility.

200% responsibility

The difference between GTD and Integrity

Eli Lopian    Management for Geeks    

Getting Things Done (GTD) is an action management method created by David Allen. It is based on the principal that we have to get things out of mind by recording them, so that we can focus on the task at hand.

Following are the differences between GTD and Integrity based on GDT principals.

GDT Core Principals

Collect

In GTD, we need a place (bucket) to dump all of our tasks.
In Integrity, we start with the monthly goals and find the controllable actions we start with the end in mind and leave out everything else.

Process

In GTD we take the task out of the bucket one by one and either do it if it takes 2 minutes, or delegate it, or defer it.

In Integrity we commit to the actions we will perform at the beginning of each day and week. There is no deferring or delegation per-se

Organize

GTD, there is a great need to keep track of tasks: Next Actions, Projects, Waiting For, Someday/Maybe. Filing them and searching for them is key.

Integrity, we keep a white board of the task the each person committed to. No need to keep track of what others do, or to wait for them, it must be committed by yourself or others. It is event driven and if a task is postponed, you can act to rectify it

Review

GTD –Daily and weekly, private review

Integrity, There are set group meetings daily and weekly. Committing to the group and not in private.

Main differences: Filing System

While GTD put a lot of focus on storing the tasks, Integrity focuses on doing the tasks required to reach a goal. Integrity has no need to file tasks, and to keep track of delegated tasks. The process is event driven and when a task (goal) is delegated, there is no need to track it, and to ask about it, or to wait for other people to finish.

Although this it is true that if everyone had integrity, there won’t be a need to ‘wait for’ tasks, but as we deal with other vendors and customers who don’t manage their integrity, we need to keep track of these, and using GTD is a good way to do it, especially since there will be a lot less of these tasks.

The big difference in my view is that with GTD there is no team work, no team commitment, and the delegation is brittle. It becomes too easy to be caught up on the periodical checking or deferred and delegated tasks.

Event-Driven vs Polling

Eli Lopian    Management for Geeks    

We had a short discussion in the office about my post about the difference between Scrum and Integrity.
The discussion was:

“I don’t understand, there is no difference, we do exactly the same things in Scrum and in Integrity. The Customer will know after the sprint what we managed to do.”

This is exactly the difference. The customer will know only AFTER the sprint, when there is nothing left to do except find excuses why we didn’t meet our commitments. I must point out that scrum and integrity don’t clash and they work together well. But the focus is altogether different. Scrum is about how we, the pork-developers, can perform in a complex and changing environment. The customer/manager can come into our den and look at the Burn-Down Chart (What?! you don’t know how to read it?), and know where we are. That is their responsibility, not ours. Leave us alone to do our jobs.

Integrity is about responsibility. We know that you will do your best to get the job done. But we can’t afford to wait until the end of the sprint to tell the customer, “Sorry, we are developers and we did our best”. This doesn’t cut it. Excuses are cheap. Be a man and tell everyone involved that we won’t make our commitments as soon as you can. (Yes, I know that you still believe that in 5 hours you will be able to finish 50% of the tasks, but in reality you know we can’t)

Guess what, once you start doing that, your managers and customers will be able to make a decision in time, and that will allow them to help you, You the developer to keep your commitments.

This is the reason that we don’t allow to warn about ‘not making it’ a day or two before the deadline, we have to get the warnings way before, that will allow the customer and the management to help reach our goals.

The astute reader will notice that using Scrum, the customer/manager must poll the development team while Integrity is an event-driven process. We all know that polling wastes more time and energy then event-driven systems.