Do More With Less Developers

Creating a highly effective development team requires a number of things. Over the years and working on different teams, here's what I've found works.

The team

It all starts with the team and teams are built of people.

The best teams I've worked with are full of smart and creative people. This can be hard to hire for, but it's worth the effort to find these people. What's more important is the people who are not on the team.

No assholes. This could be the smartest person on the team, but if they suck to work with, can't see other view points, and bully people into their ideas, they need to go. They will bring the team to a grinding halt and no one else will want to work with them.

No downers. Some people just have a negative outlook. They ruin teams and need to be let go. The negativity is contagious and will spread to everyone else quickly.

No clock punchers. These types of people fit well in larger organizations, they generally work enough to not get fired. Their attitude is also contagious.

Structure

Highly productive teams are small, cross functional, and self organizing.

In my experience anything over 10 is too big and around 6-8 is ideal. Teams of this size ensure communication is lean and quick. The lead developer can manage a team of that size. And everyone is an important contributor.

That size is also big enough to be cross functional. Everyone that's needed to release the product is on the team. Developers, Designers, QA, DevSecOps and any other role that's needed to get the product to customers.

Teams and companies that are divided by function will be way slower. As a guideline, each additional team will add an extra iteration to the process. For example, if something takes a week to develop. It then goes to QA, adding another week. And if it has to go DevOps or release management, another week.

Team structure and processes are very related and work to support each other.

Teams need to be self organizing. The team should figure out how to get shit done. There can be requirements, but the day-to-day should be up to the team.

This includes deciding who works on what. What tools or processes they follow. How they communicate with each other and how they manage the work.

As the organization grows, there will need to be some coordination between teams, but even then, it should remain up to the teams.

Leaders

Leaders lead and managers manage. You don't need managers on a highly productive team.

Leaders should set the context of work. They should follow the same process as everyone else. They should do the shitty work for the team. They should trust the team do what they're good at. And they should help the team members level up.

Leaders are part of the team, not a level above overseeing the work. That's a manager, often a micro manager.

Leaders take responsibility by following the same processes, trusting the other team members, and being responsible for the work. They don't blame the team for missed deadlines or bugs. And they don't take the credit for the work of the team.

One important note, they don't let team members who are assholes, downers, or clock punchers stay on the team.

They help the team evolve and improve by prompting the team to identify problems and adjust often.

It's easy to undervalue leadership until you've worked with a great leader.

Context

Context is the framework that allows people to make the best decisions for the company without constantly needing to ask someone above them. The more context they have, they less time is spent in meetings and committees trying to figure out what to do.

A clear vision for the company and product is the baseline context that needs to be set. It can change, if communicated clearly. Everyone should know where they're heading. This is like the north star, everyone works toward it.

The company values are additional context, when they're not just marketing copy. If the company has values that are real, people can make decisions based on those values. No meetings or management required.

In my experience startups are generally bad at setting context. Even when doing so can bring huge performance gains to the whole organization.

Setting context isn't only for the company level. It's also used by the leaders to empower teams to be self organizing.

Processes

Teams need the flexibility to do what's needed, without getting sign off for every detail. And they need context around which to base those decisions.

This is where the Team, Leaders, and Context come together to create process. Below are some principles for development that I've seen produce great outcomes. The how can be implemented multiple ways.

Deliver customer value as quickly as possible.

This sounds obvious, but how? The most effective teams I've worked on follow some general principles.

• Deliver the smallest amount of functionality that provides value to the customer
• Automate repetitive processes. Builds, tests, deploys, etc
• The team owns the code base
• Release early and often
• Limit work in progress

I've worked on teams that do these things in different ways. I have opinions on how to do them. The are just my opinions however, and have seen other ways work just as well.

Where next?

This is a high level overview based on my experience working on and leading teams. It has also been influenced and articulated in a lot of books and articles I've read over the years. Here are couple I've read recently and found helpful.

• Extreme Ownership: How U.S. Navy SEALs Lead and Win
• No Rules Rules: Netflix and the Culture of Reinvention
• Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition

Photo by Marc-Olivier Jodoin on Unsplash