Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, and celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.

The eleventh principle of the Agile Manifesto reads:

The best architectures, requirements, and designs emerge from self-organizing teams.

The idea of self-organizing teams is at the very heart of Simple Thread. Justin and I started the company as two senior engineers envisioning a place where we’d want to work. What types of clients would we work with? What technologies would we use? What architectures? What UX tools? How would our engineers and designers work together? And so on.

In many ways, Simple Thread is the logical extension of a self-organizing team.

So it’s safe to assume we are big proponents of this principle. I think it resonates with most experienced developers and designers: let the people who are responsible for delivering the work have a say in how they perform the work.

However, as with much of life, there are tradeoffs. These potential risks are fairly obvious, but if you’ve never been responsible for running a program or department or large multi-team endeavor, the downsides of a self-organizing approach may not be self-evident.

Risks of Self-organizing Teams

I can feel the traditional project managers out there shuddering at the phrase self-organizing. Are you daft? Let the inmates run the asylum? It may sound like chaos if you let individual teams control how they work.

But in my experience, it actually works extraordinarily well if you find the right motivated people and give them the proper support. A single team will form and storm and all of that, and they’ll eventually get to a place of high performance. The problems really start when you are coordinating across teams – even if they have no dependencies.

Consistency of Team Experience

When I look at managing risks, my thoughts always first turn to our team members. When each team is run differently, the team lead has a huge impact. All of our leads are intelligent, competent, and kind. But even assuming that, there are risks.

For example, leads are often very driven people. It’s common for them to have workaholic tendencies. They might work longer hours and take less vacation than most people. This creates a subtle expectation that everyone on the team has similar dedication. I’m sure many companies encourage this, but for us, working at a sustainable pace is a core tenet. I don’t want anyone feeling pressure to work long hours week after week.

Likewise, team leads are often self-aware and don’t need a lot of feedback. They know their weaknesses and are working on improving them. That’s great, but it can result in a culture of low feedback. Other members of a team might be craving feedback and feeling anxiety or low motivation because they aren’t receiving it.

These issues are not unique to self-organizing teams, but they can be harder to notice if nobody is paying attention to these issues across teams. One team might have great feedback processes; another might have none.

Bias Towards Seniority

More generally, this inconsistency creates an unconscious bias towards processes that are better for more senior team members. If each team self-organizes, that typically means the team lead and the more vocal (typically more senior) folks on the team organize it in a way that feels comfortable for them.

A new team member, especially junior ones, might not be receiving the support they need, but they don’t know how to ask for it. They might not even realize what’s missing. They just don’t feel confident and secure in what they’re doing.

Our team leads are empathetic and generally good at understanding what our junior folks need, but when you get busy, it’s easy to just focus on delivery and let team support activities atrophy.

Consistency of Client Experience

I don’t think I need to belabor this one. If each team operates differently, each client will have a different experience. That’s self-evident. It’s not necessarily a problem, as long as certain baseline goals are met.

For example, we have a mandatory rule that, regardless of how a team operates, we need to be showing work to the client and getting feedback at least once every 2 weeks. Ideally collaboration is more frequent and real-time, but that’s the minimum. I think that’s a reasonable balance.

The trouble is that every process we impose erodes the self-organizing principle. If you’re not careful, managing this risk can slowly create a top-down, command-and-control engineering organization.

Strategic Leverage

The other big issue, beyond consistency and reinforcing certain biases, is that teams have a necessarily constrained view of the world. They are focused on their project, their stakeholders, their working relationships, etc. This is reasonable, but it can also lead to missed opportunities and increased long-term risk.

A concrete example could be something as simple as choosing a CSS framework. If every other team is using Tailwind CSS, does it really make sense for this one project to use some other niche CSS framework? We can’t reuse any components or any of the expertise on the team. It might be a reasonable decision for this one team but at a large cost to the broader engineering organization.

More generally, a team is often incentivized to focus on their project, which may have different priorities than the overall organization.

Benefits of Self-organizing Teams

So if there are real risks, why do we still encourage this self-organizing ethos?

The short answer is that we’re not typists. Our job is not simply to translate requirements into computer-readable syntax. Our team members are experts at solving problems with technology. It would be hypocritical to preach about the incredible value of empowered teams and then dictate every last detail of how they should work.

We could talk about employee engagement and job satisfaction, the fact that people feel happier and more fulfilled when they have a voice in how they solve problems. Motivated team members also create better solutions, which begets a virtuous loop of pride and striving for continuous improvement.

We could talk about innovation and how letting teams try different approaches creates room for experimentation and refinement. Using the same process as everyone else will yield the same results. I want better than that for our team and for our clients.

We could talk about agility and how the inspect-and-adapt cycle is only possible if you let teams influence their destiny.

There are a lot of objective reasons to support this approach. But for me, the biggest reason is somewhat subjective: It’s how I want to work!

Responding to Change

The people inside a team will typically understand their problems the best. I want to work at a company where anyone on a team feels comfortable suggesting solutions.

There are real risks with following too many disparate approaches, which we need to be vigilant in managing. And there are often constraints and real-world limitations that prevent us from following certain paths.

But I want to hear the ideas – not just for how we solve some technical problem but how we as humans interact and collaborate and work side by side, day after day. So many of the best ideas start with, “This is a little crazy but what if…”

For me, that’s the core idea of a self-organizing team – and one of the fundamental ideas behind Agile. We are all empowered to propose better ways of developing software.

In this way, self-organizing helps us bring our very best ideas – and our craziest what ifs – to the table when we face a big, existential challenge.

We as a team can better respond to changes on projects, we as an organization can respond to changes in our industry, and we as a profession can respond to changes in the world. That’s what being agile is all about.