Putting together the Software Dream-Team

Forenotes from 2023

This post was originally published on my blog on April 16th, 2017 as part of my Daj Się Poznać 2017 blog post series 🖋️. This was a very special post to me as team building, teamwork, and collaboration have always been topics close to my heart. Fast-forward to 2023. Over 6 years have passed and I've had 100s of opportunities to experiment and gain invaluable knowledge in all those areas since then. Would I write this post differently today? Oh boy, most definitely. The more I think about it, the more I believe this post deserves a 2nd edition! Some examples listed below make the old me giggle at the then young, naive me 🙂. I would certainly put more emphasis on the fact that context matters a lot, and that there is no one-size-fits-all solution to these problems. How I approach QA activities as a developer also changed drastically. Nevertheless, I still stand behind some of the ideas mentioned below, and it's nice to be able to travel back in time and see how one's perception evolves. Anyway, here we go👇

Putting together the Software Dream-Team

If you read some of my previous posts on this blog, you will find that I am equally interested in both the technical and social aspects of Software development. As I explained in Oh no, why is my software broken again? - A scary IT story, statistics appear to show that most problems Software professionals encounter are not in fact technical but rather social. Based on my own experience, I am very inclined to believe those figures.

On my quest to understanding how we could make and deliver better Software, I often wonder what I would do if I was given the difficult mission to assemble the ideal development team from scratch – the Software Dream-Team, if you will. I guess it’s time to put my thoughts in order and lay them on paper!

First, we need to define what such a team will be tasked to achieve. For the sake of the exercise, let’s assume that the lucky guys will be working on a product aimed at Italian restaurant businesses: A web-based pizza manager with both cloud and on-premises data hosting options. As the product itself is available under a monthly subscription business model, the team will have to deliver new features very regularly to keep customers from going to the concurrence. All this while guaranteeing good performance and stability, obviously. Seems like there’s a lot on the agenda, so we’d better pick the right guys for the job! Since we’re at it, let’s add an additional challenge to the mix. Turning the pizza manager into a successful project will certainly be a long-term endeavour and therefore we also want our team members to be happy and proud of their achievements. Customer satisfaction starts with employee satisfaction.

The usual suspects

Who will we need in our team to make our pizza manager the killer app it deserves to be? Let’s list the usual suspects we encounter in Software projects and try to pick the ones that’ll be useful to us.

• Business analyst (BA)
• Project manager (PM)
• Release manager
• Back-end developer
• Front-end developer
• Tools developer
• QA specialist (QA)
• Test automation engineer
• Software architect
• Graphic designer
• UX designer
• Database administrator (DBA)
• Network specialist

That’s 13 roles already. So let’s hire 13 guys and rock’n’roll, right? RIGHT!? Not really. This would most probably end in a real communication mess and this is precisely what we want to avoid. Our goal is to deliver Software, not to manage a circus.

How many individuals should we hire then? In my opinion, the magical number is probably 5. Why 5? Because there were 5 Power Rangers (not counting the green or white one, those guys joined later on as external consultants!), and that was one hell of a team! Look at that!

More seriously though, I believe that having a team composed of 4 to 6 individuals is ideal because it doesn’t introduce too much communication overhead while still providing significant Software firepower. There is a problem though: we listed 13 positions above but we only have 5 team members to fill them in. Luckily, I might have an answer to that. I believe that people should ideally hold 2 roles within a given project. Not more, not less. Let me expand on that.

Why not more than 2?

• Every team member must understand precisely what is expected from him and others within the project, and having too many roles introduces unnecessary confusion: “What is this guy doing? Is he our manager, our back-end developer or our DBA?” “Wait, am I supposed to look at that from the BA perspective or as a Tools programmer?”

• Constantly switching between roles often consumes a non-trivial amount of time. This time could be better spent doing some actual work on the project. People usually try to compensate for that by introducing more planning into the project, but that’s just like solving a problem by introducing a new one.

Why not less than 2?

• Having several roles can prevent someone from getting tired of doing the same things over and over again. Boredom and mental fatigue can be a real productivity killer.

• Having several roles gives team members different paths to explore and more career options. It also allows people to have a wider perspective on the project. This can contribute to the overall happiness and sentiment of ownership of the individual.

“Very cool, Ricardo! 5 times 2 equals 10, so we can cover 10 roles out of 13 already!” Not so fast. There are a few more aspects that we need to take into account in our equation. What if our main developer decides he wants to take a vacation (crazy, I know!) or gets hit by a bus (the first cause of mortality amongst developers)? We can’t really afford to put the whole project on hold just because one individual is missing.  This is why we need some roles to overlap.

We already defined that each team member should hold 2 roles. Let’s go further and introduce the concept of major and minor roles. The idea is that each individual should spend around 70% of his time or effort on his major role and the remaining 30% on his minor role.

With this in mind, we need to make sure that each of the most important roles for the project is covered by 2 team members: as a major role for one and as a minor role for the other. Aside from partially solving the problem above, it brings two more things to the table:

