Roadmaps, goals, morale, beliefs and motivation

One of the as­pects of de­vel­op­er per­for­mance to con­sid­er is the avail­abil­i­ty of the roadmap, a roadmap which is very pre­cise near the point the per­son is, and less pre­cise far from it.

Why is it im­por­tant for a de­vel­op­er to have an im­me­di­ate ac­cess to this roadmap?

With­out know­ing where should we go, it's ex­treme­ly hard to be mo­ti­vat­ed. I spent the last three days do­ing noth­ing: wan­der­ing around, watch­ing Net­fix, and lots of oth­er things I can't even re­mem­ber. I can re­mem­ber do­ing a com­plete rewiring of my rack ma­chines, but noth­ing de­vel­op­ment-re­lat­ed. In the same way, at my last em­ploy­er's job, I spent hours just sit­ting there, mov­ing chaot­i­cal­ly my mouse just to give an im­pres­sion of some ac­tiv­i­ty (I be­lieve that peo­ple tend to be scared when they have an im­pres­sion that their col­league is dead), and think­ing about life and death and list­ing all things which were too wrong at the work­place.

With a roadmap, you know ex­act­ly where you are and what should you do next. The fi­nal goal mat­ters, but in­ter­est­ing­ly enough, it doesn't mat­ter how long will it take to reach this goal (nor would you even be able to reach it, nor is it even reach­able). As soon as you have two things: the tasks to per­form in im­me­di­ate fu­ture and the fi­nal goal, things are great. The list of tasks to per­form soon shows what should you do. The fi­nal goal shows why are you do­ing all that.

For ex­am­ple, one can have the list of fol­low­ing tasks:

• Solve the is­sue which oc­curs when the user logs off while watch­ing the video in a dif­fer­ent tab.

• Change the col­ors of the bot­tom pan­el: this hor­ri­ble blue back­ground is killing my eyes.

• Add OpenID, be­cause hav­ing just our own reg­is­tra­tion/lo­gon forms is not cool enough for geeks.

and the fi­nal goal:

Cre­ate the great­est video shar­ing plat­form for geeks.

This means that when I ar­rive in the morn­ing at my desk, I know what to do (for ex­am­ple chang­ing the col­ors, it seems eas­i­er than oth­er two tasks) and I also know why am I do­ing it (be­cause I en­joy con­tribut­ing to the de­vel­op­ment of the great­est video shar­ing plat­form for geeks).

Such ap­proach also makes it easy to un­der­stand why only short-term tasks mat­ter. When I'm here, at my desk, at 9 AM, I re­al­ly don't care about some­thing I would need to do in three weeks. I care about what I need to do to­day, this morn­ing, 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 cre­ate more harm than good. Know­ing that I have 514 tasks as­signed to me doesn't mean any­thing. It looks de­press­ing, but it's ac­tu­al­ly mean­ing­less. I can be hit by a bus to­mor­row. The pro­ject can be can­celled. A new per­son can join the team and take some of my tasks. A per­son can be hit by a bus, and I'll find my­self with twice the num­ber of the ac­tu­al tasks.

Life-crit­i­cal pro­jects aside:

• The list is also sub­ject to change, and will change fre­quent­ly. Tasks which are far away in time have more chances to change. A task “change the col­ors of the bot­tom pan­el” sched­uled for two months from now is prob­a­bly use­less, be­cause two months lat­er, the bot­tom pan­el would change rad­i­cal­ly, or there would even be no longer any bot­tom pan­el.

• It is prac­ti­cal­ly im­pos­si­ble to get the list of tasks right for a pe­ri­od of sev­er­al months or of­ten even sev­er­al weeks or days, since some tasks would re­veal tech­ni­cal con­straints, com­pli­ca­tions and pre­lim­i­nary re­quire­ments which would span ad­di­tion­al tasks.

The long lists con­tain tasks which are un­equal in terms of dif­fi­cul­ty. Ei­ther they are par­tic­u­lar­ly spe­cif­ic, and will be in­val­i­dat­ed giv­en enough time, or they are too gen­er­al and will span ad­di­tion­al tasks. Giv­en this volatil­i­ty, the long lists can­not be served for mile­stones ei­ther. We can't say that we have done 10% of the pro­ject, be­cause we fin­ished 150 tasks and there are 1 350 tasks left in the list. This mis­take is what leads man­agers to mis­lead busi­ness peo­ple. They claim that they have fin­ished 60% of the pro­ject, but this claim is based on the data they don't un­der­stand, the data which is by its own na­ture un­re­li­able. And by un­re­li­able, I don't mean a de­vi­a­tion of ±5%, but rather two, three or four times the orig­i­nal es­ti­ma­tion.

As a side note, un­re­al­is­tic sched­ules are en­cour­ag­ing even more the un­cer­tain­ty of such lists. If the man­ag­er knows the team is late and wants to show that it's not ter­ri­bly late, he will (even­tu­al­ly un­con­scious­ly) write more gen­er­al tasks which will lat­er span even more ad­di­tion­al tasks, but which, un­til then, will re­main small and silent in the list of things to do.

