This week it was my turn. Reluctantly I committed to the task in the daily stand up and started testing the application. I found a first bug and a strange thing happened. It felt great to find a bug. I found 11 bugs that day and I felt great about it! Normally when I find a bug this is a demotivational thing for me, because someone (often me) didn’t do his job properly, someone (possibly me) has to find some time to fix this. Not fun.

But being “The Tester” changed the game. It was my task to find bugs. The team agreed that it was a good thing to find bugs. It was fun and felt productive and since I found lots of bugs it was productive.

My recommendation for today: Don’t just do the task, be the one in charge of getting this task done and getting it done well.

When her son made a mistake which resulted in loss of his queen and as a result loss of the game she said:

“I better don’t talk to him. I’d only scold him for his mistakes.”

My immediate answer was:

“Of course you should talk to your son! You should praise him for the way he played.”

This resulted in a blank stare.

Is this really so difficult to understand? When somebody makes a mistake, most of the time, they know very well they made a mistake. The chess playing kid knows he lost. He knows losing the queen wasn’t a smart idea. Often kids know this so well that they start crying. Trust me on this: There is no need to tell them what they did wrong. They’ll focus their thoughts on the things they did wrong. And this doesn’t help.

Instead tell them what the did well. A kid playing a game of chess most certainly made a couple of good moves. Your task is to find these moves. Or maybe he remembered to press the clock most of the time after his move. Or he used the available time well to think carefully. Or he remembered to shake hands and setup the board again after the game.

Praise him for that.

It will move the focus to the things he did well. It will turn his focus in something positive. It will motivate him to continue playing and learning. And sooner or later he will start taking care of his queen as well.

And the same applies when you are coaching grown ups. A software developer who introduced a bug knows he made a mistake. And he doesn’t enjoys it. Especially when it was a very damaging bug. chastening him doesn’t help. Instead find the thing he does well. Does a different module of him work well? Did he fix the bug quickly? Does he help his coworkers? Is he especially knowledgeable about a certain area? Did he improve some skills in the past months? Praise him for that.

You might think “But I can’t praise the people that make mistakes! That’s unfair”. You are wrong. You can. You should. You MUST. But of course you should praise the ones doing good work as well. The difference is: Praising the good is much easier and requires much less skill on your side. So if you have problems with praising, you might start with the good ones today.

Digging prohibited

Many companies lately come to the conclusion, that they have to do something about this social web thingy. But when I listen to the discussions, I feel like traveling back in time to the end of the last millenium, when everybody thought the web (release 1.0 at that time) was the way to print money. The news is: it wasn’t back then and it isn’t now either.

For two reasons I think this time it is even worse!

1. For many companies it isn’t at all clear, what they are trying to achieve.
And as we all know from our last motivational training: If you don’t have a goal, it is difficult to reach it. So what are viable goals in the social web world?

• Better customer service
• Better internal communication
• Higher employee satisfaction
• Higher customer loyality
• Higher visibility
• Utilize the long tail
• Higher sales

These are attractive goals, and each might get supported by leveraging web2.0 technology. But all the web2.0 stuff is just tooling. Which brings me to the second, more important point:

2. Many companies have to change a lot in order to become web 2.0 compatible:

• If a customer says it’s broken, it’s broken. Web2.0 is all about communication. One partner of communication is the customer. But if you do not intend to listen to what the customer says you might as well stop right now.
• If you want your employees to communicate, start by listening to them. Blogs seem to become popular communication tools for some managers, trying to communicate with their employees. But if you want your blog to be read you either need to get involved in the discussion in the comments, or you must write something that really is interesting for the readers. For both you must listen to the other side of the communication channel.
• If you want motivated employees, don’t give them the feeling, they are walking problems which you will get replaced by a piece of software as soon as possible. You would never do that? Great. Unfortunatly I have seen exactly that just to often. Processes requiring to write 200page documents, which get reviewed, corrected, approved and ignored. Organizational structures where a bright idea has less chances for growth then a snowflake in hell.
• If you want your customer to be loyal, you’ll have to give them a reason. A great blog is cool. Intersting tweets? Nice! But customers need products and services in order to become customers. And if products and services suck, the customers will notice and take the money somewhere else.
• Nobody works for free, including the authors at wikipedia. The impression that the authors of wikipedia work for free is a wiede spread illusion. They might not take money for their time. But they take pride in their work. If you are used to consider the employees of your companies as little more then slaves, you are heading for trouble with ‘the community’.
• Great products and great marketing still needs a lot of work. Just because you use Twitter for listening to your customer complaints, just because you use a blog to tell your customers about the features of your new product, just because the documentation has the form of a wiki, doesn’t mean there goes less work into it. Quite the opposite. Office times don’t exist on twitter.

