Virtual Teams and Software Development

I have finally found the time to read this discussion topic about working from home. I’m proud to say that I actually read every letter, because it’s a long topic.

The subject is very interesting to me because I spent approximately one year working from home in a virtual team. Virtual team developing software. For me, it was unpleasant, and maybe it will not be an exaggeration if I say: a terrible experience from both personal and professional side.

I don’t want to write about personal problems because in the discussion referenced above, all my problems were mentioned at least once. The way I see it, this is probably the best summarization.
Instead, I would like to describe the problems that we had as a software development team trying to make something as a joint effort; the reasons why we underperformed, missed all deadlines, lose significant number of employees (including me), weren’t able to successfully integrate any new team members etc.

People are different: some who took part in that discussion obviously experienced positive impact to their personal life. However, I couldn’t draw a general conclusion about the nature of work those people were performing. It is hard to imagine that any of them worked in a team whose every member worked at home alone.
The crucial thing also is to have a well defined output. All successful teleworkers I’ve seen so far have had strictly defined deliverables which, as such, could be measured (read: paid ;)). Virtual teaming is something else. And software development might be the last place to exercise it.

Background:

• 7-8 people gradually moved from office to home. At first, only some of them started to work from home and after few months everybody was working from home.
• This was not an accident but a company strategy. Project manager, who was also a CEO of the company, expected better results from our work. The assumption was that we would be more productive as individuals, working in a peaceful, domestic environment.
• All team members were familiar with each other, since we worked before under “normal” circumstances. We were all from the same country; speaking the same language.
• We used IM, Skype and regular phone for communication.
• We used wiki (namely, Flexwiki) for documentation exchange and processes description.
• We used SourceOffSite (had bugs but we were grateful that such product even existed at the time) to enable web access to VSS.
• Face to face meetings were rare. Never more frequent than once a month.
• Previous company experience with teleworking was the following: some people worked from home and they were very successful. Type of work they performed was either a) work on helpdesk or b) working on products which were mainly their own responsibility.
• Working time was 100% flexible. Everybody worked when they found suitable; sometimes not overlapping with others at all.

The only thing I found beneficial about virtual team work is that it is actually (and sadly) easier to talk to some individuals over IM than in person.

And now a list of things that went wrong. The most important, of course: incredible problems with communication in many aspects. Most things from the list bellow are related to communication.

• Unbelievable amounts of useless, inconclusive IM communication. The problem was that we approached each other with simple questions but the issues often turned out to be pretty complicated. After half an hour of futile discussion we would realize that it would be better if we talked by phone – but the time was already lost. After a while, every time I had a question for someone, I felt physical pain prior to clicking his name in the IM window.
• Problems in communication and work between team members were not easily tracked by project manager as they would be if we were in an office. People were not talking to each other and nobody knew about it!
• There were people who had to work intensively together on some tasks but were never “at work” at the same time. This means, if I needed someone to do something for me and he was in the “night shift” I had to wait for the results until tomorrow morning. If people work when they want, they will have their own schedule because we are all different. Chances that we will all be present at the same time are almost equal to zero.
• Using wiki for document sharing was extremely painful experience. On more then one occasion I have lost hours of work. It just happens, sooner or later.
• Face-to-face meeting were opening too many questions that piled up over time and remained unresolved. For this reason, these meetings lasted for hours and hours but with few significant outcomes.
• Project manager became very suspicious about everyone’s working habits and most of us were offended by that as we knew that if we were really not doing our jobs – he would hardly find out about that. Some people were working there for years and with significant results and this behavior was really a slap in their face.
• Interruption problems remained the same as in the office. We were at home, yes, but with IM icon blinking every 5 minutes, one can’t say that there is no interruption. It’s too easy to click someone’s name and ask something and as you have 6-7 people doing that – there will always be some blinking going on.
• Joint discussions over Skype multiple person chat were Monty-Python-like events. Often incoherent parallel discussions about all kinds of unrelated stuff.
• Project manager’s personal flaws were really surfacing since he didn’t have satisfying overview of the project status. This of course had bad impact on everyone’s motivation and work/job satisfaction.
• Integration of new employees went very slow. We never saw those people in person. I’m not saying that it’s impossible, but went much slower than those times when we were in the office.
• People received far lees credit for their work than they should have. Project manager was not able to determine what their contribution to the project is.
• Even when it was obvious that things are not going very well, the decision about working from home didn’t change.
• At the moment when I left the company, only 3 full-time employees were still in the team.

Consequences for me :)) ...

• I hate wikis of any form. I like them only when they are read-only. Especially when I see those white-yellow screens of Flexwiki. I could get a heart attack.
• I rarely use Skype, also bad memories. I know it was not meant to be used primarily as a chat but now what can I do?
• I avoid working from home in my current company, even if it is for one day and even if it is really better for me. I never take work home; I stay in the office as long as it takes to finish everything.

