The Merriam-Webster dictionary defines dynamic as “marked by usually continuous and productive activity or change”. Most of us have had the fortune of working in such a team, where collaboration is easy, information flows, and the team keeps on delivering success after success. However, if you ask people what makes a team dynamic, you’ll probably have as many different answers as respondents. So, what are the different ways of being dynamic? Or what benefits do each of these ways bring?
An example of dynamism
My last team was composed in a very traditional, Agile way: we had software engineers, QA engineers, product owners, business analysts… the usual. Everyone was very skilled, but there was this particular business analyst who had a special knack for it, writing tickets with just the right amount of detail, and always including a section titled “Risks and assumptions”, even if empty. One day I noticed that one ticket didn’t have this section, which I found odd, so I went to ask them. It turned out that, somehow, their changes hadn’t been properly saved and there was a lot of important detail missing.
This worked because I knew how this particular business analyst communicated and this ticket didn’t fit the pattern, which prompted my question. This is an example of team dynamics that comes from knowing each other and creating an expectation. It’s a right middle point in between two inefficient extremes: asking the business analyst about every single ticket wouldn’t work, too much overhead that may lead to confirmation fatigue, but always assuming that the ticket is correct would have missed this particular issue. Knowing how the business analyst communicated allowed me to identify an issue without the overhead. Continuous and productive activity. Dynamic.
Enter the new joiner
When someone new joins, the new joiner won’t know any of this, so they won’t be able to participate in this dynamic pattern. They’ll be slow in comparison with the rest and, what’s worse, they’ll be making everybody else slower. They may even be confused by the implicit knowledge, which can often lead to frustration.
The typical reaction to this is the creation of onboarding manuals: reams of documentation that explain the process, the interactions, the tools, the conventions… This comes from good intentions, but often makes the onboarding process even more frustrating: new joiners want to hit the ground running, they want to contribute as soon as possible, and instead they need to go through heaps of often out-of-date documentation before they can even understand how the team operates. Not to mention the additional overhead that the creation of the onboarding manuals poses on the existing team.
Other organisations try to maximise the value of new joiners by selecting people who will complement the skills of the present team members. The idea is, if the new joiner has some skills and/or knowledge that the present team members don’t have, then the new joiner will reach a state of effective contribution much more quickly, even as the new joiner is still learning the ropes. This requires careful analysis of the skill sets of the present members and of the candidates for each type of role (you can see an example of such analysis for the case of Product Managers in What’s Your Shape? A Product Manager’s Guide to Growing Yourself and Your Team). It also requires a candidate pool large enough to ensure diversity of skill sets so as to find the right pattern. And all of this, in summary, requires a lot of effort.
These are often assumed as necessary evils but, what if there was a way to structure the team while facilitating the addition of new members?
Structure the team so as to facilitate joining
The main challenge that new joiners face is discovering the culture of the organisation, so you should strive to make that culture easy to discover. Spotify had a good go at it when they announced their Spotify Model, a system of squads, chapters, and tribes where people more or less self-organise to achieve objectives. The clear advantage of this model is that, when a new person joins Spotify, they know exactly how the company works. Or do they?
Now, a new joiner at Spotify may know the theory behind the model, but that doesn’t mean they know the actual structure of the company. Sure, there are squads, chapters, and tribes, but who are they? What are the features or technologies they gravitate around? How and why were they created? Not to mention the fact that, according to some reports, the whole Spotify Model was partly aspirational, and the company didn’t work in exactly that way anyway.
Oddly enough, the main issue with the Spotify Model was the encouragement of team autonomy. There was no problem with the autonomy part, after all that’s one of the three intrinsic motivators; the weak link was the static team. Whenever you have static teams and long-lived structures, then you’ll have implicit knowledge that builds and accumulates over time, making it harder for a new joiner to find their place and participate.
Fluid teams
If you’re reading this you’re probably into topics that deal with team structures and organisations, so you’re probably familiar with the Cynefin framework. Most organisations are optimised for clear and complicated projects, but start to struggle when dealing with complex or chaotic projects. And part of the reason for this is that organisations are built around static, long-term teams, with trackable assignments and measurable objectives.
A trend that started to emerge in response to this was the further encouragement of autonomy: instead of analysing, breaking down, planning, and assigning tasks, an organisation would simply explain the vision, the needs, and the constraints, and then leave individuals self-organise. This led to the creation of FaST, or Fluid Scaling Technology, a model that proposes patterns to encourage self-organisation and adaptability.
FaST is built upon the concept of Open Space Technology, a methodology for facilitating gatherings towards a particular objective without a specific agenda, not dissimilar to the unconferences that we run at the London Java Community. The basic tenet of FaST is the lack of static teams:
Everyone involved in the project is put together into a Collective
The Collective meets and, together, creates an information radiator where the vision, constraints, etc. are visible.
People self-organise to decide what to work on, teams may appear.
After a couple of days, the Collective meets again to check progress, and teams may be disassembled and reassembled as needed
Now imagine a new joiner entering the Collective: there are no static teams nor onboarding materials, just a vision and a set of people trying to materialise it. Sure, relationships still exist and new joiners will have to create their own, but the fluid structure of FaST will make it easier for the new joiner to start participating. Of course, FaST isn’t the only way to allow people to join dynamic teams, but it’s one way that explains the main feature: fluid teams where people naturally come in and out, so everyone is, in a way, a new joiner.
Optimise what you do often
Are FaST and/or fluid teams the best option for your organisation? That will depend on your needs, after all, all models are wrong. Agility and adaptability are obviously great traits to have, but they come at a cost. A jet ski gives you a greater degree of manoeuvrability than a cargo ship, but whether a jet ski is better will depend on your needs: if you need to switch direction often and respond to an ever-changing environment, then a jet ski is obviously better; however, if you need to carry large amounts of goods from point A to point B, and you know what points A and B are well in advance, then you’ll be better off with a cargo ship.
Similarly, you need to understand what the needs of your organisation are. Perhaps you work in an industry with intense competition and where talent retention is hard. Or perhaps you’re developing a new product where the market is uncertain and you need to pivot often. If this is the case, then you want to make sure that you make it easy for new joiners to become productive as soon as possible, so you’ll want to set up fluid, self-organising teams. If, on the other hand, you have stable projects with clear long-term goals, then perhaps you’re better off with the predictability and efficiency of static teams.
What works best for you?