More than the sheer amount of work an engineer or team lead in SaaS has, dealing with multiple things simultaneously with unclear priorities really pushes the stress needle. So, what are ideal team compositions, and how do you structure growing teams? How do you deal with multiple priorities? What do stable teams look like?

The ideal team

Stream-aligned, cross-functional, autonomous—there are plenty of words to describe how teams should be built, but in essence, it comes down to the same thing: you don’t want to create dependencies between teams. The theory sounds nice and makes a lot of sense, but it’s a snapshot at best: teams are rarely stable for an extended period. 

Benefits of stable teams

Over the past few years, we’ve seen great results with stable teams. They also enable having clear priorities. When you belong to a single team, your priorities are pretty much the same as those of the team. Whenever you start drifting, the team will either allow it (when there's time and it brings value) or correct your course.

It's not always that simple, though. When you're just a small company, some roles are scarce. Not every SaaS team has a dedicated designer, QA engineer, or DevOps engineer. Things tend to get messy when you're in one of those positions.

The floating team member dilemma

Either you consider yourself part of multiple teams or a floating team member. That means you have to decide for yourself which team to give the most attention to at which time. Of course, teams don't necessarily take the fact that they have to share you into account when planning and estimating, let alone when hell breaks loose in one of your teams.

Establishing a one-person service team

The alternative is to consider yourself a service team, even when your "team" is just one person. You are not part of any team but offer services to other teams. You'll still set your own priorities, but at least now, things are more transparent and open. Ideally, you become a real team (+1 member) and can discuss priorities together. Until then, you can ask stakeholders from all teams to join you in discussing and setting priorities.

While starting your one-person service team might seem like overhead, it can potentially prevent many missed deadlines. It will also reduce frustrations and avoid stress about not knowing what to do first. There are other scenarios where priorities might become difficult. When there are more projects to maintain than there are people, for example, not all of them need both front-end and back-end development. 

Trying to split up your team per project may not be the best option because unless you can afford (and find) tons of people to join the team, you'll be so thin that you end up with one-person teams, and then some people swarming across teams to fill in where the need is high.

Handling multiple projects

So consider your projects and be honest: are they all top priority? Should they all have a dedicated team (read: developer) on them? The answer might be no. If that's the case, having an existing team take responsibility for these projects can help:

  • More people know about these projects. In case someone leaves or is unavailable, others can take over.
  • There's more communication & uniformity across these separate projects. Nothing fun about having 12 projects & 13 coding standards.
  • If one project is urgent, you can focus on it with the entire team, putting the rest on hold. Of course, this only works until all of the projects they are responsible for become a priority. If that's the case and you really can't afford to do them in sequence, it may be time to split the team and see if you can have more people help out on the new teams.

Potential downsides and solutions

Are there downsides? For sure. A team may not be the best option for the next thing in their planning. For example, their balance may be off if an initiative is mainly frontend or backend. They may need expertise they don't have but that exists in another team. But we think there are solutions for all those issues that don't throw away the entire team concept. And if it happens constantly, it's a sign to reform your teams.

Not everyone is fond of stable teams, but we see potential in the right scenarios.