Growing great Laravel teams

A great team can be the difference between a project that soars and one that stumbles.

With the ever-increasing pace of software development, this is more important than ever.

It's not just about hiring the most senior developers you can find. It's a balancing act of structure, culture, and ownership.

For this post, we'll assume you have around 10 developers, and need to soon figure out a better team structure.

Let's cover some common team growth issues and how to avoid them.

Team size & structure

As your codebase(s) and business domain grows, you'll need more developers over time to handle it all. However, you can't also just adopt a "throw more resources at the problem" strategy.

Doing that leads to poorly defined focus areas within the department, as well as a dilution of ownership across the team. Bugs might slip through more frequently since no single area is anyone's direct responsibility. It's also hard to care too much about what your current ticket impacts when you're going to be doing something completely different soon.

Similarly, having one big, flat team with only one manager becomes difficult to lead and manage with so many direct reports. In an ideal scenario, a manager should have around 5 reports, and no more than 7.

Next, it helps to have a mix of seniority levels in a team. A guideline is to have one junior developer for every two non-juniors.

Lastly, you should keep in mind that teams should be cross-functional, i.e. not just developers. This is often known as a pod team. A pod can include other specialties like product management, quality assurance, and design. Pod leadership is ideally split between an engineering manager, technical lead, and a product manager.

  • The engineering manager focuses on people management and team direction.
  • The technical lead handles research and specification of tickets, capacity planning, and is the lead code reviewer.
  • The product manager engages with business stakeholders, the technical lead and the engineering manager to prioritise work for the team.

These pods will then own a particular domain. For example, one pod handles a frontend, while another handles internal staff tools.

Ownership & responsibility

One issue that often comes up with product-oriented tech teams is that they are railroaded in their work instead of having a degree of ownership.

Even within corporations and agencies, tech teams must be treated as collaborators instead of workers.

The clearest reason for this is to prevent a common cause of burnout: lack of control over one's own work.

In other words, a tech department needs to have authority and responsibility over its own work. This does not mean having a fully independent agenda, but it does mean having control of the agenda.

Giving this ownership and responsibility requires trust from stakeholders, both in the ability to satisfy business needs and the tech team's work priorities.

Likewise, good communication is needed both ways from the team and from the rest of the business.

Developer experience

The last factor we'll cover in this post is developer experience (DX).

Why discuss a technical topic in a post about people?

The answer is motivation.

Having a poor developer experience absolutely demolishes individual motivation to get anything done.

Having a codebase that is pleasant to work with requires active maintenance. This involves things like developer tools, time to fix tech debt, and automated quality improvement.

Teams that don't have ownership over their work, often also never get any time to focus on improving the developer experience. That means doing simple work becomes more difficult over time.

Extrapolating from that, it means at some point you'll need to hire two developers to do the work that one used to!

Putting it all together

In short:

Teams should be kept small and cross-functional (i.e. not just developers), with specific responsibilities, and a mix of different developer seniorities.

Tech teams must be treated as collaborators instead of workers, and entrusted to prioritise and handle their own workload.

Lastly, tech teams suffer greatly if a good developer experience is not maintained. Let your team tinker, take care of tech debt, and improve their own tools!

For more reading from other Laravel community members, have a look at Matt Stauffer's recent Laravel Live UK talk on building productive Laravel teams.

This is just the tip of the iceberg! There's never a one-size-fits-all solution at all times, so take this as a good starting point to launch from.