How do you transform a bunch of developers → into a team?
For most of us, this is the hardest part of the job. It doesn’t come naturally, and nobody trains you for it. As it’s the hardest, team leaders tend to ignore 'team building', just waiting for it to happen by itself. You are not alone.
Sorry to bash your hopes - it won’t. This is your job. Nobody said being a leader is easy :)
Today I’m going to share the most powerful method to achieve that goal.
But first, what exactly am I talking about?
A Bunch of Developers → A Team
When you read the title, I’m sure you had examples in your head for both cases.
A team you were a part of and enjoyed every moment.
A bunch of demotivated developers, surviving the day-to-day.
From my experience, there are 3 main differences:
1. Working together
⛔ In average teams, people don’t care who they work with. They talk only about work, and won’t mind switching coworkers.
✅ In great teams, people enjoy working with each other. They wouldn’t want to move to a different team. They usually know personal things about each other, like hobbies, and relationships (but that depends on the cultural background of the people).
2. A sense of mission
⛔ In average teams, people work for the near future, one sprint at a time. They tend to care less about the company, and more about the tech side of the work they do (if at all).
✅ In great teams, people know WHY they do things. They understand what the business is about, and how their team is connected to it.
3. Aiming for more
⛔ In average teams, people won’t try to improve processes, just complain about them. They will be quiet at retrospectives, apathetic.
✅ In great teams, people will work to change the processes. They will ask questions, and push to improve the development experience.
There are different ways to build a great team. But I haven’t met one that didn’t enjoy working together, didn’t have a sense of mission, or didn’t want to improve the processes.
The key part - almost every group of developers can become a great team. It’s up to you, the leader, to make it a reality.
The work is worth the effort:
But how?
Team Focus Day
The method
A dedicated time to discuss bigger issues, that are not raised in the day-to-day. I prefer to dedicate a whole day, outside the office. This makes people more relaxed (I did the last 2 at my home, but any place outside the office will work).
Sometimes companies have all-hands offsites, where there is a dedicated time for each team to talk. That can also work.
I aim for a full day every 6 months, with the whole team (PM included).
What to discuss?
It depends on your team and company, and changes from each focus day to the next. Here are 10 ideas that you can choose from:
Spicy organizational chart 🌶️:This I did once, and it was a great success. Go over the organizational chart, and tell some interesting details about people you interact with and the team doesn’t know. Make it personal, and explain the dynamics. From my experience, it helps when the team connects the names in Slack to stories (and faces). Especially in multi-country organizations, your developers might not even know who is who. Even worse - what kinds of roles exist in the company, and what each role is responsible for. Remember, you have much more interaction with the wider organization - share it with the team.
Business review:Talk about the things you know, but your team might not. How were the sales last quarter? What are the struggles of the operations team? Especially in rough times, they will appreciate the transparency. We had a tough start for 2023, and the open discussion of the difficulties, and the reasons for them, helped create trust. When there were layoffs - nobody was surprised.Sometimes the best way is to bring someone else to talk about those things ⬇️
Bring guests:On our last Focus day, I invited our Chief Product & Marketing Officer to join. This gave the team quality time with a senior executive, to ask questions that interest them. Often their only source of information is you, and what you say may be subjective or filtered down.
Roadmap review:Explain the reasons behind the roadmap, and what guided the PM and you in building it (this can be the PM’s spotlight). If there are dedicated quarterly sessions on the roadmap, with the whole team and the PM - no need to repeat yourself. But make sure that the WHY is discussed. We tend to assume the developers understand the reasons behind certain features, but what’s obvious to us might not be so for them.
Retro of retros: Go over all the retrospectives in the last 5-6 months, and summarize the main points. See what was addressed, and what was forgotten. Use the opportunity to decide on 1-2 things that are important for the team, and make sure to implement them. Better yet - let one of the team members take ownership :)The first time I did this, I was horrified to find out that 80% of the things raised in the retros were ignored. With time, I understood it’s not necessarily a bad thing. We cannot do everything.The focused team day is a great opportunity to understand what REALLY bothers the team. That - you should make sure is addressed.
Team rituals:Daily, Planning Day, Team meetings. Nothing should be sacred, open them to discussion and feedback. Are the meetings long or useless? Does the team feel it helps them? Are there any missing meetings? (lol 😂)Before our last focus day, I felt the daily had become a bit too long as the team grew. I raised it during this section, and was surprised to learn the team liked it as it is, and why.
Technical debt review:Ask the team what bothers them. What 3 things would they like to fix the most? Work together on an internal ‘technological roadmap’. Here too, it works best if each team member takes ownership of a small improvement (including you). Sometimes you can identify together quick wins to tackle. Even if it won’t happen, and the ‘technological roadmap’ will be shallow, the team will understand the decisions you make and be less frustrated.
The development process:
Are we satisfied with the designs we receive? (Remember - the PM is here, it’s a great opportunity to discuss that in a collaborative way)
Do we feel we have a good testing culture?
Is the code review process smooth and painless?
Do the people feel they can work autonomously on most tasks?
Explain new initiatives:For example, the team rep, which you might remember from this article. It’s a great opportunity to explain the reasons behind an initiative, and how you expect it to be implemented.
Your values and agenda:You can use a framework such as this one (A manager’s ReadMe), or write something on your own. What bothers you, what you are less good at, what’s important for you.I’ll share mine in a future article :)
Last but not least - have fun! Board games are a great uncontroversial option. After a long day of deep conversations, it’s a great opportunity to relax and bond :)
I suggest choosing at most 3-4 items from the list, to leave some time for the fun and have a bit shorter day.
Summary
As you probably guessed by now, there is no quick way to build a great team :) But a good focus day, can give you a HUGE jump in the right direction.
‘Focus’ days alone though, won’t do miracles. You need to work on an ongoing basis - in 1-on-1 conversations, in team weeklies, in retros. I chose to focus on this single activity, to break the resistance and help you actually try it out. And because I felt it deserved an article of its own.
The 3 main takeaways:
Almost every group of developers can become a great team
Team-building is one of your main responsibilities
Focus days can provide a huge boost, plan them effectively!
I’ll wrap up with a short cheatsheet:
