Why Teams Are Slower, and When That’s a Good Thing

In the early days of a start-up, things move quickly. Entire software features and projects are often completed by a single person.

If the company is successful, however, the team must grow. As soon as this happens, things slow down — a lot — and it is pretty jarring.

I’ve been through this transition as the technical founder at Collage.com.

Not having prior management experience, I naively thought things were slowing down because I was a faster developer, and the solution was to step up recruiting in search of “10x” developers who could pick up the pace.

While technical founders may work more quickly than others, the size of the effect is typically small and the real factors that slow down teams are more nuanced.

Founders Are a Jack-of-All Trades

In reality, there are a few unavoidable things that happen when you transition from individual development to a whole team.

When there’s just one founder building software, that person is the product manager, designer, front-end engineer, back-end engineer, DevOps engineer, QA engineer, etc.

Being able to do all these things decently well is what makes a good technical founder so rare. And because it’s just one person, there’s no communication overhead and things are very fast.

Master of None

Obviously, one person doing everything doesn’t scale. Your first inclination may be to find other generalists and divide up work by product area, as I tried to do when I first found myself in this position.

This is a mistake, however, because it’s not just the workload that’s limited. No one can perform each of the functions part-time as well as an expert who’s dedicated full-time in that area.

To reach a high level of quality for a mature software product, you need a team with multiple specialists.

The Value of Specialists

As you might expect, adding more people to the team adds communication overhead because people need an interface with each other — for example a designer might hand off mock-ups to an engineer.

The initial temptation and trap I fell into as a new manager was to keep this interface as minimal as possible to “reduce overhead.” After all, minimal interfaces are a best practice for software architecture.

The problem lies in a misunderstanding of how human experts work. The real value that an expert adds happens only when they bring their unique perspective to a deep understanding of the entire system, including the customer, market, product, and architecture.

For example, if you just give a QA engineer code and say to “test it,” they will have to make assumptions about use cases and how customers perceive quality in different areas.

If, on the other hand, the QA engineer sits in on customer interviews and deeply understands the drivers of business metrics like churn, then that person will be able to achieve a level of quality unobtainable without that context.

Knowledge Sharing is Expensive and Necessary

The challenge with building a highly functioning team of experts is that you have to externalize all relevant information that was previously stuck in one person’s head.

This means documenting the entire chain of thinking behind decisions, including the supporting data, alternatives considered, assumptions, goals, etc. Only then can everyone on the team have the context they need to perform at the highest level and contribute to the fullest of their ability.

Of course, doing this well takes a lot of effort. A highly effective team might spend a significant portion of their time communicating and sharing context.

Quality Can Be Opaque

During this transition from isolated generalists to a highly functioning team, it can be difficult to observe and appreciate the true value of higher quality, especially from the perspective of the generalist who was doing a “good enough” job before.

Take QA again for example. After adding a QA expert, you might see only a slight decrease in bugs and wonder whether it’s worth the expense.

However, you might not see all the improvements to test execution speed, reliability, readability, and thoroughness of regression coverage, as well as better documentation to make future onboarding more efficient. These things enable others to work more efficiently and prevent testing infrastructure from becoming a major bottleneck down the road.

Oftentimes, the “speed” that technical founders achieve is built on a tech-debt house of cards, and much of the subsequent “slowness” comes from disarming all the ticking time bombs.

It’s not uncommon for new team members to spend most of their time their first year just cleaning stuff up to enable themselves to work more efficiently, which can look pretty inefficient from the outside.

When Slowness is Bad

So far we’ve described the good scenario where teams slow down to improve scalability, consistency, and quality while reducing risk.

However, teams can also just be dysfunctional and slow without realizing these benefits.

So, how do you tell the difference?

How Much Rework is Happening?

In my experience, the biggest canary in the coal mine is rework. If the team is collaborating effectively and reviewing each other’s work at appropriate intervals, then the chance of having to throw things out and start over should be low.

However, if people frequently deliver work that doesn’t meet requirements, or often encounter big unexpected problems toward the end of projects, then they are not planning and working effectively as a team.

Do People Have Context?

Another litmus test for team dysfunction is whether people really do have context, or if they are just being told what to do and left to make their own assumptions.

If you want to assess this, just ask. Does each person know who is going to use the thing they are working on, when they will use it, and what they are trying to achieve? If not, you’re going to get features that work as specified but fail to achieve their goals.

Another extremely important benefit of context is that it helps people know what not to do. A big part of what makes founders efficient is they can identify when to cut corners and reduce scope to achieve 80% of the value with 20% of the work.

To assess this, compare what was specified at the start of a project to what the team actually built and how much time it took. If the team implemented everything without cutting a lot of low-ROI requirements, then there is a problem.

What Are People Doing and Why?

Finally, if it looks like things are moving slowly from the outside, it helps to ask people how they are spending their time and why. If people are spending all of their time churning out new features, that is a red flag.

If you have true experts on the team, they are going to spend a lot of time on important things that you never anticipated. You might find that they didn’t ship any functionality this week because the build was slowing them down and they worked on decreasing the time from 30 minutes to 10. Or they added documentation to the API. Or any number of other things.

Sometimes engineers get carried away with fixing tech debt and need to dial it back to align with business goals, but more often than not they receive pressure from management to spend too little time investing in their future efficiency.

The Bottom Line

Transitioning from a technical founder to a mature development team is a difficult process.

Teams are fundamentally slower than individual generalists due to the cost of sharing knowledge.

However, it’s important to understand that by being more thorough and methodical with multiple specialists, a strong team will outperform even the most brilliant technical founder in the long run.

With the tips outlined here, you can assess whether you are on track for success.