To do lists and the death of passion in IT. Part Two.

Resources, Thoughts about...No Comments

You Are Here:, Thoughts about...To do lists and the death of passion in IT. Part Two.

Welcome back to the second part of the To do list blog post 🙋‍♂️. Last time I mentioned about my rediscovery of data structures that felt like a breath of fresh air. If you haven’t read the first part, you can check it out here:

tree structure

Tree structures are specific to project management oriented towards objectives. A software product can be modeled from a specific objective, that defines a problem,or a requirement. For which a decomposition strategy applies to smaller issues that are then analyzed. The analysis is resulted in sub-problems and activities. Once solved, they must be integrated into the final product.

One very important thing to note is that this model works as long as the team is relatively small and there is a responsible person who defines the top of the tree (that is, someone to set the goal). Each member contributes to building the tree by making knots and bindings. Implementation becomes a matter of keeping focus on the ultimate goal and of keeping active connections between those who work.

The end product depends on the involvement of each and the ability to understand the maximum number of ramifications a team succeeds to manage over a period of time.

code is a tree
The tree structure is so popular that it finds its place in many organization charts, but it becomes extremely inefficient especially in software development work. The code is a tree, so you need a more complex structure to produce it.

A model that we found to be more effective in teams larger than 20 to 25 people is the matrix. Product teams are defined vertically. And community-based practice, that support a particular discipline, are formed horizontally. The trap of this model is that teams are developing lists, and the homogenization of practices is a challenge. In spite of leverages being defined so that team members exchange knowledge.You probably are able to recognize this in the figure below.

The promoters of this model are those from Spotify. They released two videos describing how to work in the product development team.

What they’ve noticed is that they still do not work well in their teams. Mostly due to the distance between those who solve the problems and the real problems to solve. The teams are still made up of specialists and there is a segregation between business and IT.

The death of passion in IT happens when you work as a robot on a list of tasks assigned by someone. Meanwhile, you are measured by the number of such tasks solved in a time span. Or when a team is rummaging into a long list of things to do that gathered hundreds of ideas, problems and projects. They are not being connected to users and the need they started from.

In conclusion, managing software development work is less about to do lists. Organizing software development work is a matter of creating relationships in social networks that use their energy in a creative way to solve complex problems.

We will further look into this in the third part.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Cookie Settings