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;DRdynamics 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.
instead of a team.
However, teams and individuals are very different.
It helps to understand particular
The individual contributor.
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. 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.
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.
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.
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.
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?
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.
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, 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.