Team vs Solo – benefits and challenges

Who is this post for?

Team in an indie world

I chose this topic for a blog post because for the past few years I have had experience in leading IT teams and helping people grow by coaching them. I’m not a professional coach or a manager with 20 years of experience. But I’m fascinated by how a leader can influence people, and I’ve already seen some of that in my own teams – and that’s what I’m trying to do, with some success already, I dare say.

In the indie world, we often start alone. To be perfectly honest, I tried both worlds quite extensively. Keran Labs is a brand that I built completely myself (with some AI help) and I have no human team. On the other hand, I’m a Product Owner and people leader at my day job. It’s an interesting combination because I get to see the upsides and downsides of both worlds. And as disappointing as it may sound:

There is no perfect solution. Working in team or solo… it all depends on your personality and motivation level.

Why work in a team?

Here are the less obvious things:

• Team has a way of pulling each other up – a bad day can happen to everyone. A day when you are just demotivated and don’t want to do much. Having a team with whom you can talk to, complain and share can be very beneficial mentally and also productively. In a good, mature team, the people care for each other and motivate each other to do more and to do better.
• Leader is like a parent (of small kids) – based on my personal experience with some teams, I often feel like a father figure trying to keep small children in line, keep them entertained with cool tasks and allow them to shine to their maximum based on their work. Sometimes I have to be strict, sometimes I have to be caring, sometimes I just have to be understanding. It really comes down to this and even if you have people of mature age in your team, they all need this kind of caring. Teams fall apart usually due to bad leadership who doesn’t care about these things, it’s a common opinion. So if you are a developer and your boss checks up on you, tries to find you tasks that usually seem achievable but slightly challenging, gives you feedback and pointers on how to grow – you can count yourself lucky. If you are a leader who does these things, then most likely these actions will not be so noticeable to the management or even your team. Some might even say “he/she is only sitting in meetings all day”… that’s our reality.
• Every small conflict destabilizes the team – there is a nice theory (by Tuckman) about team maturity and stages each team goes through. From the forming phase (a.k.a. sniffing), to storming, norming, performing and adjourning. The most interesting ones that most teams spend majority of time is storming and norming. It is quite rare to see a team that is in the performing stage, doing their absolute best and using their maximum potential. It’s quite a beautiful sight, but rare. What is interesting though, a team can be in that best stage and still go back to the storming phase, where some conflict arises and suddenly productivity goes down, people are stressed and anxious. It can happen to the best of teams. This is another example how the leader is the key role to step in and try to remedy the situation and help the team progress back to the best stage. Conflicts will always be there though, how your leader handles it is where he/she really can shine.
• Agile? Waterfall? Agile-fall? – most likely if you work in an IT team, you are working in Agile model. It is quite rare these days to find other models, even though they exist and different companies experiment with them. None of them are perfect. My advice – don’t push Agile like a holy book you have to follow to the letter. Take the best of it and adapt it to your situation, to your needs, to your team needs and to your business. Some say Agile makes everything be delivered slowly – there’s probably some truth to that. But the main idea is that you deliver what is expected without burning the people on your team out – that part is usually skipped when criticizing Agile.
• Toxicity – at some point of your career you might meet a person that can only be described as toxic. They are there, I have no idea what drives them. Sometimes they will point out your biggest mistakes in the whole forum in front of your boss, sometimes they will steal credit for your work, sometimes they will harass you in some other way… My advice – toxicity in workplace is always a hard no. Even if the person is a genius knowing the system in and out, I’d rather replace him and have a friendly and ambitious junior willing to learn and being able to respect the team. The problem is, management (not leaders) often perceive these toxic geniuses as necessary evil we have to live with. I firmly believe that’s an incorrect way because even though you might have this evil craftsman on your team, chances are he will drive other people to switch jobs, get burned out or worse. As a leader, I believe your job is to ‘eliminate’ such toxic behaviors in the team and if not possible, ‘eliminate’ the person from the team.
• Influencing without authority – this might sound familiar to some, there’s a quite famous book about it (I recommend to read it). In one my side projects we decided to start a small digital business with a group of friends, 5 of us specifically. In the end, it’s still a team. The problem with such friendship-based teams, it’s very difficult to appoint one leader. Because we all start as “founders”, we are all the “board members”. But you know the saying “Too many cooks spoil the broth”. That’s one of the main challenges of such teams, people are afraid to offend each other or dominate each other because they are friends. But the reality is, when you decide to start a joint-business, you are not only friends anymore, you are also associates. Your main priority is your “company”, not friendship. So there has to be someone who will take the role of that leader, even if he might jeopardize the friendship. It’s hard and even in our small side-business we struggle to find the right leader and we do have a lot of conflicts which sometimes even stops the business for some months… still, we keep on going. My advice, even if you start something with friends – be serious about it, treat it as a job, not as some epic party.

