You might have overheard people saying or said some of the following phrases yourself. "I work better on my own," "Pair programming just doesn't work for me," "Other people just don't think the same way I do." Usually, when I hear people say these things, we discuss whether we should spend more time working with each other. Sometimes this comes up during retros, sometimes during post-mortems. People think that these are good excuses not to do something.
Let's change the subject of these statements from "working with others" to "testing." "I work better without tests," "Testing just doesn't work for me," "The test framework just doesn't work the way I want it to."
I would bet that you wouldn't stop testing if the people on your team bring up these excuses. However, I've repeatedly seen that we're (without hesitation) willing to give up collaboration and make more room for solo work.
TL;DR
Working as a team or managing one is hard! Historically, many practices focus on individual contributors instead of a team. However, teams and individuals are very different. It helps to understand particular dynamics that exist whether you like it or not. Also, similar to software development, you can't afford to ignore issues but need to tackle them head-on. Hard tasks need to happen as often as possible so that the team can learn how to cope with them and, eventually, turn them into easy tasks.
The individual contributor
I believe the underlying problem is that even though we're forming teams within our organizations, most performance reviews still happen solely for individuals. When it comes to whether someone should get a promotion or not, we're only thinking about individual contributions. What have you specifically done to get the company further? It bothers me that how I work (tech stack, setup, location) has changed dramatically in the last decade but performance reviews, salary negotiations, and the likes still mostly happen the exact same way. When everything about your work changes, why doesn't the mechanism to figure out whether you're doing a good job or not change?
Even more so, I genuinely believe that if we want to get the best out of our teams, we also need to change how we think about a team's performance. For instance, compensation is usually seen as something tied to a title. What would happen if we'd not tie salary to a title but instead to specific roles that an individual may or may not hold for a certain period? When a junior developer is excellent at writing documentation and finding bugs, why not pay them for that? What if the teams decide who has which roles? I don't know whether this would work or make sense, but I like the sound of it and the flexibility it brings with it.
Working in teams
I've recently participated in a course called modern leadership. One module dealt with team dynamics. A key takeaway for me was that we're inclined to call every group of people a team. However, most groups of people are just that. A group. Not every group needs to be a team. But if we want to turn people that share a manager into a team, this takes effort.
When you form a new team, or the team structure changes considerably, every team will go through five stages. Forming, Storming, Norming, Performing, and Adjourning.
This isn't some business talk but psychology. It will happen whether you like it or not. However, when you cater to each stage and support it in the right way, you're helping the team become the best version of itself. Let's have a quick look at each stage.
1. Forming
We got either a completely new team or some people left or joined. In this stage, people get to know each other. People try to figure out whom they're working with. What do I want to achieve in this team? What do the others want to achieve? Can I imagine working with someone else? Do our values align?
All the above (and possibly more) questions need to be answered because it helps people understand each other. This is essential in the future because it can help understand the actions of others when you know something about their intentions.
2. Storming
After the team has formed, people will now try to assume the roles they think they are best suited for. Prepare yourself for some conflicts. You'll see different ideas of where the team should go and different ways of working. What is important is that you leave room for these conflicts. They need to happen, and they need to be discussed. Sometimes even in great detail. If you're shutting down these conflicts to "get going," you're setting the team up for much more trouble in the long run when it really should be performing.
3. Norming
Conflicts have happened, and people have a much deeper understanding of how they work and their characters. Now is the time to draw up concrete rules. In software, this is where you'd define your definition of done and the likes. You want to document these rules because they become the foundation of how your team works. You can discuss and change them at any point but only when everyone agrees. No single individual is allowed just to break these rules.
Notice how making up rules is the third step and not the first. To me, this screams "individuals and interactions over processes and tools" from the Manifesto for Agile Software Development. Why would we think we can start with the rules if we don't yet understand the people who should follow the rules?
4. Performing
Only now will the team be able to perform. People understand each other, and they've defined a set of rules to follow. With this setup, you got the necessary trust between people to do a great job.
Again, you can't skip to this stage. The three stages before will happen if you like it or not. You can influence how good (or great) the team will perform when it reaches this stage. If you shut down any initial conflict and don't let people create their own set of rules, you'll miss out on a lot of energy.
5. Adjourning
I have to admit I have never witnessed that the "adjourning" stage was properly supported. Let's say a team finished a project it was set up for, or someone leaves the team. Did you acknowledge what this meant for the team, the people?
It is crucial to be aware when the current team setup changes considerably. Why? Because it will mean that the team forming process starts again. When most team members stay the same, it might not take as long, but it will happen. You'll need to make sure that new team members get the same chance to become a part of the team as current ones. You'll also need to look out for people who might want to fill a spot that is not taken by someone else anymore.
Do you think your current team went through all these stages in the best possible way? If yes - great! If not - you can still fix that. I've used a tool called the team canvas in the past, and I think it is excellent! It is similar to the business model canvas but for teams. The whole team fills the canvas together. This exercise takes longer than you think (instead of hours think days) and will lead to a lot of discussions.
What I like most about it is that I can correlate each category to either forming, storming, or norming. However, that's also why it might take you a while to finish it. A good strategy might be to start with "common goals, "values," "personal goals," and "needs & expectations" because I think these are closest to the forming stage. Let what you put in there sink in for a day (or a week) and only then move on to "purpose," "people & roles," "strengths & assets," "weaknesses & risks." These four categories all say "storming" for me. Consider what would happen if someone thinks they are good at something, but then this skill is listed under "weaknesses & risks." You'll have a lot to talk about. Again, let this sink in for a couple of days and then define "rules & activities," which I consider the only "norming" activity.
Talking is hard
Communication is hard. I wrote an article about non-violent communication, but I still struggle to apply that every day. Especially when you need to talk about issues, it becomes complicated. That's why we sometimes tend to avoid talking about something to fool us into believing the issues don't exist. But that makes the whole situation worse.
So why do we do this? I claim that this has a lot do to with the value of the individual contributor. We trained people to think they're not being productive when they don't do the thing they're hired to do. Now, when a performance review focuses solely on you and your output in terms of code or features, resolving underlying issues inside the team seems not to be your job. Because who would spend time doing this when this will actively harm your career progression?
I might have convinced you that we should strive for team performance instead of individual performance at this point. If we want the team to work better together, we need to reduce solo work as much as possible. Because when people don't talk with each other, they'll lose alignment, knowledge transfer, and colossal learning potential. All these things are crucial if you want a team that performs as best as possible.
When something is hard, do it more often
The headline of this paragraph has become one of the things I often say. It applies to sports, software releases, bug fixing, and so much more. Most importantly, it also applies to team collaboration. If you believe that "other people just don't think like you," then this is not an excuse to collaborate less. It is a clear sign that you need to collaborate more! You have just discovered that you're missing alignment with others in your team. And maybe you're the one who needs alignment more than the others.
Pairing or Swarming
Pair programming is a proven technique to get out of your bubble. By working with someone else, you're forced to explain yourself and bounce ideas back and forth. That's great. But it might also mean that you're "just" extending your bubble to one more person.
Swarming takes the pairing approach even further. You pull together as many people as you need to get something done. This might feel slow, but it isn't because you're working towards single item flow. Let me highlight just some of the advantages of a swarm.
Made for distributed teams
One of the most incredible things about a swarm is that the people who participate in it don't need to be the same all the time. Sometimes it makes sense to pull in a designer or product manager, and sometimes it doesn't. If the people don't have to be in the swarm constantly, this also means that teams that operate over different time zones can better work together. When your whole team focuses on one topic, the people who get up early can start together. Working hours should overlap at least a little so that the people who start later can join the swarm when their workday begins. People are now having conversations about the given task which means there aren't any hard handoffs. Some people will continue to work while others stop.
If you lean into this idea, it will significantly impact knowledge sharing inside your team.
Simplify and speed up your process
Have you ever chased down people from your team to review your code? This can be a cumbersome task. It gets even worse when you also have to spend a lot of time explaining to them what you did so that they can do a proper review of your code. Does this sound like fun? It doesn't sound like that to me.
When you're working in a swarm, you have multiple people debating the pros and cons of a particular approach all the time. This effectively removes the need for any further review. You've already shared the knowledge, and multiple people have agreed that the solution you typed is the best one given the current circumstances.
If you take this idea further, it even eliminates the necessity for branches 🤯.
Accelerate learning
For me, the worst part of the individual contributor model is that it slows down learning. When you have to make every mistake yourself and find a solution for it yourself, this takes considerable time. While this might be good from time to time to train your problem-solving strategy it can become very tiring.
Swarming helps less experienced developers to learn more faster. Since the swarm only moves forward when everyone is on board with a solution, senior engineers must explain more. This ramps up junior engineers faster and also requires senior engineers to become better at explaining things. Again, I'll file this under if it is hard, do it more often.
Is your team as good as possible, and what are your thoughts on individual contributor strategies? Tell me on Twitter: @philgiese.