• A natural knowledge transfer within the team.
• The possibility to work in pairs to tackle more complex problems.

However, not every combination will do just fine, as some roles may be more difficult to pair than others. During my career I’ve had the “chance” to experience this at several occasions. Here are a few examples of combinations that may be problematic:

development + project management tasks

Those two aspects are fundamentally different. Project management requires to swiftly deal with the unexpected and remove the obstacles as they come so that the rest of the team remains focused and undisturbed. This requires from the manager to go back and forth between tasks and to shift his priorities. On the other hand, a developer needs long, uninterrupted sessions of focused work in order to be efficient. According to several surveys, it takes a developer between 15 and 30 minutes to fully go back to his programming bubble (also called the zone) after being interrupted by a phone call from the client or by the project manager asking “Do you think you can finish this by lunch?”. A few interruptions like those are synonym to a day lost for the developer.

Development + QA tasks

Writing Software and testing Software are two very different activities. Quality Assurance is a job on its own and should be handled by professionals. In practice however it is not rare that developers are the only ones to test their own creation before releasing all hell on the poor end users. What are the issues with this approach? A developer may unconsciously be more indulgent toward his own work and half-ass the testing. Or they may end up in the situation illustrated below:

Something that I do in my current project in order to mitigate this is that I try to leave a buffer of a few days between the moment I finish the implementation of a task and the moment I start testing. It allows me to somehow “forget” about the implementation details and have slightly more impartial testing sessions. This only works to an extent though, as I will naturally be tempted to test the happy paths only (at times I won’t even have enough knowledge to come up with negative test scenarios). As another downside, it will also take me longer to bring a given task to completion.

The Software Dream-Team?

Taking into account all the parameters explained above, this is how my Software Dream-Team would probably look like (for each member, the first item is his major role while the second is his minor role):

Member 1: Business analyst + QA specialist
Member 2: QA specialist + Test automation engineer
Member 3: Back-end developer + Front-end developer
Member 4: Front-end developer + Back-end developer
Member 5: Graphic designer + Front-end developer

Let me explain some of my choices. Member 1 and Member 2 can work together on gathering requirements (BA) and making sure those are properly implemented (QA). This is an idea that I already submitted in Help yourself and your programmers by writing better specs!. Having test automation skills will definitely help the team efficiently measure the overall quality of the product while new features are being added.

Member 3 and Member 4 are both full-stack developers, but each they specialise in different areas (back-end vs front-end). Member 5 is mainly a graphic designer but can also collaborate with Member 3 and Member 4 on implementing the front-end, if need be.

What about the remaining roles?

As you may have noticed, my Dream-Team contains only 6 roles out of the original 13. What happened to the remaining 7?

There are 2 roles that I long considered before finally deciding to exclude them:

• Tools developer. I believe that using the proper tools is a great step toward success in an IT project. Having a dedicated Tools developer might be helpful, but nowadays there is a ton of great tools out there to help you solve almost any technical challenge you could think of (logging, caching, data persistence...). And chances are that those are probably better today than your home-brewed custom library will ever be.

• UX designer. All other technical aspects equal, UX might be the most important criteria for consumers to choose between two applications. Does that mean you need a dedicated UX designer? I don't know. Maybe you could treat UX as a separate cornerstone of your application and have all your members work on it. Or you could pay hourly an external UX designer to help you when necessary. This is a question that definitely deserves some thoughts.

The following 5 roles can be in my humble opinion ignored:

• Project manager. I don't think that a dedicated project manager would bring much to the table here. Our members should take all the global decisions regarding the project as a team, be it the planning, budget, or overall direction. This will also reinforce the general sentiment of ownership within the team.

• Software architect. Once again, I believe that the all members of the team and especially Member 3, Member 4 and Member 5 should be knowledgeable enough to take all the technical decisions as a team.

• Network specialist and Database administrator. With all the Cloud hosting options available today, maintaining your own infrastructure and servers might not be the safest and most cost-effective solution. Aside from the cost of the hardware alone, there are dozens of aspects that could potentially turn your business into a nightmare if done wrong: server backups, security updates, customer data confidentiality, network monitoring, load balancing or scalability... You name it. Your dollars will be better spent on platforms that do all that for you, out of the box.

• Release manager. If you still do releases manually, then you might be doing something wrong. Your release process should be automated and include all sorts of tests to guarantee an acceptable level of quality to your customers. Releasing a new version shouldn't be more difficult than pushing a button. No need to have a dedicated release manager for that.

That concludes this post on my Software Dream-Team. I hope this constitutes a good base for reflection on the topic. I'd like to thank Michał "MSI" and Piotrek, two of our awesome QA specialists at Infusion, for giving me precious input and helping me better understand their job. Also big thanks to Agnieszka for making those great illustrations for my posts on demand!

If you have your own idea on how the ideal Software team should look like or have suggestions about the above, please leave a comment. I'd be very interested in your opinion!

Until next time!