Innovation: Not “what if” but “how can”

Eli Lopian    Management for Geeks    

Zane Safrit has a post about innovation: Innovation Key: Asking “what if”.

Although “what if” questions might work, I have found that they support innovation more than they create innovation. What I mean by this, is that you must already have the innovative idea in mind, to ask the “what if” question. “What if, we try this new way”, we already know the new way.

“What if” is not a question that creates innovation. Asking “how can” is a question that does lead to innovation. “How can we unit test this code?”, ”In what condition, can we unit test this code”. Now we can think of ideas and start asking “what if’s”

Although “what if” is not a question that creates innovation, it is very powerful at allowing other ideas to exists. It comes down to two basic paradigms

The Either/Or Paradigm

The Either-Or paradigm is something that most of us have been brought up with, it starts with our parents: “Either you clean up your room Or you won’t be allow to watch TV”. This is not an allowing paradigm, it is a paradigm that says, you have to do it my way or the highway. Most of our training uses the Either/Or paradigm as it is a strong logical paradigm. “Either you pass the test or you won’t succeed in life…”, “Either you go to university, or you will not find a good job”

The Both/And Paradigm

The Both-And Paradigm can allow several ways to co-exist. It is possible to Both clean up your room and watch TV. It is possible to unit test this code by rewriting the production code or by using great tools. It is possible to have a great life without going to university. “what if” questions are a great way to open the opportunities and to move from an Either/Or paradigm to a Both/And one.

So ask “how can we do this” to get ideas and “what if” to allow them to co-exist.

Scrum and Lean are just an excuse for our failing profession

Eli Lopian    Management for Geeks    

To build the team that Typemock needs we need great developers. I don’t mean craftsmanship or pragmatic developers, we need super stars.

Have you noticed that some developers are so much more productive then others? How can I make sure that Typemock created and attracts those kinds of developers?

As a profession we are still failing, take a look at the latest chaos reports, our numbers are worse. The number of startup and project that are failing is raising. What are we doing wrong?

Is Agile a process or an Excuse? There was even a session about this in Tech-Ed.

Perhaps we are not bold enough to leave our comfort zone, we just keep on doing those things that we where once good at, and this leads to mediocrity. Practicing one process will not make you a super star, be it waterfall or Agile. It will teach you how to do things in a different way and then enable you to crumble back to mediocrity.

We have to leave our comfort zone at all times, have a new challenge every day, commit to them, have integrity, raise the bar, try different things, focus on actions and not on results, dare to fail and stop waiting and making excuses.

Perhaps Integrity Management will help save our profession.

Clearing, the next stage

Eli Lopian    Management for Geeks    

I talked about the great effects of the clearing process that we do in  Typemock. This process allows us to pinpoint areas that are not working, fix them immediately (by committing to controllable actions) and then to focus and celebrate on the things that do work.

Clearing is actually a state of mind. It turns out the people wait for the clearing to do the retrospect and to find solutions. But suppose you come to the standup with the solutions to your problems. Suppose you don’t only tell everyone about your problems but give 2 different solutions, you can even tell the team what you prefer. Just take 5 minutes before the meeting and come up with the solutions, wouldn’t it make the meeting more valuable. I think so.

If you can do that, why not go another step, why not find the solution yourself when the problem arises and they start executing your solution. You can then talk about it, in the “What is working” stage. This is how you can move your problems from the “What is not working” stage to the “What is working” stage, talk about it as a dilemma that you solved. 

If we all do this, we can come to the meeting clear, we can solve it before the meeting, your manager does not need to be the bottleneck of solving problems.

Loosing sight

Eli Lopian    Management for Geeks    

Because Managing by Integrity makes sure that we play one game at a time, day by day, by creating controllable actions for each goal – we separate ourselves from the companies goals. This can lead to separation from responsibility. We did exactly what we said we would do, so we are in integrity, but there are no results.

For example, if we have a goal of finishing a piece of software but our controllable actions are to play foosball, we can be commit to playing foosball all day and be in integrity, but we won’t see any results. 

This is not good, there must be a good balance between 200% responsibility and focus on controllable actions. It is everyone’s job to make sure that the actions we are doing do actually lead to the desired result. If in doubt, make sure that you are leaving your comfort zone and trying something new.

Flowers, Game Theory and our Company Culture

Eli Lopian    Management for Geeks    

I had a great discussion the other day with a Professor who specialized in the  Game Theory. We had a nice discussion about flowers. Flowers compete for bees (guess why?) each flower can balance how much energy is put into its marketing (the colors, flowers, smell) and how much into its sales (the quality of the nectar). I really liked the discussion and some results are really interesting, for example, it is possible to predict which flower species thrive when they grow close to each other, and which fail.

But what really interested me was our discussion on Company Culture. The professor (who is also an investor and very much into business) put a lot of focus on the company culture. He told me that this is more important than the marketing or the product, because the marketing and product can change but the culture, the DNA of the company is very hard to change.

So what is the company culture of Typemock.

Off my head here are the values we value.

• High integrity workplace
  (empowerment, teamwork, responsibility and accountability)
• Getting things done attitude
• Strive for excellence and personal growth
• Customer-focused
• Learning by experimenting and measuring

Specialization is for Insects

Eli Lopian    Management for Geeks    

I have been talking about team work with my team lately. It seems that a common issue that comes up, is specialization.
Everyone has a place, everyone is a piece of the machine, each piece should know what to do, and they should all work in perfect synchronization.

I know that this is the common belief, it just doesn’t feel right to me.
As I always give examples from sports teams, the team keeps on giving me the example of football (soccer) in which each player has his place.

Then I saw the amazing game between Barcelona and Real, and I noticed that what makes the former the best team in the world is that every player can do all the different jobs.
The defender Gerard Piqué run from his defense position to help the wingers then continue running to help the strikers and score a goal. Amazing.

This is what an exceptional team looks like, there is no specialization, to be the best team, everyone must know and be able to do all jobs. This will allow them to understand and learn a new point of view and be able to fill in. 

A developers must be able to do other jobs to become exceptional.

I had a casual talk with a developer. He said that he would never do a QA’s job, it boring, below his honor, he would do all he can not to do it. In his company they sometimes had to do a week in QA, but he would not do it, he would just sit around and not do it. No wonder developers are becoming sloppy and allowing bugs to flow to the QA team.

To become an exceptional, you have to understand the other parts of the system, and to do that you have to do it yourself.

Trying, to become aware

Eli Lopian    Management for Geeks    

There are a big difference between awareness and alertness, it also has a big effect on how to accomplish work.

Awareness: having or showing realization, perception, or knowledge
Alertness: watchful and prompt to meet danger or emergency

I think that alertness come before an event happens to you. We are alert and watching out for something to happen. We can be alert of the difficulties of riding a bike. In software development, in the coding stage, we know that the design is important so we are on alert. When we create an API we are on alert for ease of use issues.

Awareness comes after the event, there is knowledge there, after the event we know. After we tried riding the bike we know that we are safe (or if we fell down how not to ride). In development this is after we tried coding, and are now aware of the design issues (which we can fix via refactoring). Or after we tried several api’s on the computer (in our tests)  and we know which one is easier.

I found that I get stuck on the alertness stage too often, I am aware of a problem and I am thinking of several solutions but I am basically before the event. When I try, I cross to awareness, I understand what I did and how to do it better.

So to gain knowledge I find that I have to try,try and try again (yes, this does entitle leaving your comfort zone). I spend too much time thinking and talking about the problems.

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