7

Situations where the members of the project team have tasks which are not directly related to their job positions happens quite often (especially in cross-functional teams).

According to my experience, this will always decrease the morale of the team.

Two examples from my practice:

1) On one project my team had a lot of translation work.

In my company we have a special translation department, but the quality of its translations are very poor, they don't have knowladge of the subject area and if we give a translation to them, we will have an external dependency that we can not control well.

That's why the development team does all translation work. Of course, no developer wants to do this and it is a great demotivation factor.

2) Another example. Unfortunately, my company eliminated the tester from my team. Developers can test well, but dont want to (and it's logical, if they wanted to test, they would go to work as testers, not as programmers).

So, how can we decrease this kind of demotivation?


Of course, the answer that we should hire a technical writer or tester on our team is very easy, but in the real world it not always possible.

So, a little bit of explanation about what kind of solution I want: for example, if a new project should be done in a well known or even legacy technologies, some companies make special days for developers, when they can work on their own project with any technologies they want. My company has no resourse for such days. But in any new project we try to implement the minor part with new technology. This decreases the dissatisfaction from monotonous work with boring well known technologies very well.

I am looking for some kind of non-trivial solution to the question that I described above.

9

Get the team committed to the business goals

In the long run, you should get the team committed to the business goals so much that they voluntarily step up to do what it takes to accomplish them without worrying too much about what their job position is. In the short run, here are some things you can try:

  1. Challenge the development team to automate part of the work:

    a. Translation: Google and Bing have translation APIs. These machine translations won't give you the finished translated text. However, it will give you 40 to 60 % depending on language pair and topic. You can ask the developers to create simple tools to get the initial translation done so that the manual work is reduced. Once the tool is developed, you can possibly give it to your translation department to speed up their work.

    b. Testing: Developers can write scripts to automate part of the testing.

  2. Develop business justification why you need to hire a tester: In my experience here are the additional costs to developer testing. See if you can build a business case for hiring a tester by collecting this data:

    a. Testers will have the time and motivation to create and maintain good test plans and cases. Developer testing is likely to be poorly organized and documented.

    b. Developers generally cost more than testers.

    c. If developer testing is not as good, there will be much higher cost to fix the bugs in production.

  3. Pair up a developer with the translation department: If the developer can provide subject matter expertise, I am sure it will improve the quality of the final translation.

8

You are creating a cause and effect between a lowering morale and motivation with doing certain tasks. My first reaction is you are creating a cause and effect that does not exist. Every job in the world has tasks no one likes, or tasks with which one might feel less competent, or tasks that causes some anxiety or worry.

They may not like it but it does not reduce overall morale. Maybe for a few, some of whom will be selected out, but not for an entire organization of practitioners. If you are truly experiencing a loss in motivation and morale across your organization of programmers, I would look for other drivers. You have something else going on.

Review some current thinking on morale and motivation. I personally like the paradigm of Autonomy, Purpose, and Mastery. It goes a little deeper than incentives and rewards. But whatever theory resonates with you, use it to identify other drivers that are going on in your organization.

  • I agree, although I would add that you should ensure that the task you are asking your team to do are the tasks they will be rewarded for doing. Ie. they dont lose their bonus because they spend all their time testing – Ewan Jul 5 '15 at 13:59
  • That's true. Telling your team to go left while paying them to go right is not uncommon and is definitely a morale killer. But that also violates "autonomy" and "purpose". Having your team choose to do the undesirable tasks because they are necessary to achieve mission should not adversely affect morale...at least in theory. – David Espina Jul 5 '15 at 14:31
  • 3
    Really? Doing something you don't like for weeks/months at a time doesn't lower morale? Working for a company that fired the tester and saddled me with that work won't lower morale? These sorts of things go directly counter to the Mastery your employees are working on. – Telastyn Jul 5 '15 at 20:16
  • As I wrote above, I think some would lose their morale. Sounds like you might be one of them. But if the culture supports the right variables that have been shown to boost morale, doing tasks you do not like will not cause a systemic breakdown in morale across the organization. If this is what the OP is experiencing, there are most likely other drivers. – David Espina Jul 5 '15 at 23:36
2

I totally understand your question and am struggling with it also.

What I figured out working sometimes is

  • Highlight the tasks importance by explaining the tasks importance including the consequences is the task is not done with best effort. Saying that someone else would be better in doing this is not an argument because no one else will do it. For whatever reason.
  • Show empathy for the dislike for the task. E.g. by identifying the common enemy but take care to not to start a revolution...

By the way you asked for a a non trivial solution. Unfortunately, the real solution is a trivial one and I'm sure you know it: Respect the rules for delegation. There are many websites out there describing how to delegate. I have roundabout 5 rules in my mind where dummies.com comes closes too after a short search: http://m.dummies.com/how-to/content/delegating-effectively.html I often disrespect those due to a lack of time (just a bad excuse) because you actually have to think about the points to find good answers but if you really struggle with those problems it might be worth...

2

I am a developer and yeah, I do get frustrated sometimes from fringe-work and so do my colleagues. But doing fringe-work is rewarded very much during our monthly reviews/awards. My firm understands that it is hard work and shows its appreciation. So the work could be demotivating but the reward for the work is what keeps folks motivated :) .

