Traditional practice when a company handles multiple projects tells us to build teams, where members are experts of their respective projects.
In previous personal experiences, I’ve felt pretty lucky to be a part of such teams, and we managed to have a strong sense of companionship, knowing each other’s strengths and weaknesses, actively trying out new methods to improve our daily worries.
But I also watched the opposite happening, in cases where for example, there was weak team leadership, or where developers were in charge of a particularly «buggy» project, or where developers were simply given the same kind of tedious tasks over and over because they are the ones that «already know how to fix them».
So each separate team’s dynamics can feel quite different from one another, creating very different perceptions of the company depending on who you ask.
This traditional model has been predominant over the past decades, but does it adjust to the current market with fast paced changes to requirements, people and knowledge?
Some questions that arise:
What happens if a project does not require more than one person working on it at a time?
What if they leave/go on holidays/get sick?
What if the project has long idle periods of months without development, and then peak moments with a lot of it?
Surely, these are not new questions, But here at Renuo, we try to turn the paradigm around, by working in a dynamic team environment.
Dynamic teams
In a few words, teams are not fixed. Meaning that team members can easily come in and out of each particular project, as existing project demands are met, and new ones are introduced.
This translates to temporal teams formed based on the arrival of new projects/requirements, and on the knowledge of each employee. The latter marks an important point, as knowledge is not contained within the traditional team, but spread among the company.
And temporal teams mean employees get the opportunity to interact with everyone, leading to:
On a project level:
More opinions exchanged.
Questioning decisions, leading to solid foundations.
Strong project versatility.
And on an employee level:
Personal growth by collaboration and interaction with different colleagues with different expertises.
Often faced with new challenges to learn from.
Developer flexibility.
Set in motion
It then becomes of utmost importance to set up some common ground, so that employees can quickly integrate into each new project. For developers like us, this means to have standardized:
Project structures (we have our own setup guides for each of our most commonly used tools)
Codebase (we use mainly Ruby on Rails)
Programming practices (The first task given to me on my first job was to read the book The Clean Coder, which to my pleasant surprise, was also the case here at Renuo)
Looking back
Now, we all know change frequently does not come easy, and as the word «dynamic» suggests, we setup an environment of constant change, this means being able to adapt from one week to another to different work styles (we do set standards, but since we are talking about people, we need to recognize each other's uniqueness), project requirements, meeting schedules, possibly programming language. Also each member is more responsible to ensure they have sufficient amount of work, and ask for it otherwise.
This can be tiresome at times, but after a year at Renuo, I can confidently say that those are the fewer moments.
In the end, there is no One-Size-Fits-All, and each company needs to fine-tune details like, for example, how many projects can an employee handle at the same time.
But in our experience, giving the chance to each employee, to work together within different projects opens up many possibilities.
And for us, happier programmers most often translates to better results, leading to happier clients.