If one point or the other matches the situation at your company, what are you gonna do? Forget about web2.0? Hell no, just embrace the change, because web2.0 will affect your company, better be ready for it.

By the way: For the readers wondering, why I am addressing them as if they where the manager of their own company. I am convinced that in a company that is ready to embrace web2.0 YOU are just as important as the management.

Comfy Chair

Some of the customers I am working for have an extremely crappy office environment. On the other hand the office we work in at LINEAS are rather nice. This contrast makes me realize how big a difference a decent work environment is. After all: how important can you and your work be, if you don’t even get a descent space to do your work. So if you are a boss who likes to treat the employees well, here is a list of ideas for you. If you are an employee in a crappy office space you can at least start dreaming.

• A good chair. No the best chair money can buy. The spine is one of the weak points of the human anatomy. And we software developers are treating it extra rough. Even extremely expensive chairs pay themselves once they prevent a couple of days sicktime of because of back problems. And these sick day come in batches of weeks or months.
• A table that can be adjusted in height so you can switch between standing and sitting position.
• Extra quiet computers
• 3 big or2 extremely big screens. Most of the time I work with two pretty normal screens (effectively 2980 x 1024 pixel) , but if I am forced to move to something smaller I notice the loss immediatly. So I think an effective  resolution of  4000 x 1500 should be pretty nice.
• Huge white board, actually I would like a double white board that allows to move one whiteboard way up, and write on the other one. Just like the blackboards at the university.
• Nice Bookshelf, 1 meter wide, floor to ceiling filled with books, I’ll compile the list of books later.
• Colleagues, two or three of the smart sort, for lively discussion about technical problems and the last ‘Dr. House’ or TED video.
• Window with nice scenery to the left from my place. Facing north, so no direct sun light.
• Coffee machine and printer on the other side of the (not to large building). Does walking there count as exercise? At least it will keep me from drinking 2 liters of coffee a day.
• A corner in the office should be separated a little by some plants. There I would a have a comfy chair and a stereo with head phone. It shouldn’t be to far from the book shelf.
• A phone with headset. Allows for working on the phone and on the computer at the same time

What did I miss? What should your office look like?

• Employees get extra pay for work on billable projects. Undesired result: If an employee is finished with her work she benefits from claiming to still work on the project instead of announcing availability for new tasks.
• Employees get extra pay for the ratio of positive feedback from customers. Undesired result: Negative feedback gets hidden, but the negative feedback is the one you really need to know about.
• Employees get extra pay for the success of their department. Undesired result: Fights between department about who is ‘owner’ of a project; Information hiding between departments.

So should we scrap all key figures? No, I think they are actually quite useful, as long as you never try to tie any kind of automatic action on a key figure that goes beyond some kind alarm, triggering somebody to look into the situation. It also makes the selection of key figures much easier. You don’t have to find a key figure which is fail proof (which you won’t find anyway). Another example: Key figures for Software Development. The aim is to get an indicator when something in the software construction phase is going astray. I propose the following key figures:

• Lines Of Code per man month
• Code Coverage in any of its flavors
• Toxicity

Of course it is a bad idea to base any kind of payment on the lines of code produced. Employees would use cut and paste instead of avoiding duplicate code. The inverse is equally bad. People would probably stop working at all. Yet if you find that one team produces half the lines of code than all the others it is worth a second. Maybe they creating extremely crisp code or they are just lazy, or encounter serious problems. Almost the same applies when code coverage or toxicity deviates from the usual values. If all three numbers evolve as you are used to from other projects, development probably evolves as you are used to. And if something unusual happens it will probably show in the numbers pretty soon.