And now seriously, my question to anybody who had any similar experience: did this fail because of bad management or would it fail anyway if the management was good?

I think that even if it succeeds to some extent, no matter how good the management is, it's much harder than with "normal office team" of equivalent capacity. A million years of communication evolution (verbal, non-verbal) suddenly flattened to chat and phone cannot stay without punishment. Also, the discipline and formalities in software development processes become very important in this case and they take significant effort.

But hey, to quit the job using Skype is really a story for one’s grandchildren! (I'm kidding, it's really a worthless experience! :))) )

Some resources about the subject:

Theory: http://www.answers.com/topic/virtual-team

A study: virtual teams with students building some piece of software. It is mostly about behavior of people who were in the team. However, they had two professors leading them, and not project manager with his own issues.
http://heim.ifi.uio.no/~sundeeps/publications/SarkerSahayJAIS.pdf

Some advices:

• 1
• 2
• 3
• 4

Which One of You Guys Is Leading This Project?

Last week an interesting, sad and funny conversation took place between my colleagues and me.

I have a colleague that came to my company a few months ago. She is working on the same project as I am from the first day she came to the company. (Occasionally she works on some small tasks on antoher project .)
And so, during the break, a few of us went for a cup of coffee to the nearby cafe. We were again (unfortunately) discussing everyday company issues/problems. In the middle of the conversation about the project we are working on (I can't even remember what this conversation was about) this colleague told me:

"You should decide about that." (... whatever it was ;) )
I said: "Why?"
She: "Why? Because you are leading this project."
Me: No, I don't.
She: "Then who is?"
Me: "XYZ is."
She: "OK, him too. But you lead it also. You are doing it together."
Me: "No we don't. It's just him. He is the project manager and the team leader. Officially and unofficially."
She: "OK then, I didn’t know that..."

I will not comment this because it happened to me and not somebody else and it will look like I’m bragging. But there is something seriously wrong with this picture. And even though it's funny, it's not difficult to guess what the status of the project is.

Reasons Why Someone Would Want to Be a Project Manager/Team Leader

In my experience not all people have the same motivation for becoming team leaders and/or project managers. Their reasons may vary a great deal and often have significant impact on project outcome and especially team atmosphere.
To be honest, I didn't prepare 10, 13 or 39 reasons but I will try to remember as many as I can... Maybe later I can count them and change the title. ;)

I will also try to comment on particular motivating factors in respect to personal, project and company benefit. If the project benefits from something, this can only be temporarily - until the project is finished. Later, however, some people may quit their jobs and leave the company (as I did once, for example) because of project manager’s behavior. So in the long run, it is not a good thing for the company. Personal benefit covers the impact that a particular motivating factor has to both future professional carrier of project manager himself and the respect he will get from his colleagues in his later work.

"I'm the best developer around here so I have every right to lead others."
Project benefit: If this is a true statement, than it’s a positive thing to have someone who is skilled in technology. However, it does not at all guarantee that other necessary skills are present. On the contrary, they are often not present and this person doesn't realize it. If the statement above is not true then - oh, my God!
Company benefit: If this person annoys people wit his/hers management style, then they will try to avoid him/her on future projects. Not a good thing.
Personal benefit: This person can get respect from colleagues because of the technical knowledge but it's not necessarily so; it really depends on how he or she treats people and handles “level of project stress”.

"I want to organize things better and help people work without stress."
Project benefit: Better organization of project tasks. Higher probability that deadlines will be reached.
Company benefit: People who work on such projects have a chance to form a real team and work the best they can if manager succeeds at least partially in his/hers attempt.
Personal benefit: Respect of colleagues and possibly a successful project in ones record.

"No one can do it better than me, I have to sacrifice myself."
Project benefit: This person strongly believes that it is his/hers duty to take this responsibility. It is probable that he/she will do his/her best to finish the project.
Company benefit: Company can lose this employee eventually if it is extremely unwanted task to perform.
Personal benefit: If it is very stressful for an individual, than definitely can have very bad impact on personal life. Anxiety will not leave you when you go home and even on weekends.

"I want to be in charge."
Project benefit: If the person is a tyrant, project can have benefits. On the other hand, people will react and simply work slower and with less motivation. Some can leave in the middle of the project.
Company benefit: Sounds like a true leader? When it comes to knowledge-workers, I don't think so. Smart people don't want someone to "be in charge". At least not this way.
Personal benefit: One can tell his friends that he/she is in charge at work. ;)

"I want others to admire me."
Project benefit: I see no benefits for the project here.
Company benefit: People will notice this flaw in character, so to speak, and avoid this person in the future.
Personal benefit: Admiration is not won by simply wanting it to happen so forget about it (if this is your only motivating factor).

