Choosing what work to do at TIM Group

TL;DR: Working at TIM Group means having the responsibility to decide what work to do. The most obvious criteria is business value but I don’t think that is enough.

At TIM Group we have been experimenting with self-organisation for a while. It’s been a gradual process that started with the adoption of the Eight Behaviours for Smarter Teams and whose last steps were the removal of the line management structure in the technology department and a reiterated message from the CEO on employees insisting on being responsible.

My personal experience has been of changing team and/or project every six months or so which I find refreshing. Most of the time my moves were motivated by changing conditions and suggested by people higher in the hierarchy. A few times, very notably the last change of both team and project at the same time was decided and executed without indication from the management. I saw this happen multiple times since, to multiple people across multiple departments.

My colleagues and I have the responsibility of deciding what work to do. The executive team still has the authority to give orders and to fire people but that does not happen often. For all intents and purposes proposing projects, staffing those projects and delivering are now shared responsibilities.

I’m more interested in the staffing part of the equation in this post as it is the most immediate problem we are facing.

I believe staffing in our current form of self-organisation is the sum of the individuals’ decisions of which project they dedicate their time to.

Every day we decide, based on our knowledge and the information we receive, if the best thing is to keep doing what we are doing or stop and do something else. I find this model of organisation very interesting and motivating but I find it is difficult to navigate at times. How do I decide what work to do? It is a hard question!

This reminded me of something I had read a long time ago in the Valve Handbook: “Deciding what to work on can be the hardest part of your job at Valve”

A model I have seen discussed is to estimate the revenues of the alternatives and do the work that has the bigger potential win. Another, from a period when the product team was studying Reinertsen’s Product Development Flow, is use cost of delay to sequence projects.

The common aspect of these two approaches is the use of money as a unit of measure, the economy of the company as the space in which to locate the models. It makes a lot of sense if you are trying to influence an economically minded person but I ain’t one and the times when I, and a few other developers, attempted to use them it did not work.

I want to take a step away from direct business value to reflect on what else I see as potential factors for deciding what work to do.

Skill acquisition: the project I’m working on right now is in a new domain and is a great opportunity to learn about domain modelling and event sourcing; as a general skill for me and in the context of commando operations for the company. We believe this improves staff liquidity even though we have not done the spreadsheet yet so it is not an informed decision.

Skill application: have you ever seen someone very skilled do an amazing work? I bet they enjoy it.

Skill transfer: Find out what you already know, teach it to somebody else and enjoy watching how they pick it up and sometimes even extend it beyond your own knowledge.

Purposeful execution: fixing a bug that someone is experiencing, implementing a feature that will be used, making someone’s life better. Making a difference.

Polishing: I would love to see a product I’ve worked on being listed on a site like

Personal alignment with business phase: want predictability and regularity? Join a maintenance project. Up for something a bit more shaky? Seek a new opportunity.

Compatibility with career objectives: what work would you like to do in 5 years? Is the work you are doing helping you get there?

Process adoption: I joined a team because they were trying to use experiments to drive product development. I don’t think I have acquired the skill itself but I’ve seen this process at work and it was an enriching experience.

Cost reduction/Improved efficiency:

Making the right thing cheaper: take the opportunity now to shape your future legacy code the way you would like it to be.

Cultural learning: a part of the company radically changed the way to approach development by bringing the concept of experimentation at the very front. By working with them I absorbed some of their ideas.

Character alignment: I worked with person X before and it was great so I want to keep doing it. I worked with person Y before and it sucked so I don’t want to do it again. I’m in a great mood so I want to work again with Y to see if we can make it work.

Improving the industry: we go to conferences, speak at conferences, organise conferences, organise meetups, write blogs. I think the underlying value in all these activities is improving the state of the art of product development.

I believe there are more. How do you choose what work to do?