The Human Factor in Software Engineering

Each half-year, I write 2000 emails. This makes 20 per work day. Isn´t this crazy? No, I am no call center agent, I am a knowledge worker. Team work creates such an amount of communication. I apply some Best Practices for reducing the amount of emails written:
- ask less questions: Sometimes, it is attractive to just ask a stupid question in order to get the email and topic out of my mail box and send the ball of action to someone else. Until he answers my stupid question, I do not need to do anything about this topic. But, of course, the ball will return in the form of an answer. And this will force me to act anyway. Why not spare the world useless questions and just decide myself? Many people are not so fond on answering questions and making decisions, so my stupid question just creates work and stress on the other side.
- clear responsibilities: Sometimes, you do not mind who out of three persons answers your question. All you need is an answer. The problem is that the more people you send the question to, the less they will feel responsible for answering. Why me? Someone else will answer... If you want to triple the probability that you get an answer, then you must write to three persons individually, not by the same email.
- Tracking: 50% of all questions and tasks I send out by email go to the abyss. Some people´s inboxes are black holes where messages disappear. So, you can not trust that if you have asked a question, that you get an answer. Therefore, I track when I sent which question where and do not hesitate to repeat my email two weeks later. It is even better to contact the other on another medium like phone or just popping in his office or being in the kitchen at the same time.
- do not talk about others: If you have something to say to or about someone, do not create complex forward chains. When Alice asks you who has the book about X, and you believe that it is Bob, then do not do this: ask Bob, wait for his reply to forward it to Alice. Instead, tell Bob that Alice wants to know it, send Bob her email address and tell him to answer to her directly.
- answer emails within 24 hours: In one company where I worked, we had the order to answer each email within 24 hours. Such an answer can also be an out-of-office reply or the information that I will answer next week because I am currently on a training or because I must ask Bob and he is on vacation.
- keep promises: When you do not keep to the promises you made, you need not wonder that you get avoidable emails - in the worst case going to your boss per cc. (No good style, but more painful for you than for its author.)
- no preliminary information: Do not send intermediate versions of documents or preliminary information, except for very rare cases where someone is very eager on receiving information fast, even if it is preliminary. Do not send a new version of the same document every 6 hours to everyone. Because then, people will not read any of them, they just can not distinguish between main releases and mini changes.

In my former research, I showed that goal-oriented self-management leads to detrimental side-effects. Now, I work in a company that practices goal-oriented management. Recently, I experienced one of these side-effects. One of my objectives is to submit a certain number of research proposals this year. Now, I have a research idea that is not much more than an idea and a draft, we do not even have testbed partners for the evaluation of our idea. And the research partner will be on vacation the next two weeks. The deadline for the submission is 15th October. So, what alternatives do I have?
(a) To write the proposal all alone, what would have been feasible, as I write fast. But the consortium would be not very convincing and they would probably also not be convinced of what I wrote because they had no occasion for contributing their visions. Consequently, the probability of success would be low. I expect that the project either would not be funded or it would be funded but would shipwreck. However, I would have added one point to my proposal count.
(b) There will be another deadline for this programme next spring, so we can now take our time to discuss and find the right partners, and then submit half a year later. The idea is great, and we will probably be successful then in all respects. This is better for the company, but I will personally pay for having taken this decision. I will earn less money because of this.

A system that forces me to pay with my own salary for taking decisions that lead to a better success of my company, that is quite perverse. I believe that work life is such a complex system that conditions or criteria for success can not be expressed by a handful of key performance indicators (KPI). Such criteria indeed steer decisions, but this can go in the wrong direction, as in the example above. And I could tell more of these.

Of course, one could argue that I must have failed earlier, if two weeks before the deadline I realize that there is a problem. Well, I saw the problems approaching long time ago, but it was not in my hand to organize the consortium. There were several delays NOT caused by me; I did even worked on free days when it was my turn. That´s one unjust factor in this objective: The number of submitted research proposals does not depend on me alone, it is teamwork.

PS: The publication which I wrote about the effect of KPI is in German, see: Herrmann A (2009) Wie KPIs auf Entscheidungen wirken: ein explorativer Selbstversuch im Zeitmanagement. Metrikon 2009, Kaiserslautern, Germany

My name is Andrea Herrmann. My exciting and adventurous work life has led me through many jungles and over many seas. For 7 years, I was sweating as a consultant and project manager in software and consulting projects. The other 9 years, I have been working as a scientist and in University teaching. I am now a private lecturer at the University of Heidelberg. Next semester, I´ll teach Project Management again. I am still doing some private research. My main job (this means: the one that pays my living) is at a company where I am the Research and Innovation Manager. Yes, it IS exciting. I am creative one hour a day and the rest of the day is real work, like writing consortium agreements or project reports. I am writing a lot anyway. Currently, my book about communication is growing, and there are also some nice little novels around. And now the blog.

Dies ist also mein Blog zum Faktor Mensch in der Software-Entwicklung. Das ist ein ganz guter Obertitel für meine Lieblings-Themen wie (ir)rationale Entscheidungen, Requirements Engineering, leichtgewichtiges Projektmanagement, Zeitmanagement, Kreativität, Sicherheit und Qualität sowie emipirische Forschung. In diesem Blog sammle ich die besten Fundstücke aus meinen Literaturrecherchen sowie eigene Forschungsergebnisse und Gedanken.

This is now my blog about Human Factors in Software Engineering. This is a suitable sup-title for my favourite topics like (ir)rational decision-making, requirements engineering, light-weight project management, time management, creativity, security and quality as well as empirical research. In this blog, I gather the best nuggets from my literature research, own research results and thoughts.