Home Home Posts Rants about IT DevOps Stuff I'm working on

Roadmaps, goals, morale, beliefs and motivation

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
115
articles
September 24, 2014

One of the aspects of developer performance to consider is the availability of the roadmap, a roadmap which is very precise near the point the person is, and less precise far from it.

Why is it important for a developer to have an immediate access to this roadmap?

Without knowing where should we go, it's extremely hard to be motivated. I spent the last three days doing nothing: wandering around, watching Netfix, and lots of other things I can't even remember. I can remember doing a complete rewiring of my rack machines, but nothing development-related. In the same way, at my last employer's job, I spent hours just sitting there, moving chaotically my mouse just to give an impression of some activity (I believe that people tend to be scared when they have an impression that their colleague is dead), and thinking about life and death and listing all things which were too wrong at the workplace.

With a roadmap, you know exactly where you are and what should you do next. The final goal matters, but interestingly enough, it doesn't matter how long will it take to reach this goal (nor would you even be able to reach it, nor is it even reachable). As soon as you have two things: the tasks to perform in immediate future and the final goal, things are great. The list of tasks to perform soon shows what should you do. The final goal shows why are you doing all that.

For example, one can have the list of following tasks:

  • Solve the issue which occurs when the user logs off while watching the video in a different tab.

  • Change the colors of the bottom panel: this horrible blue background is killing my eyes.

  • Add OpenID, because having just our own registration/logon forms is not cool enough for geeks.

and the final goal:

Create the greatest video sharing platform for geeks.

This means that when I arrive in the morning at my desk, I know what to do (for example changing the colors, it seems easier than other two tasks) and I also know why am I doing it (because I enjoy contributing to the development of the greatest video sharing platform for geeks).

Such approach also makes it easy to understand why only short-term tasks matter. When I'm here, at my desk, at 9 AM, I really don't care about something I would need to do in three weeks. I care about what I need to do today, this morning, from 9 AM to 10 AM, right now. I care about where to start.

What's wrong with long lists of tasks?

Long lists of tasks can create more harm than good. Knowing that I have 514 tasks assigned to me doesn't mean anything. It looks depressing, but it's actually meaningless. I can be hit by a bus tomorrow. The project can be cancelled. A new person can join the team and take some of my tasks. A person can be hit by a bus, and I'll find myself with twice the number of the actual tasks.

Life-critical projects aside:

  • The list is also subject to change, and will change frequently. Tasks which are far away in time have more chances to change. A task “change the colors of the bottom panel” scheduled for two months from now is probably useless, because two months later, the bottom panel would change radically, or there would even be no longer any bottom panel.

  • It is practically impossible to get the list of tasks right for a period of several months or often even several weeks or days, since some tasks would reveal technical constraints, complications and preliminary requirements which would span additional tasks.

The long lists contain tasks which are unequal in terms of difficulty. Either they are particularly specific, and will be invalidated given enough time, or they are too general and will span additional tasks. Given this volatility, the long lists cannot be served for milestones either. We can't say that we have done 10% of the project, because we finished 150 tasks and there are 1 350 tasks left in the list. This mistake is what leads managers to mislead business people. They claim that they have finished 60% of the project, but this claim is based on the data they don't understand, the data which is by its own nature unreliable. And by unreliable, I don't mean a deviation of ±5%, but rather two, three or four times the original estimation.

As a side note, unrealistic schedules are encouraging even more the uncertainty of such lists. If the manager knows the team is late and wants to show that it's not terribly late, he will (eventually unconsciously) write more general tasks which will later span even more additional tasks, but which, until then, will remain small and silent in the list of things to do.

Shouldn't the goal be reachable?

As a said previously, a list of immediate tasks is not enough, and there should also be a goal. The presence of the goal motivates us, given that the reachability plays no role in this motivation.

The goal should be believable, and it's essentially this aspect which influences motivation. A team of passionate developers may spend months writing the next great thing just to discover, during development, that either it's not so great or somebody already did it or it is impossible to do or the goal itself should be different. It doesn't matter how it ends: what matters is that all those people share the same vision.

The denouement plays an important role in how those developers will apprehend new projects and believe (or not) in new goals.

  • The best, in terms of morale, is a change of the goal. It can be either a small shift (“We were building a test framework, but let's focus now on automation a bit more.”) or a radical change (“We were building a test framework, but a full DevOps platform with its own test framework looks much more interesting!”).

  • The worst, according to my experience, is condescending ignorance. It's when the manager returns from a meeting with a boss and tells that the project is cancelled. No explanations. No “sorry”. This is similar to break up with your girlfriend by asking your friend to send her a text message telling that you don't want to see her any longer.

The fact that the goal is not reachable doesn't mean it will affect the team negatively. In the same way, a break up between consenting adults who came together to the conclusion that their life together is not what they expected originally is not necessarily affecting the partners negatively. Both understand why their relationship can't last, both understand that it's nobody's fault and doesn't mean they couldn't find a partner who corresponds better to them. If a team have spent great time together and learnt a lot, this is the only this that counts, not that the project remains unfinished.

So:

  • Belief influences motivation: high belief in the goal (high cohesion for a common vision) increases motivation (which also increases the doability).

  • A goal may or may not be reachable.

  • If the goal is not reached (and eventually the team discovers that the goal is not reachable), the belief of the team in future projects is not necessarily affected.

This is how goals, morale, beliefs and motivation interact together.

Example

For the last months, I was developing a DevOps platform.

The goal? Having a solid infrastructure which make deployment of specific applications as easy as it could possibly be. I believe in this goal, while I know that it can change at any moment: I know where I go, I'm just not sure where I will arrive.

The tasks? I have my board inspired by The visual management blog. I have a dozen of “long-term” tasks: tasks which won't be done during the current week. I also have a half-dozen tasks waiting to be done during the week. They are somehow general and often span additional tasks which are very specific but also mostly short in time (some can be solved in a few minutes, others take a few hours). Finally, there is one task I'm working on; sometimes there are two tasks marked as current, but that looks weird. Finally, there are tasks I've done, waiting for the end of the week to be analysed during a retrospection and be removed.

The project is experimental, so there is a lot of uncertainty. I can be working on monitoring application, and a hour later decide that I absolutely need an additional option in the application which creates virtual machines; a hour later, I can be working on something completely different. This also means that tasks change constantly.

Is it motivating? Totally. I know the goal. I know what should I do right now. I don't know what I will be doing tomorrow, but I don't care.

Unless I have no tasks to work on right now, in which case I can easily spend days wandering around, watching Netfix, and lots of other things I can't even remember.