During the past two years, I had the luxury to be part of a large-scale program that involved several development teams across the world. As an agile coach and scrum master in one of the teams, together with my colleagues, we built a development team that ended up being one of the best crews I’ve been working with so far. However, we didn’t get it right on the first – or even on the second try. There were some important lessons to be learned. In this post, I’ve listed my three most important takeaways.
Encourage active and respectful face-to-face communication
Ideally, all the teams should be co-located. There is no better way than to simply walk to another person and to start asking those questions. This overcomes any other means of communication. However, in a global environment, this is not always possible. Thus, it’s crucial that, if there are multiple teams in different locations, you really need to go out there and meet those people. Or, alternatively, fly them over to your country and make them feel comfortable. This is a must and we learned it the hard way. If you don’t have the travel budget, pick it from your own pocket – I can assure you it will be one of your best investments for the project.
After you have made acquaintances, use video conferencing tools as much as possible in everyday communication. It might feel awkward in the beginning, but again, it will improve how the teams communicate. If the other team does not have the equipment, it’s a great idea to buy them a proper webcam as a gift when you pay a visit.
Meeting people in person, having a laugh and working together, side-by-side makes all the difference. This will also enable people to establish common rules for working together more easily. Different cultures have different customs and e.g. ways of saying things. Like it or not, we also all have sub-conscious stereotypes of different countries and cultures. If the people you’re interacting with daily are mere virtual icons in your teleconferencing tool it easily becomes “us and them”. This is definitively not the setup to be in when you have to deal with more difficult issues.
So, in essence,
- Co-locate the teams, or fly them over to visit as soon as you can
- Get to know people, then use video conferencing tools and encourage relaxed communication
- Beware of “us and them”
Enable the team to evolve and remember to have a safety net
Preferably, the team’s composition should not change too often. Effective communication within the team, building an identity and your sense of humour will take some time, so be patient. Yet, setting the team composition in stone from day one might be problematic. The skillset the team needs at the very beginning of the project is usually different from the skills team members require over a longer period of time. In the beginning, you may need to have more specialists working with, say, concepting and service design. Later on, as the product evolves, the team might gravitate more towards operations or security-related topics.
An experienced team can identify these needs themselves, but it’s worth making this clear from the very beginning: changing the composition of the team is natural as the project evolves and everyone should keep their eye on whether the team has the best fit to deliver at a given time. Of course, the team is usually very capable of learning new things and sharing skills, as long as there is a decent time frame for this. Sudden changes will affect the psychological safety of the team, so avoid hasty decisions – involve the team, they know best what is required.
An external coach can be valuable
The chemistry within the team is something to look after. Even the brightest minds don’t work well together if the way of working simply does not match each other. Active discussion and even strong opinions are quite all right, as long as the team can work things out. However, very strong personalities can sometimes dictate discussion, even unintentionally. In this case, there’s a great danger of losing valuable insights and ideas. To overcome this, the team can take advantage of a plethora of tools available ranging from online anonymous feedback systems to tools used in retrospectives. Also, having an external coach to facilitate these discussions can prove to be valuable. The team should be coached towards non-violent communication and you should lead the example. As a last resort, don’t be afraid to make changes to the team. Having a fruitful working environment weighs more in the longer run, even in the case where the team might temporarily lose some technical talent.
Lastly, the team should take care to produce an easy and fast onboarding process. You will never know when one of your team members finds the love of her life or even a better job opportunity – which is on the other side of the world. For a highly efficient team, it’s a great safety net to make sure that whenever new team members are joining, they will get going as quickly as possible. It will improve the ability of a team to get back in the normal pace and reduces the anxiety of a new member of the team starting anew. Make sure everyone knows how to get started, where to obtain credentials and access rights, where to look for introductory tutorials and so on. And when the new team member joins the team, her insights and perceptions of the project might prove very valuable – especially with regards to the on-boarding process, but also on the project in general. The team might be blind to things and habits that have lost their value a long time ago.
Three key points regarding team evolution:
- Encourage people to step outside their comfort zone to learn new things – remember that changing the team composition should not be the first choice
- However, the skills needed in the project might change over time – involve the team to determine what is required at a given moment and then proceed
- Even the best teams will also face unexpected attrition, so be prepared
Be curious, challenge the status quo and empower the team
The same way as a newcomer to the team can see things differently, so the whole team can see the new project in a different light. There might be something very evident blocking the team on its way to success, which the team can immediately spot. So, challenging existing structures and the status quo should be encouraged.
When it comes to these blockers, there are many sayings, such as “it’s better to beg for forgiveness than to ask for permission”. With this kind of thinking it is often tempting to start from a clean slate. ”Things would be so much easier and more fun if we simply ditched this box here and recreated it ourselves”. Sound familiar? Honestly, if you don’t need it, get rid of it. Still, it’s good to think twice before blindly overhauling all the existing processes and tools already in place. They usually are there for a reason. Before making any big changes, the team needs to understand how the underlying system of work works.
The other point of view is that a fresh team does not yet carry the weight of the organization. Hopefully, the team is free of any strong opinions regarding other departments in the organization. As no bridges have yet burned, the team might be able to approach different parts of the organization in a more neutral way and thus learn more this way. This should be encouraged.
The point is to actively seek the actual users of the system, even if (and especially when) it has not been the custom, or when there is a proxy entity representing actual end-users. What are the users really trying to do – do they actually need this system? This is often overlooked, or users are misrepresented by some other entity. There might be existing tools or structures, parts of the system, that are then, once again, recreated. But the team can easily go on for a long time before really understanding what it is actually building and for whom – or does it even make sense? Once the team really understands the real needs, it should be empowered to make even bold decisions regarding what really should be done next.
In the end, it comes back to active communication. Perhaps it’s about pointing out the elephant in the room no-one else is willing to see. Then, having the right people expressing themselves in a polite but decisive manner – and at the same time being able to express and reason themselves clearly – will make a world of difference.
Remember that
- A new team has ”fresh eyes” – try to benefit from it
- There might be existing structures that, in the end, serve no real meaning
- Understanding the system, i.e. what users are trying to achieve, is the key thing
Conclusion
From my experiences, I can guarantee that building a highly-effective team from scratch is challenging and will require some trial and error. If you work with a global customer and with different cultures and time zones, things will not get any easier.
There are many things to keep in mind, but always make sure that you communicate your intentions, what the team is currently doing and where you are heading next in the clearest and concise way possible.
Do your best to find the most suitable composition for the team. Try to keep changes to a minimum, but always remember to think ahead and have a plan B ready, if and when you are forced to change the team.
Encourage the team actively to seek a better way. Usually, things are in place for a reason and they can always be done differently. The trick is to know whether the features the team is implementing are actually taking the product forward from the real customer’s point of view or are they merely feats of engineering. And finally, always remember to ask why.