1

Whoa, I think I worked for your company recently?! Just kidding! :p

A big problem in our team was time management. The person responsible for the schedule ignored all time estimations, made up new ones and those obviously failed.

If you are in such a situation and then get additional boring tasks, this drops morale a lot. In our team three of the developers left more or less simultanously.

Make sure the developers have enough time for both their normal work and the extra stuff, make sure they can split the boring stuff in batches, for example on 10 days doing 10% of the translations instead of doing them all on the last day.

Make sure they know about the extra work ahead of time so they can plan it in. Often you 1-2 hours left in the evening and don't want to start anything important, but doing some of the testing then seems good.

Use an issue tracker (for example gitlab) to define everything that needs to be translated/tested, they can then go and pick something out they like, this assumes there is enough time for it.

Which languages are they translating to? Are they familiar with them or just learned them a little at school? You could also hire an external translator, just show them what your program does and they will get it done. And probably better, faster and cheaper than paying a developer to do the job.

Same applies for testing, there are people who really like to break and hack things and they are more efficient than letting the developers repeat their mistakes from development while testing.

-1

I might be jumping to conclusions, but from what you write it's not the tasks that demotivate people, but you and/or your company.

Two examples from my own experience:

  1. We started a new project and the offices we had to use had no blinds for the windows (south facing; summer time). Also we had just barely enough outlets for the computers, but none for some of the secondary monitors, let alone phones and similar stuff. We as a team decided to get some multi-outlet power strips and some aluminum foil which we pasted on the windows.

    Net effect: Motivation boost, because we solved two problem all on our own, although a highly qualified software developer did what any intern could have done. What did the company/management do for that? Stayed out of the way, accepted the odd ball solution and accepted the trip to the shop as working time.

  2. Short before noon the Vice President of a company strolls from office to office asking everybody to join for lunch. Nobody clarifies who is going to pay. VP has some tasty and expensive steak, while an intern nibbles on some salad, wondering if he is invited or has to pay himself. The check arrives and the VP proclaims: Lets split evenly! So basically the intern pays part of the lunch of the boss. Effect on moral: I'm sure it is obvious. Was the 'task' of eating lunch together the problem? No the way it was communicated and 'rewarded' is.

Now to your situation: You (meaning you and your company) remove the tester from the team basically stating: "Testing is not important and/or trivial to do, so we don't need someone dedicated to do it." And then you tell the developers to do it. It's hard to be more demotivating than that without actually trying.

What can you do?

  1. Anybody in your company who has the title "Manager" and is surprised by the effect should be fired immediately. They don't know the very basics about what their job is about.

  2. Get the testers back into the project ASAP.

  3. In the meantime apologize for the huge thoughtless mistake and ask the team what you together can do to cover up for the missing tester. If that means that you personally do the testing, go for it.

The situation with the translators is similar. Them not performing their job (and as it appears nothing happening to change that) basically means: It's Ok to mess up your jobs, our janitors -- sorry developers -- will clean up the mess.

What can you do?

  1. Anybody in your company who has the title "Manager" and is surprised by the effect should be fired immediately. They don't know the very basics about what their job is about.

  2. Come up with a plan to get the translators to a level, where they can perform their job. Possibly by having a retrospective with developers and translators together. Note that this is not about putting blame on the translators. Somebody tasked them with a job they were not capable of doing. That sounds like another management mistake.

  3. In the meantime apologize for the huge thoughtless mistake and ask the team what you together can do to cover up for the inadequate translators. If that means that you personally do the translating, go for it.

  • Welcome to PMSE. I understand your emotions, but obscene language is not permitted on this site. Also, your answer looks a little rough. Please, read this article before your next post. – Sergey Kudryavtsev Jul 6 '15 at 14:47
  • Thanks for welcoming me. Are you suggesting that the phrase "fuck up" is obscene? Vulgar, yes. Obscene? Certainly not. While I find it ludicrous to write f*ck instead of fuck, I'm fine with that if it helps anybody. Apart from that I try to choose my words according to the importance of getting heard. And here it seems someone who should know better is actively destroying a team and then seems to blame the team. This is dangerous behavior and should stop quick to avoid further damage. Therefore the somewhat strong language was chosen intentionally. – Jens Schauder Jul 6 '15 at 18:11
  • Thanks for your self-censorship. Your answer looks much better without "f-words" and "s-words". – Sergey Kudryavtsev Jul 6 '15 at 21:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.