Starters, finishers, and large development teams

When evaluating programmers, it’s very easy to see the value of someone writing a lot of new code. Do not, however, fall into the trap of only valuing developers that write quickly. A healthy project has a mix of developers in terms of values, strengths, and weaknesses.

One productive way to categorize programmers is starters and finishers.

A starter creates a vision for new code and writes the initial version, prototype, or skeleton. Starters usually lack motivation for bringing the project to the next level, making it easier for others to work on the code, or generally polishing. That isn’t to say that they can’t do it — it just costs them much more mental energy than a finisher, so they often don’t.

A finisher, conversely, takes an existing vision, fills in the details, and turns it into something more practical. That might be implementing a spec (and suggesting revisions), rewriting a prototype, filling in a skeleton or tracer, making a project production ready, or making a project easier for new contributors to on-board. Finishers struggle with a blank sheet of paper in the same way that starters struggle to improve the work of others.

Balancing starters and finishers #

“If a programmer takes one month to finish a task, two programmers can finish that same task in two months.”

Anecdotally, this outcome feels true, but it’s the result of an unbalanced team. Teams comprised entirely of starters take more time to bring a project to completion. The problem only gets worse as teams get bigger.

As consultants, we often meet managers that limit teams to 5 or 6 programmers, because experience tells them that adding more to a team will not result in more productivity. This a direct result of hiring/filtering their developers by a naive set of values. They don’t have enough finishers, and more specifically, they don’t have anyone guarding the cultural value of project sustainability, reducing the overhead to contribute to a project. They’ve filled their team with starters because management (and the team) over-values this type of programmer.

Large teams need an additional developer-type #

Within finishers, there are detail-oriented people who excel at making large teams productive by reducing the cognitive overhead of a project. These “sustainability guards” or simply “guards” are bothered by project pitfalls, because they value maintainable and sustainable projects, while most other developers would simply work through and around these problems.

Nowhere are the problems that prevent large teams from being effective more obvious than when on-boarding a new developer into a project. If a project is hard to get running locally, a guard might simply state, “I can’t run your code.” They could, and they will, but really what they’re saying is that they’re going to have to repeat the work of others in order to get the project going; their value for sustainability is being challenged. Maybe the documentation is lacking, there are environment assumptions, or unmaintained dependencies. Maybe there aren’t proper data fixtures, or there aren’t sufficient tests to show the intent of the code. When a guard says that they “can’t” do something, they’re just being overly nice by claiming responsibility; don’t confuse this for incompetence!

Due to their values, a guard will want to make on-boarding smoother. They’ll want to expand and fix documentation and tests, as well as root out code that isn’t self-evident. You should let them do this, because it will benefit all of your programmers, including project veterans. Everyone will waste less time and energy loading the mental context of the project and spend less time on project overhead like repeated debugging and in-project research.

Balancing your teams #

In order have productive programming teams of any size, make sure to keep a balance of starters, finishers, and guards. It’s easy to do yourself a disservice by filtering out programmers who aren’t great starters.

In order to make your programming team efficient as it grows:

• Cultivate a team culture of valuing starters and finishers through hiring and internal discussion. Requiring the same strengths from all of your developers is a recipe for inefficiency.
• Get to know the strengths and weaknesses of all of your programmers so that you can balance them with each other to efficiently produce quality code.
• Make sure at least one of your programmers is a guard that values maintainability and sustainability to keep the project efficient.

It takes all types to make a programming team efficient; merely filling your team with high quality programmers is not enough.

• Next: Introducing Ape ECS (js!)
• Previous: Starters, finishers, and large development teams