Adapting Team Dynamics in Response to Change
Adapting Team Dynamics in Response to Change
31 July 2020
Team dynamics are definitively more of an art than a science, however they are crucial to collaborative and organisational success. In this post I look at adapting a team’s dynamic as a direct response to change: specifically a change in personnel, or a change in working styles in light of the new remote-first lifestyles many of us have undertaken.
The dynamic of a team (primarily a software engineering team in this context) has a tremendous effect on that team’s ability to be effective, produce quality outputs, sustain motivation, and stay in high spirits. You can select five of the best individuals in any particular field and ask them to work on a combined project/product: if their cohesion and team dynamic is lacking, then the final result is going to suffer no matter the prowess of each individual. Different teams (even within the same sector) are likely to have substantially varied team dynamics. Some might be markedly static, lacking any sort of dynamism.
As a consultant I’ve had the benefit of being in a variety of teams working on different products. While there are many similarities that can be drawn between teams, there are many major and nuanced differences in the way that they function. Often, well-established teams have some of the best team dynamics, however they are still susceptible to changes in circumstances and need to be willing to adapt/evolve.
It’s no secret that high performing teams are almost always motivated and have managed to cultivate an advantageous team dynamic. Dan Fabulich has talked about how at Redfin (a metric often used to evaluate client satisfaction and loyalty). Engineer motivation and happiness (and by proxy the wider team dynamic) is found to have a (Graziotin, Daniel & Wang, Xiaofeng & Abrahamsson, Pekka. 2014).
Improving a team’s dynamic will doubtlessly improve the motivation of the individual team members. There are lots of ways to do this and this post will only scratch the surface — I'll be focussing on how you can adapt to a new team, followed by adapting to changes in working locations.
Adapting to a New Team
Joining a new or existing team can be daunting. It is something virtually everyone working in software engineering will have faced at some point. Here at Formidable it’s a commonplace experience: we work with a variety of clients, integrating into their own teams to help them deliver the best products possible.
As a new team member to an existing team, it is imperative that you are open to integrating with the team’s dynamic. Being dismissive or resistant to how things currently work will hinder teamwork and potentially perpetuate the aspects of the team dynamic that you find unfavourable. I’m sure we’ve all been there (“why do we have so many meetings, it’s interrupting my flow!”) — here it’s important to remember that decisions have legacies. Though a team might not be using what you consider to be the most efficient way of working, they’ve likely incremented in a way that works for them (although that’s not to say that there’s no room for change).
In Robert Greene’s book, Mastery, he elegantly investigates the path to honing one's craft. In part II of the book, Greene describes “The Apprenticeship Phase” as a crucial step. This particular section was enlightening: being an apprentice, taking a step back to reflect and absorb, is a crucial phase of self-development that is often not given enough credit.
When the participants of a team change (or when a new team is formed) it’s valuable to allow for a period of apprenticeship to find out how to collaborate best as a team. So, while on the surface you may think something along the lines of “well, that doesn’t apply to me — I’m a senior, not an apprentice”, this phase helps with finding out how best to collaborate and grow as a team, setting the stage for a successful team dynamic.
Two of the apprenticeship steps Greene outlines are Deep Observation and Experimentation. I feel that Deep Observation is the most important when joining an existing team, while focusing on Experimentation makes more sense when forming a new team.
When you enter a career or new environment, you move into a world with its own rules, procedures, and social dynamic […] every workplace has its own conventions, rules of behavior, and work standards. […] And so your task upon entering this world is to observe and absorb its reality as deeply as possible. […] These procedural and political rules may be dysfunctional or counterproductive, but your job is not to moralize about this or complain, but merely to understand them, to get a complete lay of the land.
Directing energy towards an initial phase of observation (rather than an attempt to change processes or workflows) can provide insight into the underlying way that a team works. Then, once a level of understanding is reached, changes can be suggested and introduced that are backed by qualitative evidence as opposed to instinct.
In the case of:
- A new team member joining a team, there should be a degree of flexibility afforded by that person. Whether that's by following the programming styles or paradigms that are in place, or the way that pull requests and code reviews are conducted — ideally all teammates will be comfortable with what’s in place, and if not, feel comfortable asking for help. The new teammate should be willing to observe and adapt, only suggesting change once they understand the dynamics at play.
- A new team forming, it’s prudent to observe your new teammates to try and understand how they enjoy working: having a base level of understanding will help you to work cooperatively and towards a shared goal. One of GitLab’s excellent values is that ; adhering to this allows them to continually observe and be poised to make changes.
Most people wait too long to take this step, generally out of fear. It is always easier to learn the rules and stay within your comfort zone. Often you must force yourself to initiate such actions or experiments before you think you are ready.
A team that is constantly willing to observe, interpret, and adapt, will reap the rewards. With the world today being so focussed on continuous improvement and optimisation, remaining static is a sure way to get left behind. This is the reason that agile frameworks place such emphasis on short feedback loops and reflection.
By treating meetings like retrospectives (in Scrum) with the deserved significance, it will help to ensure that maintaining/improving team dynamic isn’t regarded as a “nice to have”, but is instead considered paramount to the success and productivity of the team in the long run. These type meetings are good times to plan/initiate/measure experiments.
Once the team has collectively decided on an experiment (whether process, code, or communication based), there are measures that can be put in place to make sure it’s likely to be beneficial, rather than desultory:
- Defining success criteria prior to starting will help discern whether the experiment has been a success or is worth continuing. Setting a fixed timeframe prevents experiments dragging on too long.
- Taking note of how the team’s dynamic and resulting output has been affected means you can celebrate learnings (either bad or good).
Underpinning all of this is the fact that we don’t want to experiment to the point where changes become overly frequent and onerous. Changing ways of working too regularly will keep things unsettled and hinder any chances of getting into a productive rhythm.
Adapting to Working Remotely
Some teams are already well-versed with remote working; at Formidable we work on a largely-remote basis so have been thankfully well-prepped for the seismic shift to remote-working. However, losing face-to-face time with colleagues means that we have to focus on making sure that our other communication methods are as productive as they can be.
Not only do teams have to respond to changes in teammates, they also have to respond to changes in their physical working environment: in the current climate this means that teams that have built a favourable team dynamic working side by side are having to adapt. For some of us who enjoy having face-to-face time with colleagues, being fully remote can be demoralising — it can be hard to feel as valued and recognised for the work you do. can be helped by going out of your way to show others that you care.
There’s no golden ticket to “solving” remote working. Different teams will have different ways of approaching it that work for them. Linking back to the experimentation mentioned prior, the important thing to do is try and recognise when something isn’t working as well as it could, then actively make a change (or changes).
Set the Stage for Success
As software engineers we could refer to workstations/desks as our “stage” in a sense. If you’re working somewhere that doesn’t promote calm, productivity, and happiness, that could well be the first blocker to maintaining a team dynamic that had been working well in an office (or face-to-face) environment. Obviously there are some aspects completely out of our control, though there are still likely to be improvements and tweaks that can be made:
- Having consistency in your daily routine and home (/remote) setup is the first step towards having consistency within the team. I personally feel like there's more time in the day when I'm following some sort of daily structure/routine. The more team members who fall into a routine/consistent rhythm, the more aligned the team is likely to be as a result.
- Having a dedicated workspace with physical separation from your "leisure" area. This could be accomplished by having your work setup in a different room, or, by something as simple as having one piece of furniture reserved for relaxation and one for work. The physical change is a nice way to signal the end of a work day.
- Communicating! Communication is the most important factor in maintaining or improving team dynamics in light of change. It’s often noted that . I’m dubious that the percentage is as dramatic as that, but I think it’s fair to say that it’s harder to convey information purely over text than with the help of body language/tone — one of the reasons that video calls should be used frequently if possible. If sending a message solely via text, depending on the context, emojis and gifs can be used as a replacement for tone.
- Building trust and rapport with teammates. Creating designated opportunities for team members to chat, work-related or otherwise, can help to build trust and encourage free-flowing communication (as mentioned above!). Earlier this year Sam Morrison, a fellow Formidable, wrote about how important it is to .
Working Remotely Across Timezones
While people working remotely don’t always span different timezones, people in teams spanning different timezones will almost always have an element of remote working. Shifting from being in the same timezone as your colleagues to being cross-timezone is another change lots of us will have to adapt to at some point, bringing with it another set of challenges and benefits. If the challenges are well dealt with, then there are notable perks from having members of a team in different areas of the world: customers/clients benefit from the extended hours of support and there is likely to be a greater range of perspectives and viewpoints.
On projects I’ve worked on with teams split between timezones, have been integral to their success. Golden hours in this context refer to the “overlap” between timezones; it’s important to make use of this time in the best way possible. will help to keep communication across timezones in good shape. It should also help relieve pressure on team members to work outside of their preferred hours in order to make progress as a team and resolve blockers. There are a bunch of tools out there that can help with accommodating time differences: I’d recommend , or if on macOS.
These overlaps between timezones are often a useful way for to sync up progress and resolve blockers, although they shouldn’t be relied upon. It almost goes without saying but leaving appropriate detail in tickets and PRs as well as including bug reproductions where applicable will make it much easier for that work to be picked up asynchronously (this is always good practice, not just when working across timezones!).
Don’t Let Your Team Become Static
Nurturing an uplifting and motivational team dynamic is crucial not only for stakeholders concerned about the final deliverables, but also for the members of the team themselves. I've found that working in a team that feels arduous or out of sync (for example) feels discouraging, leading to less productivity as a result; and on the contrary, working in a collaborative and non-judgemental team can feel hugely rewarding and motivating.
It’s worth recognising that change is inevitable, and while recent change has far surpassed anything that most of us have encountered before, we can be sure that change will continue to happen in different forms. When change does happen, remember to focus on:
- Being flexible when joining a new team — not only will this help you align with your teammates, it will also steer you away from rigidity.
- Making changes and experimenting — even if things seem to be going fairly well, who wants to settle for "fairly well" when they could be going great.
- Communication — transparent and free-flowing communication will help your team to pivot and respond to change (particularly when remote). While structure is often seen as something we should avoid, if a little structure aids communication then in my opinion it's worth the trade-off.
- Prioritising team morale — a happy team is more productive. Do what you can to help make your teammates feel comfortable and motivated.