Shouldn't the goal be reach­able?

As a said pre­vi­ous­ly, a list of im­me­di­ate tasks is not enough, and there should also be a goal. The pres­ence of the goal mo­ti­vates us, giv­en that the reach­a­bil­i­ty plays no role in this mo­ti­va­tion.

The goal should be be­liev­able, and it's es­sen­tial­ly this as­pect which in­flu­ences mo­ti­va­tion. A team of pas­sion­ate de­vel­op­ers may spend months writ­ing the next great thing just to dis­cov­er, dur­ing de­vel­op­ment, that ei­ther it's not so great or some­body al­ready did it or it is im­pos­si­ble to do or the goal it­self should be dif­fer­ent. It doesn't mat­ter how it ends: what mat­ters is that all those peo­ple share the same vi­sion.

The de­noue­ment plays an im­por­tant role in how those de­vel­op­ers will ap­pre­hend new pro­jects and be­lieve (or not) in new goals.

• The best, in terms of morale, is a change of the goal. It can be ei­ther a small shift (“We were build­ing a test frame­work, but let's fo­cus now on au­toma­tion a bit more.”) or a rad­i­cal change (“We were build­ing a test frame­work, but a full De­vOps plat­form with its own test frame­work looks much more in­ter­est­ing!”).

• The worst, ac­cord­ing to my ex­pe­ri­ence, is con­de­scend­ing ig­no­rance. It's when the man­ag­er re­turns from a meet­ing with a boss and tells that the pro­ject is can­celled. No ex­pla­na­tions. No “sor­ry”. This is sim­i­lar to break up with your girl­friend by ask­ing your friend to send her a text mes­sage telling that you don't want to see her any longer.

The fact that the goal is not reach­able doesn't mean it will af­fect the team neg­a­tive­ly. In the same way, a break up be­tween con­sent­ing adults who came to­geth­er to the con­clu­sion that their life to­geth­er is not what they ex­pect­ed orig­i­nal­ly is not nec­es­sar­i­ly af­fect­ing the part­ners neg­a­tive­ly. Both un­der­stand why their re­la­tion­ship can't last, both un­der­stand that it's no­body's fault and doesn't mean they couldn't find a part­ner who cor­re­sponds bet­ter to them. If a team have spent great time to­geth­er and learnt a lot, this is the only this that counts, not that the pro­ject re­mains un­fin­ished.

So:

• Be­lief in­flu­ences mo­ti­va­tion: high be­lief in the goal (high co­he­sion for a com­mon vi­sion) in­creas­es mo­ti­va­tion (which also in­creas­es the doa­bil­i­ty).

• A goal may or may not be reach­able.

• If the goal is not reached (and even­tu­al­ly the team dis­cov­ers that the goal is not reach­able), the be­lief of the team in fu­ture pro­jects is not nec­es­sar­i­ly af­fect­ed.

This is how goals, morale, be­liefs and mo­ti­va­tion in­ter­act to­geth­er.

Ex­am­ple

For the last months, I was de­vel­op­ing a De­vOps plat­form.

The goal? Hav­ing a sol­id in­fra­struc­ture which make de­ploy­ment of spe­cif­ic ap­pli­ca­tions as easy as it could pos­si­bly be. I be­lieve in this goal, while I know that it can change at any mo­ment: I know where I go, I'm just not sure where I will ar­rive.

The tasks? I have my board in­spired by The vi­su­al man­age­ment blog. I have a dozen of “long-term” tasks: tasks which won't be done dur­ing the cur­rent week. I also have a half-dozen tasks wait­ing to be done dur­ing the week. They are some­how gen­er­al and of­ten span ad­di­tion­al tasks which are very spe­cif­ic but also most­ly short in time (some can be solved in a few min­utes, oth­ers take a few hours). Fi­nal­ly, there is one task I'm work­ing on; some­times there are two tasks marked as cur­rent, but that looks weird. Fi­nal­ly, there are tasks I've done, wait­ing for the end of the week to be analysed dur­ing a ret­ro­spec­tion and be re­moved.

The pro­ject is ex­per­i­men­tal, so there is a lot of un­cer­tain­ty. I can be work­ing on mon­i­tor­ing ap­pli­ca­tion, and a hour lat­er de­cide that I ab­solute­ly need an ad­di­tion­al op­tion in the ap­pli­ca­tion which cre­ates vir­tu­al ma­chines; a hour lat­er, I can be work­ing on some­thing com­plete­ly dif­fer­ent. This also means that tasks change con­stant­ly.

Is it mo­ti­vat­ing? To­tal­ly. I know the goal. I know what should I do right now. I don't know what I will be do­ing to­mor­row, but I don't care.

Un­less I have no tasks to work on right now, in which case I can eas­i­ly spend days wan­der­ing around, watch­ing Net­fix, and lots of oth­er things I can't even re­mem­ber.