"I don't want to depend on others." or "I want to have the project under control."
Project benefit: This person will not expect much help from others. But that can also be bad: breaking a team atmosphere where everybody is dependent on one another.
Company benefit: Depends on other personal qualities.
Personal benefit: Can help self-esteem but may not win respect of colleagues.

"I don't want others to tell me what to do."
Project benefit: This person is not meant to lead knowledge-workers.
Company benefit: Same here.
Personal benefit: I don't see it.

"I want to get a raise."
Project benefit: This can only be a personal goal or, better to say, a consequence of well managed project. If it is the only motivating factor, than I don't know what the benefits would be.
Company benefit: None.
Personal benefit: See "Project benefit".

"I want to add something new to my resume."
Project benefit: Let's put it this way: if the project fails, one can still put in his/hers resume that he/she was a project manager. So there is not much of a guarantee that project will be a success.
Company benefit: Benefit is possible if the person is determined to add "project success" to his/hers resume. :)
Personal benefit: One can add that he/she was a project manager to his/hers resume. :))

"I want people throughout to company to know my name."
Project benefit: Might put pressure on the project that is not necessary.
Company benefit: People might try to avoid this project manager in the future, if they are to pressure with his/hers "glory". In reality, projects that people talk most about are the ones that are in deep trouble. The ones that are successful are unknown and their managers live in shadow.
Personal benefit: Can be significant if you ask people who are not actually working on the given project.

"I want to have a successful project and help my company."
Project benefit: Sometimes it can happen that a company had a few unsuccessful projects in a row. Individual person(s) might at that point have motivation to put their best into leading one project that will change things. Highly motivated person can transfer motivation to his/hers team members. Such a team can make wonders.
Company benefit: This positive attitude of one team can motivate others in the company to achieve better results in their field of work.
Personal benefit: One can get respect of colleagues and be a true member of a team. If it really helps the company, professional benefits might be significant.

"I have no motivation whatsoever."
Project benefit: Some people argue that in software development (and/or other areas) the best project managers or team leaders are those who don't want to perform this duty at all. I have to say I disagree with this because if someone doesn't want to do something, it will be very hard for him/her to move forward, learn new things and educate oneself. No one is perfect, and if you want to get better you have to be motivated. On the other hand, people will not be threatened by this persons and possibility of forming a real team is significant.
Company benefit: Formation of a team that can work on future projects with the same or better performances.
Personal benefit: One might get experiences, knowledge or find new interests which will change his/hers carrier or even perspective in life.


In most cases, people have more than one reason. Two bad reasons from the list above are, I think, enough to ruin any project. Let's hope most managers have at least one good reason!

A Developer-Analyst Hybrid

Yesterday I had a discussion with my co-workers about developers, analysts and overlapping of their tasks (inspired by an article from Mr. Angry). We were not able to decide if it is worse to have:

• An analyst with no knowledge about programming or some other (corresponding) skill and knowledge or
• A developer with no will or interest for client’s requests

It’s really hard to tell. For example, I know an “analyst” who simply forwards all emails and notes from clients to developers, thinking, I guess, that her job is done. Maybe I’m wrong here, but I think I know a better way to do this. It’s called: automatic email forwarding. I mean, it’s:

• Free (doesn’t ask for salary and bonuses)
• More reliable than manual forwarding
• Fast
• Never sick or absent

This is an extreme example but I had to tell the story because it’s the truth (!).

It would be nice to have analyst and developer in one person. Often, for various reasons, it doesn’t work that way.
Nevertheless, there should always be a tendency not to have “pure” analysts and “pure” developers in the team/company. Here are (some of the) reasons why.


Main problems with developers detached from reality:

• Problem zero: communication overload. An analyst has to explain everything to the smallest detail about functionality that needs to be implemented. He has no confidence that any work will be done correctly without his supervision. I had a colleague that had to tell the developer that upper left corner is no place for a “Submit” button. I’m not kidding. Imagine the communication necessary to finish the job completely!
• Not learning business processes as they go along with development. Analysts will have much more work to do if a developer doesn’t learn the business processes. Every time some bug appears in the code which was written a month ago, analyst will have to explain all over again about things that need to be done. The reason is simple: if you really understand something, you remember it more easily even if some time has passed.
  

Main problems with analysts detached from technology:

• Promising wonders to end users. Analysts should know at least what information they should get from developers before they say it’s OK for something to be implemented.
• Not being familiar with data structures. If analyst doesn’t know enough about these, his job will be very difficult. Chances are that he will have to take one developer with him to each meeting with customers (which a waste of developer’s time in most cases).
• Leaving their problems to developers. If they do, it means a developer is doing a significant part analyst’s job. (Maybe developer should also get a part of analyst’s salary.)
  

