If you want to start a music band, you’ll need to think of the genre you are going to play, set a budget, pick the instruments, and so on. All these factors will directly affect the size of your band, musicians’ specialization, their skill sets…you name it! Another thing you’ll have to do is assign roles within a band and make sure each knows to whom they can turn to with their concerns.
With software as a service (SaaS) teams, it works pretty much the same. Your project manager (PM) should embrace the subtle art of structuring the teams in a way that is perfectly aligned with your project goals and capacities. If you don’t have the concrete structure in place, soon enough you’ll find yourself running in circles and achieve little to nothing.
But there’s no reason to panic right now, as the JatApp team is here to back you up. In this article, we will be discussing working SaaS team structures as well as giving some recommendations on how to build a kick-ass team that functions as a well-oiled machine.
Team structuring during different software development stages
Your PM should structure the team based on what your current goals are. There are two major cases that need to be taken into consideration: product discovery and minimum viable product (MVP) development.
Product discovery
The product discovery stage usually requires four specialists: a PM, business analyst (BA), account manager, and user interface (UI)/user experience (UX) designer. If you’ve got an idea for your SaaS product, but aren’t sure whether it’s going to work or not, product discovery is the very first step you need to take in your development journey. During this phase, the team works together to find enough evidence that your product will be viable in the market. In some cases, specialists will have to change your concept to meet the market demands or even suggest you pivot in opposite directions.
The discovery phase may also presuppose developing product prototypes. If you crave for investors’ love, prototypes may help in this regard. A well-functioning team can turn project requirements into a fundraising tool.
MVP development
MVP refers to the version of your SaaS that has core functionality for your users to try it and leave feedback on the product quality. We at JatApp recommend the MVP approach for every project, as it lets you avoid any unnecessary work and allows you to modify the app before starting to invest heavily into its development. During the MVP development stage, you need to gather a team consisting of a PM, BA, UI/UX designer, software engineers, and software architect. As a rule, you don’t need quality assurance (QA) engineers at this stage, as it’s you and your customers who will check the product for viability.
Having discussed team structuring in the discovery and MVP stages, let’s have a look at some interesting approaches that successful organizations use to organize and manage their teams effectively.
Agile is a #1 choice among major development teams
Modern SaaS teams adore the Agile methodology because of its ability to speed up development without giving much headache. Instead of frantically waiting for the “big bang” release, Agile teams complete work in small increments. When a project is split into many small pieces, it’s easier for a SaaS team to check with a client now and then and make necessary changes early on. Besides, Agile teams are autonomous and therefore can respond to market changes faster, compared to traditional team structure, where each team depends on the work of others.
It’s safe to say that Agile teams focus on both quality and communication. And it’s the main reason why it’s extremely important to organize the team members properly. Without further ado, let’s discuss how successful companies approach structuring their Agile teams.
The Spotify model
Spotify, the most popular music streaming platform in the world, experimented a lot with their team structuring approaches. Once the company documented and shared their successes with the world, they literally changed the way technology agencies organize and manage their teams. The Spotify model focuses on dividing people into Squads, Tribes, Chapters, Guild, Trio, and Alliance.
Squads refers to cross-functional autonomous teams that generally consist of 6-12 specialists working on one feature. When several Squads cooperate with each other, they create a Tribe (40-150 people). A Tribe Lead is accountable for managing the work across Squads. Chapters are the group of specialists united by one field to share best practices with each other (PHP developers, DevOps, and so on).
Workers that are passionate about a certain field or topic can build a Guild. A specialist voluntarily enters this team and may form strong bonds with other team members. No awkward team building meetings on Zoom or Slack channels with memes, just pure chemistry between people that share the similar interests.
The Trio is a team of a Tribe Lead, design lead, and product lead. When working on new functionality, they make sure all processes are aligned and everyone is on the same page. When several Tribe Trios cooperate together, they form Alliance. This allows teams to achieve goals that are bigger than those that a Tribe has.
The Spotify approach encourages teams to be more creative, giving them freedom to complete tasks the way they want. The model concentrates on decentralizing decision-making by sharing responsibilities between Squads, Tribes, Guilds, and Chapters.
Amazon’s two-pizzas teams
One of the most successful companies of all times, Amazon, always opts for smaller teams. As a rule of thumb, the team that will be hungry after eating two pizzas is too big to function properly. Jeff Bezos himself, is convinced that smaller teams are much easier to manage, as there’s less chances for disagreements and conflicts. Besides, in small teams specialists tend to be more engaged and focused during task discussions and meetings.
Even though you need to take into account your project requirements, the idea behind the two-pizzas concept is crystal clear. You may want to build teams with no more than seven members to achieve maximum efficiency.
JatApp’s approach
Here at JatApp, our PMs definitely have a superpower to determine the software development team size without getting into trouble. The secret sauce for this is taking project deadlines into account. The less time the client has to build the solution, the more specialists our PM will assign to the project. In some cases, adding more professionals is absolutely necessary, as the success of the product heavily depends on how quickly it will be released to the market.
To structure and manage the team, JatApp’s PMs rely on the concept of Forming, Storming, Norming, and Performing (FSNP). This is an approach that focuses on four stages of psychological development of a team. Let’s see how our teams go through these stages.
- Forming
A PM defines the team size and assigns tasks to each team member. Everyone tries to establish positive relationships within the group to better address a problem at hand.
- Storming
During this stage our PMs are particularly vigilant, as there’s higher risk of interpersonal conflicts and lack of team coordination. Group members may hold different views on a certain subject and even resist joining the rest of the team at all.
- Norming
At this step, team members start to effectively work together and build trust towards each other. Despite a range of differences, they manage to deliver positive results.
- Performing
If any issue arises, team members focus on shared goals and cooperate to come up with the best possible solution. At this point, the software development team structure is fixed, but the team members’ roles remain flexible.
The Forming, Storming, Norming, and Performing model
Tips on structuring a SaaS team
In this section we aren’t going to give you a silver bullet that will solve all your problems with product team structuring. However, by using these tips and tricks you’ll see positive outcomes on how your teams cooperate and how their work aligns with your goals.
Determine who you need for your SaaS project
The team size and structure depends on the needs of a specific project. A typical team consists of a UI/UX designer, frontend developer, backend developer, QA specialist, and PM.
Having settled on the team structure and size, you have to think about the software development team roles. It’s worth admitting that the roles aren’t the same thing as the positions we mentioned earlier. More specifically, if you want a team lead for your project, it doesn’t necessarily have to be a PM. The team lead can be in charge of any stage of the software development process, whether it’s a backend or design. This person acts as a mentor for a team and is responsible for the project success.
Split a team, if it stays hungry after having two pizzas
Amazon avoids big teams at all costs, and on your path to greatness you need to do the same, if you rely on the Agile methodology, of course. Agile software development teams consist of no more than ten members and therefore have less problems with reaching consensus or decision-making. If you feel that your team will ask for a dessert after finishing off two pizzas, you might want to divide it in the following ways:
- By cycle. For instance, you can create a team of a PM, software engineers, and designer to cover the full software development lifecycle.
- By specialization. Another approach is to gather software developer teams or designer teams.
- By development stages. When you know what specialists you’ll need in each development phase, you might want to build a team based on the project requirements.
Shuffle members like songs in a Spotify playlist
Feel free to restructure your SaaS teams, when necessary. At JatApp, we move software engineers between teams regularly and generally have 2-3 coders working on each project. This helps to make sure that all our developers have 100% workload and, if one specialist is on vacation or sick leave, there’s always someone to replace them up.
On top of that, you might also want to shuffle team members to match their interests. An enthusiastic attitude is often as important as many years of experience.
Give your teams more freedom
Agile teams are all about autonomy and trust. Letting specialists change another team’s code, for instance, or select their own development tools helps them pivot quickly. Otherwise, they will become frustrated and will reluctantly do the work that they’re told to do. However, there’s one tiny detail to mention: teams should be mature enough to be able to organize their work independently. If the team is just starting out, chances are they will feel lost and fail to come up with effective solutions because they lack solid expertise and knowledge.
Let your team rock the SaaS scene
As you can see there are tons of different approaches to organizing SaaS teams. At the stage of project planning, you may be tempted to borrow the models you’ve seen in big successful companies, like Spotify or Amazon. While being a copycat of such behemoths is clearly not a crime, we highly recommend you developing your own unique approach to meet your team needs.
Another way to solve your problem with team organization is to turn to JatApp. We have seven years of experience in structuring teams for projects in different industries, from real estate and education to finance and human resources. If you need some proof showing how awesome our PMs are, feel free to visit our page on Clutch. Here’s one of many positive reviews:
“The project manager on JatApp’s side is always in touch with my colleagues and me. We created a Slack channel where we receive progress updates and exchange messages at any time, on any day. Our service manager made sure that the developers share suggestions with us. I always know what to expect from the next milestone. I like their approach.
From a financial point of view, we always know how much we’ll be charged for the next milestone and what functionality to expect. They have the perfect project management approach.”
If you feel like JatApp is the right fit for you, please don’t hesitate to write us a message.
