Dear future colleague, I suffered from a lack of leadership – but working in a team improved my wellbeing
Read time 7 min
Dear future colleague,
Before I joined Reaktor 4 years ago, I had already been working as a software developer for almost 10 years. During that time I was reporting to several managers, but overall my work was quite independent. I had the freedom to organize my work however I liked. It felt good to be trusted like that.
But when I look back at those times now, I mainly remember how often I felt stressed under my workload and dissatisfied with my achievements. Maybe I wasn’t being the best possible boss for myself that I thought I was. One could even say I was suffering from a lack of leadership.
When I started working at Reaktor, I got acquainted with a new kind of work environment: a self-organizing team. I soon noticed that a large part of my previous negative feelings was gone. Even without a manager looking after me I didn’t feel left alone, there has been a huge amount of leadership available to support me all the time.
Dear future colleague, you should strive to work in a team where you and others are enabled to make collective decisions, without a single leader. It’ll be better for your wellbeing, but for the work you get done as well. Next, I’ll dig a bit deeper into how my day to day has changed since working as a software developer at Reaktor.
I have heard a lot of horror stories about micromanagers. However, at least I haven’t encountered any during my career. My superiors have had so many responsibilities and duties to attend to that they wouldn’t have had the time for micromanagement even if they would have liked to.
The idea that there should be a single leader who would make all the decisions is hard to achieve. In technical subjects, the number of decisions that have to be made can be large. To run everything through a single person would slow the work down considerably, even if the leader would not have any other duties. Besides, it takes considerable time and effort to understand a technical problem if you haven’t personally worked on it.
If a leader can’t make the decisions, they are left for the workers themselves. In this case, people are leading themselves. This makes many things easier, but it can also become a burden. One can no longer focus only on the task but has to do the work of a manager at the same time. A view of the bigger picture that the actual managers often have might be missing.
In teams, decisions can also be made collectively. They are not the responsibility of a single leader, but neither is left for every individual to figure out by themselves. In my experience, this can work very well. Usually, people who know the most about a subject end up shaping the decisions and it is easier for everyone to accept them when they have had a chance to speak up their minds.
Collective decision-making does require using some new tools and mechanisms. Methodologies such as Sociocracy 3.0 have been developed for it. Even more important is that people trust and respect each other. Everyone should be willing to take some responsibility and show leadership.
In my previous jobs, there was always a constant stream of requests, demands, and calls for help from clients and colleagues. I didn’t want to disappoint anyone, so I ended up doing a bit of everything at the same time, interrupting my work when a new important request came in. There was always more work than I could do, it took a lot of effort to manage it all. I demanded too much from myself and was then disappointed as I couldn’t achieve everything I wanted.
When working in a team at Reaktor, we prioritize the work together with the team and the client. We visualize the work so that everyone can see what’s going on and what’s most important right now. The objective is to minimize the number of tasks that we are working on simultaneously so that we can concentrate on just a few things and finish them faster.
Some people usually take more responsibility for this kind of management work, but everyone’s participation is appreciated. We try to be realistic in how much can be achieved and help is offered when something turns out to be harder than expected. When you have the support of the team, it’s easier to say no to less important requests.
It has taken a huge burden off my chest to not have to personally remember and consider the relative importance of every little request all the time. Instead, I can trust that with our system, they will be taken care of at the best possible moment.
I have done my fair share of mistakes during my career, such as overengineering or misunderstanding the problem. In hindsight, I should have asked for more help, but it felt difficult at the time when I was working independently. All of my colleagues were busy with their tasks. I felt that I was the only one who understood the details well enough, after all, it was I who had been writing the software. Maybe there was also a bit of impostor syndrome as I wanted to show that I was able to solve my problems without help.
When working in a team, we try to actively avoid situations where only one person understands a part of the system. Someone is always happy to spar or plan things together. When we share a common objective in the team, helping others helps to reach that and it doesn’t matter if that takes time from your tasks.
In a safe environment, it is easy to admit that I don’t know everything and ask for help from others. I have found pair coding especially effective, getting help requires only a minimal effort in that situation.
Doing a software project alone from beginning to end is a great learning experience and I’m happy that I have had the opportunity to do that. In team projects, however, the scale is usually much bigger. There is space for different roles and specialization, so I have been able to focus more on learning areas that I find interesting. It also helps that there are amazingly talented people in the team, who can teach me a lot.
I found out that teamwork skills are also something you can get better at. Building great teams doesn’t happen by accident. Luckily I was able to attend Reaktor’s internal Team Builder Academy last spring, which taught me a lot about myself and others. When my work has an effect on the whole team, it also feels much more meaningful.
At some point there comes a time in a project, when I can no longer find any new interesting things to learn. At that time it is time to move on to the next one. That too is possible, when I’m not irreplaceable.
In my previous jobs, I often felt irreplaceable, in a bad way. There was no possibility to focus on new projects, as I had to keep on supporting the old ones. I feared that it would take too much time and effort for someone else to be able to continue my work. Even on vacations, I was worrying about what if the software I wrote breaks down.
In a team, the knowledge and responsibilities should always be shared by more than one person. If that’s the case, it is easy to rotate to a new project, since I know that my teammates can handle everything by themselves.
And I don’t have to worry about that on my vacation.
Dear future colleague: A series of letters written by Reaktorians. Come join us, as you are.
Book: The Five Dysfunctions of a Team by Patrick Lencioni. Every team is not a real team. By exploring the dysfunctions teams often have, Patric Lencioni is also describing what a good team is like. All in a short and approachable fable form.
Blog post: Always be quitting by Julio Merino. Good things will follow if you organize your work so that you could quit on the next day.