Pushing developers to think like customers

Analysts should always encourage developers to learn the business processes and to learn why customer needs what he needs. If the developer refuses to listen and just wants detailed instructions, don’t give up and explain the processes to him/her when ever you get a chance.Team leaders should inform team members that a complete separation of development and analysis tasks is not acceptable because it adds effort to the project.

Pushing analysts to think like developers

This can be especially difficult because it might take months of even years for someone who is completely unfamiliar with the technology that is used. Of course, there are some people that work excellent with customers, and it would be a shame to lose their talent, but making analysts from them does not happen overnight. It takes companies time and analyst-to-be commitment. If either of those two things is missing, it will be very hard to get results.

Software Project Soft Skills Guide: How to Be Proactive?

Working in a team combines two opposite things:

• The need for synergy with people and conforming to the needs of the project
• The need for self-improvement, grabbing carrier opportunities and outshining others

In project-oriented companies, showing your capabilities is possible only when you work as a team with others. By showing “too much” or, better to say, attracting too much attention of your team mates and superiors can bring problems to your relations with colleagues and thus endanger the project. I saw some individuals who were not particularly interested in the project as long they are the kings/queens of the county. Such an individual annoys the team and destroys team atmosphere. Also, this behavior is hardly professional. As the matter of fact, it’s childish.

If, however, you don’t show what you’re capable of in some “graceful” way, you will:

• Miss a lot of new challenges
• Not get to choose what you actually want to work on
• Work on boring projects
• Not have arguments for career promotion or salary increase

Maybe accomplishing results listed above looks impossible to achieve by simply trying to be more proactive during your working hours but I’m certain that when being “gracefully proactive” – wonders can happen. Situation is rather complicated and requires some really soft skills. But if you just sit, wait and work on whatever you are assigned to, you will do what others decide, when others decide and at the end look like someone who doesn’t have a will to work on anything at all.


So here are some of the things that I did and that really helped me in many aspects:


When coming to new workplace, scan the environment and people to find out what is your realistic position in the team and the company in general.
It’s not particularly useful to believe that you are the best programmer, designer, manager or whatever if that’s not the truth. If you are not realistic, it’s very hard to improve.
If there are some people better than you, it means that you can learn from them, compete with them and eventually improve yourself. If there isn’t anybody who’s better than you in at least some aspects than such a company or a team is a waste of your time.

Cooperate with everyone but try to work in a team with the best.
After you have made assessment of all team members, try at all times to cooperate with the best. Don’t make clans with people you don’t respect. Be polite to everyone; be decent even to the people you don’t respect too much; do whatever is necessary to finish your tasks; but always try to come one bit closer to the people from whom you can actually learn something. This is also the place where interesting things happen. If things are not interesting, these are the people that will make them interesting.

Take crappy tasks! As Tom Peters suggests: if you are at the bottom, take the tasks that are of no interest to others and make something special out of it. This is especially true for software projects because there are lots of tasks that are of no interest to anyone and can be done much better than they were done in the past by someone else.
A good example is writing end user documentation. In companies where there is no special team responsible for documentation, usually someone is temporarily assigned to this task simply because the product cannot be delivered without documentation for the end users. Or someone is hired part time to do the job. A person who feels he or she is not appreciated enough can take this task and make best written, best looking documentation in the company for a shorter time than anybody expected. This way you show to others that when you take something as your responsibility, you deliver things better and faster than others.

Well, this is an example to someone who has just started to work in software industry but it can really be applied in at least one additional case. It is the following: when you start working for a new company, people you work with not necessarily:

• Were present on your job interview,
• Know what your skills are,
• Know what you want to work on,
• Know what you worked on before

… And, sometimes, they don’t even know why you were hired in the first place.

In this case, you might be in a position where your team leader makes all kinds of assumptions and assigns you to something completely different from what you expected. What to do?

• Do the tasks you were assigned to
• Find something no one wants to work on (like unit tests ;)) and make it perfect

Find ways to talk to your superiors and find out what projects are coming next.
There are always rumors about new projects and it’s definitely good to know what’s coming next (even if it is something to avoid!). The person one level above you in the company hierarchy or maybe your team leader, probably knows more than you do about new projects that are coming. Talk to anybody you can. You will be surprised how much information you can find if you simply – ask! I think no one will punish you because you are “too interested” in future projects. OK, this one might be pointless if your company works 5 years on the same project, but in most software companies, things are very dynamic and there are always new things coming. Find out what might be interesting.
If someone gives you such information, and it is really something that you like, show your interest openly. Discuss about it. If you don't know enough, read and learn more about it so that next time this subject comes along you would be able participate in a conversation more easily.

