You can think of this article as a reassesment of On working styles: big communities vs smaller teams. You don’t need to read the latter.

One would think that work habits are transferable from one organization to the other. One would hope that time spent developing a work strategy is a one time investment that will payoff throughout one’s entire carreer. Sadly, none of these are true and they may result in frustrations, disappointment, and demotivation.

A good work strategy is not only based on what works for the person doing the work but also what meets the organization’s needs better. It’s a combination between one’s culture and the organization’s that guarantees productivity in terms of time, human interaction, and achievements.

What productivity actually entails is up to you. As far as this writing is concerned, productivity is just a measurement of successful time investment that results in the parties involved being content with the results.

The following example, while arguably not extremely dangerous, should provide a good picture of where I am coming from:

I have, in the past, been paid to work on big open source projects and help my employer implement features, fix bugs, and guarantee the stability of such projects so that my employer’s customers could benefit from it. Basically, what an open source company does. The reason the size of these project is relevant in this context is that it emphasizes the fact that the projects moved rather slowly in terms of code-reviews, RFC proposals, general concensus, and release cycles.

In order to guarantee a certain productivity in these projects, my work strategy was to pick multiple features and work on them in parallel. Since the general upstream interaction was slower than in other projects and organizations I had worked at, working on multiple features and bug fixes in parallel never felt as multi-tasking. It was easy enough to work on a feature while the other one was being reviewed. It was still possible to organize my days in a way that would not burn me out. The time it took to get something done (unless it was a critical bug) was not as important as making sure it made it into the next release.

Arguably, this work habit was more related to the release cycle than the size and pace of the community itself than that of my employer’s. Regardless, it provided the right level of productivity that would make everyone happy. It also fit well with the various cultures I was interacting with.

I then moved to a different company and joined one of their internal teams. This team, for reasons I won’t be going into details here, didn’t have a time-based roadmap, let alone a release cycle. There are tasks that have a certain sense of priority, which have no timeline except for what people implicitly expect it will take to work on something.

Working in such a team requires a complete reassesment of one’s working strategy. The team is smaller and more agile (in the old meaning of the word) if you will. Taking multiple long-term features in parallel will likely result in those features taking longer than it should. Because the team is smaller, it is easier to have a shorter feedback loop on ones work which, depending on the task at hand, will help moving it forward faster.

The above is an argument on how important it is for us to stop, reflect, and reasses not only our work habits but everything around us. Work is in constant change, cultures are in constant evolution. Adapting to these changes is part of our carreer and our growth.