Then maybe going solo?

It all depends on your personality type and motivation levels

It’s quite simple. Each of these roles gives me different experience that I use to grow. Each is very valuable either for my social, functional or technical skills. I would advise to everyone to stay open and do not focus only on one way of achieving your dream. It’s a journey and you can choose which part you want to do alone and which part you want to share. But let’s cut to the chase and focus on bullet points… I love bullet points…

• Being on a highway to burnout – when you are an indie developer and you get to make all the decisions, you tend to drown in an ocean of features you’d like to implement. In my other blog post about Design process, I mention how important is to ship fast something that is relevant to your audience, test fast and improve. In this point, I’d like to focus on another aspect of it. If you decide to build a great app with 100 features and then you spend ever evening working on it for the next year… you will burn yourself out, become more stressed, and lose track of what’s important in life (family, friends, love). Being the captain of your own ship is great, but be sure you don’t get lost in the vast sea.
• When to stop? – similarly to the first point, when going solo you might be tempted to create an unrealistic scope because you’d want your app to be the best there is. In the other blog post here I wrote that you should not aim to create a perfect product on your first try. Focus on a smaller scope but very well tested with the market to see if that’s what people want. Adapt and adjust as needed and then keep improving.
• Remaining consistent is a challenge – I’m not talking about working x hours every day, I’m talking about consistency in style and quality. If you are one person, this means no one reviews your code, no one reviews your designs, no one challenges your ideas. You might end up doing 10 features in one app and each feature looks and feels different from the other… you might even come up with some wild and funny ideas just for the sake of being wild and funny. This is the real challenge and I’ve faced it a lot. I am always tempted to do something unique that doesn’t quite fit the style of the app. I really have to pour a bucket of cold water on my head and remind myself that I am building a product, not my personal playground. And users will be able to tell if you are going crazy with the design and quality.
• A flash in the pan – that’s the closest translation of a saying in Polish that directly translates to “straw zeal”, meaning something very weak and quick to break. When working solo, no one is there to motivate you to keep going. When you spend debugging a feature for the last 2 weeks, you might just get tired of it and do something else. In the end, you have no deadlines, you are doing this as a side-gig after your work. Maybe you will have some 2-week vacations along the way where you disconnect completely. This is often the reason indie developers give up – life gets in the way. It always depends on your life circumstances, but my advice is – your dream doesn’t have a deadline. You can build an app in 1 year or in 10 years, what matters is that you keep going and never give up. Even if you had 6 months of a break, you can still come back and no one will judge you for this. I had various projects that sometimes took years to finish even though, if I was consistent, I would have finished much sooner. Still, once I have a project in mind, I tend to finish it, no matter how much time it takes.

Lessons learned

For me what worked best is a mixture of approaches – I started doing things solo, then I gained a lot of experience doing things in a professional team and finally I learned a lot by having a small “friendship-based” team. In my opinion, be open to all options. Even if people will tell you that you jump between tasks and never finish something properly, you will at least gain experience and learn something new. I’m sure at some point, this will pay off for you and for me. What I suggest as a practical takeaway:

• Try at least one solo project and one team project in the next 2 years.
• If you go solo, set clear boundaries to avoid burnout.
• If you lead a team, be ruthless with toxicity.

Thank you for reading!