Don’t rely on others, let other rely on you.
Try not to expect for others to get you out of trouble, even if you are new in the company. Do whatever is necessary so that you can finish your tasks on your own. Also, if others need help, do whatever you can to help them. Everyone needs help sometimes. That's the essence of teamwork. But there is a big difference between people who take their tasks seriously and the people who expect other people to help them by default. Make sure you are in the first group.

Use your sense of humor (if you have one).
People with sense of humor are usually perceived by others as smarter and more dynamic. If you are new in the company, colleagues will accept you more easily and will be happy that you are a part of the team. (If they are not, leave the company. ;))
Every new employee that comes to the company shall more likely approach to the team member who has a sense of humor because he or she assumes that such a person is more open for questions and help (or breaking unpleasant atmosphere). This way you are always somehow at the “center of things” because “things” actually happen where people interact with each other.
If you don’t have a sense of humor, for heaven’s sakes don’t use it. I mean, don’t use that entity called humor only by you and by nobody else. I happen to know at least one person who has almost no sense of humor, but is much respected team member and successful project leader. He doesn’t pretend to be something that he is not and that’s enough. It’s not the end of the world if you are not funny; just get over it!

Be yourself. The best edition of yourself.
This one is maybe hard to explain. We are not the same person every day. Some days we are full of energy, happy, constructive and some other days we can be nervous, confused, and angry and whatnot. At work, always try to be “better side of yourself”. Always try to say and do the right thing because you most certainly have the capacity for that. Everyone has.
I believe this can only be done if a person is well organized. I’m referring mostly to time management. If you always under pressure and always running somewhere, you will not be able to control your reactions. You will not be able to think about what you do and sooner or later you will offend someone just because you were reckless at the time. There is no need for that to happen – you can stop it. Find some time management resources on the web and act on it. These skills are definitely not only for managers, everybody needs them.

If some project interests you, join the team by working on whatever is necessary.
If the team accepts you, you will most probably get new, more interesting tasks. Even if it is because someone got sick, you will be able to show your potential.

Make sure others see your progress.
I think advertising of your work is very important. I know people who really don't need this "advertising" at all (because they are doing excellent job) but they do it anyway. That’s because it really helps. What’s the use of working more and better than others if no one sees it?
The trick is: how to do this so that it doesn’t look like you are showing of? The answer is: drop small chunks of information to your superiors and colleagues who don’t know what you are working on. Never talk to long or too loud about your tasks and results, but mention it through some other stories. Mention also the results of others. Lots of things are happening in every team and company every day; you can’t expect someone will have the time to actually explore who did what and when he or she did it. People need information and you have to give it to them.

If you have a lot of Complexifiers in your team/company, be the person who simplifies things.
This way you will become a catalyst of change in your team. If you have ambition to become a team leader, this is especially useful because people will look at you next time something is not clear. In software development, thing often get too complicated. That’s why Simplifiers are very important persons in the team.

Get things done.
Try your best to reach the deadlines you said you would reach. That is what counts to your team mates and your superiors. Deadlines are very important. Don’t overanalyze and gold plat things. Just finish and inform everybody that it’s done as planned.


There are few more things to add. With practices stated above one has to start as soon as he or she comes to a new working place. This is not because of the new chair you are sitting on, of course, but because of the new people you are now meeting for the first time in your life. As soon as you come, people start to size you up and they have a natural need to form a clear picture about a newcomer as soon a possible. I don’t think that a lot of people do this on purpose. It’s just something that we all instinctively do. But the problem is, this “picture” can be created in the matter of weeks or even days but then last in peoples heads for years. It’s very difficult to change it, no matter how hard you try.
When I got my first job, after graduating from university, I made many mistakes with many people, including my superiors, of course. ;) After a year or two I have improved in many ways and tried to fix the errors that I did in the past. Nevertheless, my colleagues had that “old picture” of me and it was very difficult to change it. I wonder if I succeeded at all.

People do not change often and when someone sees that you have changed, even if the change is positive, it somehow looks staged and fake. It’s like coming to work every day in your jeans and T-shirt and one day decide to come in your best outfit and a huge lady hat. OK, maybe that’s not a good example of a positive change… But my point is: it looks as if you are suddenly trying to be something that you are not, and people don’t like that.

Difficult Personalities, Part 2: How To Deal with Them

I’m not saying that I’m an expert in overcoming situations that outcome from problems stated in the previous post. On the contrary, this is something that I have always had problem with. “Not to explode” and “Not to get upset” were always challenges for me. Exploding in such a situation, I think, is the worst thing one could do. That is why I always observe what other (smarter :) ) people are doing in those circumstances; how do they behave and how are they dealing with the situation.

Situations can be different, but some best practices I often use are the following:

• Concentrate on constructive issues (resolution of the problem)
• Be deaf to personal insults. Never respond in the same manner; no matter what.
• Avoid emotional responses and stay professional (bite your tongue if necessary)
• Wait for the other person to come down before you continue with that conversation. In the meanwhile stay calm and don’t respond to provocations.
• If you can’t calm down, leave the room and return in 5-10 min when you do.
• Refuse to discuss about things that are of no use to you and the project you are working on.
• Stop any useless discussion as soon as possible.
• Afterwards, act as if nothing happened and treat this person in the same way you did before the “incident”.

I don’t know about others, but for me, this last point is the most difficult one.

Difficult Personalities, Part 1: Can One Person Ruin The Whole Team?

Project manager certainly can. Project manager can ruin whatever he sets his mind to: project, project team, whatever...
Can a “regular” team member ruin the whole, otherwise healthy, team? That’s another question.

To explain this little bit better. It is a sad truth that there are actually persons who have so many professional flaws and flaws in their personality, that they are actually a real threats to teamwork and, for that reason, a threat to project success.

I’m not talking about incompetence. Incompetent team member is only a gap in the team. Problematic person I’m talking about is a person who makes other team members suffer because of his or hers unprofessional behavior.

Of course, if this person was incompetent and also completely useless to the team or the company, than he or she would be easily removed from the team. At lease that is what experts prescribe in such cases. The problem is that, often, persons in question are, for some other characteristics, extremely useful for the team and the company. In those cases it is very difficult to say weather the benefits are outweighing the drawbacks.

In bigger teams, people usually don’t suffer too much because of one person’s behavior.

If a team consists of few persons, than I would say that both damage and the benefit from such a person are significant and it’s very difficult to decide what to do. To overcome problems, two things have to be in place:

• Other team members have to cooperate and get along well above average (even if we are talking about two or three persons only). I have actually seen that this alone can reduce the destructive influence of a problematic team member.
• Manager has to at all times provide support to “endangered” team members by stressing that company doesn’t approve unprofessional behavior - no no matter how indispensable you are for the project.

Motivational Posters in Foreign Languages and Their Impact on My Productivity

A lot of things have need said about “Those Damn Posters and Plaques”.
For example here.

But in my company, we have motivational posters in foreign languages (namely German), which are not understood by at least half of the employees in the company, including me, because… we don’t speak German! At least not good enough to understand those posters.

And so we have nine pictures, each representing some noble practice, for example: “Initiative” (probably!) or “Pride” (maybe!). I am not sure if I understand any of the words on those nine pictures, even though someone “explained” them to me at some point.

In general, the practices on the pictures are really supported by both upper and middle management most of the times so it’s not nice to complain about that. But why are they standing there if half people don’t understand them?!

You can only imagine the impact on my productivity.

Customer-Oriented Deadlines

What I mean by the phrase “customer-oriented deadline” is the following…
It’s when customer says:
- We absolutely need this until 1st of November 2006.

And some upper management genius, after 3 seconds of thinking and detailed planning, answers:
- Ok!

On any project, I think almost everything has to be customer-oriented. But if something has to be non-customer-oriented it’s definitely a deadline: deadline for project ending, deadline for any task on the project.
If you make a good estimation based on facts, with help of people who actually do the tasks, even then you are going to make mistake weather you want it or not. If you don’t make estimation at all, and in fact don’t even know what the concrete tasks are, how smart do you have to be to realize that you are not going to make it anywhere near to the deadline you promised to the customer?

I am not talking here about that situation when project manager deliberately shortens the development cycle so that people would “work faster”. I will leave that phenomenon for some other time. I am talking about the case when one doesn’t have what it takes to say “No” to the customer.

I’m currently witnessing this: it was agreed to finish entire system for 3 months, with 5-6 men working on the project. The number of people is fine and system is not to be developed from scratch. A lot of functionality could be reused from other projects, but:

- The new system is for another country; meaning different laws, regulations etc. (“How different could it be - we are neighbors!”).
- Some modules will be completely different, and these are the most complex in the entire system.
- Requirements specification missing, except what modules are needed (“Let’s hope for the best!”).

Now they are working as if everything will be finished. It’s ridiculous. Some team members, who are either inexperienced or just blindly following orders, don’t even realize that it is impossible.

I said to one of them:
- You, of course, know that you, as a team, are not going to make it until that date?

My other (very funny) colleague said to me:
- You know, you were not supposed to say that aloud. :)

Project Leader is a Project Resource

Project leader is often seen as a very special person on the project: like his time and presence are worth more compared to the other team members.

There is no doubt that project needs this one person, and also that people need to know who makes the decisions and helps resolve the problems. But looking from a different angle, project leader is just another person on the project. He has specific tasks. He needs to do his job just like everybody else. Other people should use the resources of the project leader as needed: his skills and influence are just another resource of the project.

People should not blindly report everything to the project leader but only report the things that he can actually resolve or help resolve. Everything else is a waste of time. If the project leader demands reports purely because he “wants to know” and “be in charge”, than he is either:

• Sick or
• He doesn’t trust his people

Both things are deadly for the project. :)

To explain this better, here is an example.

I worked on the project which had a project leader who was very resourceful people manager. As a matter of fact, he was sometimes too “sensitive”. When he would see two people having problems, he would immediately interfere and tried to help them (with best intentions). However, everybody knows that sometimes the third person cannot resolve the personal problems between the two – it looks as if they need “adult supervision”. Also, the third person will probably misunderstand something because it is simply too much for him to get a grip of the situation.

So here is what happened. My colleague said something about other person he had problem with to the project leader. The problem was not big but only some job responsibilities were temporarily mixed somehow. The project leader immediately had his view of the problem. He went to the person in question, said that it is not his place to interfere with the work of my colleague. This person was of course offended because he hasn’t done anything wrong: only trying to help! Aggressively, but trying to help.

After that, my colleague had problems because he had harder time getting the help he needed: other colleague was always hesitating to help and my colleague hesitated to ask because he knew that the other colleague was offended.

My colleague didn’t know that such a thing would happen, he only complained to the project leader because he needed to say that to someone. But one should always think in this way:
“What will my project leader do if I say this or that to him? Will he resolve the problem? Will that push project forward or backwards?”
No project leader is perfect. You have to know them well to be able to use them for the benefit of the project.

Use project/team leaders wisely!

It's not easy...

... to form a team.

Top 10 Most Stressful Professions

I find the fact that there are professions less stressful, quite comforting.
Top 10 Most Stressful Professions

Clerical professions on number 10, huh?

Even More on Multitasking

I had a sincere intention to move away from the subject of multitasking but today something happened…

As I said in my previous posts, in my company most people are switching between tasks and between two projects. Everybody is aware that it’s not good but still continuing with this practice.
Let’s call these two projects A and B. I work on the project A. Project manager of the project B has a lot of tasks on different projects so she switches between them all the time.
Because she thinks it’s not fair that others should work on only one task, she was always pro project switching. Logic: if I’m suffering, let everybody else suffer too.

Another person who works only on project B was planned to take one task from me (project A). This person reacted to the decision and said it is too complicated for him to switch all the time. Project manager of project B backed him up by saying that she will do all she can to save her project team members from project switching because it’s bad for the project (no kidding?!).

From my (and some other colleagues) point of view, I’m pretty annoyed because:

a) Most other people are working on at least 2 tasks so it is unfair that someone refuses a task like this.
b) Person who refused the task was backed up by someone who is in general pro project switching.
c) I’m actually in a situation where I want someone to suffer just because everybody else (including me) is suffering. And I know it’s a stupid.

It’s a sick game. Avoid project switching.
If the humans are not complicated, I don’t know what is.

More on Multitasking

Special case of the multitasking problem (touched in the previous post) is switching tasks between two different projects.
The beauty in it is that not only are you experiencing all the problems mentioned before but also you don't have a feeling that you are a part of any team or of any the two (or even more) projects. If the person does not feel that he or she is part of something, than the risk of lower responsibility and motivation level is really increased.

There are also other things.

In my company there are currently two projects running. There is one colleague, however, who appeared to be working on both projects but when project managers got together, they realized that this person is actually not taking part in any of the two projects.
This is actually the same as it used to happen in high school with kids who were active in sports: at school they would say that they have to train for some big race or other competition – asking for some free days from school. To their trainers they would say that some big school exam will take place so it is impossible for them to come to their training sessions.
After such “preparations”, they would just stay at home having fun with their crosswords (!) and similar interesting stuff.

In a long run, this is of course stupid but for shorter periods it works very well.
The main problem is that, for example in my company, working on two projects is a common practice: almost everybody is switching between projects. If there was only one person doing this, it would be easier to track such a behavior.

To sum up: if you allow a lot of "project switching" in your company, it opens a lot of doors for people who are natural-born non-workers.
Either assign person to only one project, or all project managers need to communicate. And we all know that's impossible!

Multitasking

Yesterday I saw this interesting article. It covered something completely different from what I'm going to point out here, but the first few sentences (quoted below) made me think.

“I have three roles. I code about half time. I'm project manager. And I'm team leader.”

Oh yes, the multitasking. The reason why this intrigued me so much is that I'm currently in a very similar situation. Recently I have been working simultaneously on at least three tasks: system analyst, team leader and project manager. It’s better to put it like this:

• System analyst = concentrate
• Team leader = care for people
• Project manager = do politics

It would be nice if I was working on system analysis on Mondays and Tuesdays and for the rest of the week on these “sociological” tasks, but of course: with management it’s clear that every 10 minutes someone will interrupt me. That means that maximum time to concentrate is approximately 10 minutes and it is not hard to imagine how deep I get into the matter in that time…

The other important thing is that team leading really is a full time job. Everything else you do is taking the time away from people management and issues that arise during project execution.
The project can survive without my analysis but without team leader (not necessarily me) – it’s doubtful.

Anyway, multitasking is bad idea per se, but a task that requires concentration on one single thing in combination with management is a horrible idea.
Now when I think about it, it’s not clear how am I able to get any work done. It’s a mystery.

Smart Managers

I am sure everyone has had a chance to meet at least one bad manager. This is a person who has no talent or interest to manage people effectively in such a way that they are satisfied with their work. On the other hand, not everyone had a chance to work with a good manager.
I happen to know one good manager. On his example I will try to explain how complicated is to manage people and their needs.
The person I am talking about has the following qualities:

• Sensitivity to people’s emotions and changes of mood
• Good intuition to influence people in a positive way
• Intelligence – so he gains respect of smart people easily
• Openness – so people can talk to him as soon as some problem arises
• Good communication skills
• Energy and will to manage people and spread good atmosphere
• And what’s most important: invests a lot of time to improve team dynamics

All things mentioned above are very useful and help motivate most individuals in the team. The results are visible on everyday basis. So what’s the problem?
Looking from my perspective, I was very satisfied and thought all other team members are more or less of the same opinion. When I had a few private talks with some of them, I learned that they had problems with some management techniques used and also some problems with other employees. No one was at the point of leaving the company but the situation was far worse then I expected. I realized that the equation of satisfied team has so many variables that no matter what efforts you invest in your team satisfaction – it’s not enough.

Now, if you have a lousy manager, what can you expect?

Motivation, Part 2

I have noticed that significant amount of people who work on software projects are frustrated most of the time they spend working and thinking about their jobs. This is true for me also. The reason is, mostly without exception, the conflict with other people: their superiors or peers.

Sometimes it happens that the frustration is present because of some technical problem which is difficult to solve, but this is a sweet worry. It can be a good thing because such problem can be a theme for a constructive debate with your colleagues. It can make people work closely together, exchange ideas and feel good when the problem is solved.

The “sociological” source of frustration, however, usually leads to ugly comments and talks among peers (and behind their back). Such talks can also be continued at home, with your spouses and/or friends. These talks help people feel a little bit easier about the situation but, in essence, it’s destructive practice because it doesn’t solve anything, it doesn’t lead to a conclusion.

The problem with frustration is that it doesn’t disappear as soon as you go home at 5 p.m. but you take it home with you and you hang out together for some hours more, or even until you go to sleep. This means - it ruins your entire day.

Even though I have just said that lamenting and complaining to others about your workplace problems doesn’t help you in a long run, there is an obvious reason why people do it.
If you are unsatisfied with your workplace you have two options:
a) find another job
b) complain to everybody who would listen

Wouldn’t we all like to quit our jobs as soon we encounter problems? I know I would. But we can’t change it every 5 seconds. If for no other reason, then because it would look bad in our resume. ;) Our dissatisfaction grows until it is impossible to endure it and then we leave the company. In the meanwhile, we have to talk about it; otherwise we would go insane…
For me, putting my problems in written form like this, helps a lot and makes a problem real. When I read other people’s blogs and articles elaborating such issues, it has special therapeutic value for me. I hope that someone someday will read my blog post after having frustrating day at work, and that it will help him/her calm down.

Motivation, Part 1

My motivation for starting this blog comes from the fact that in my relatively short professional career in software industry I have already experienced so many managerial mistakes as if the software team management classic Peopleware was never written in the first place.

It is normal that people make mistakes. Mistakes are made if you work in any industry, on any job position. If you go to a supermarket or brush your teeth, you can also make a mistake. I have no problem with that. However, in software companies it seems to me that those mistakes and errors in judgment happen far more often. And they happen in many, many interesting variations. Situations happen that would be great jokes if you weren’t actually working in that company and spending at least 40 hours of your life every week. That is why it is not funny.

All the theory is available in Peopleware: Productive Projects and Teams by Tom DeMarco, Timothy Lister. I have read and heard a lot of people referencing it and I am sure many more articles are covering the same subjects. That is why it is pretty unclear to me, why are there so many mistakes made in that field.

I have read this book both last summer and this summer again, in the meanwhile I have changed the company I work in, but both times I was shocked with the same thing: it is unbelievable how many things have already happen to me and are mentioned in this book. I would say 90% of all problems mentioned (one day I will count them, just for curiosity). Next summer I will read it again just to check the score in 2007 ;)