Bigger isn’t better: Smaller engineering teams are the key to innovation

We used to make scientific leaps. Engineers, scientists, and manufacturers once made bold steps and drove the human race forward. Less than 10 years passed from developing jet engines to launching a supersonic aircraft into the sky and 20 years from the first fully automatic computer to one that took us to the moon.

Now? Most engineering teams make progress by the inch, despite their relatively vast resources. Today, design by committee is killing progress.

I believe in design by small teams, who can support each other when times get tough, who can think on their feet and make decisions quickly. The future lies with small groups of engineers, empowered to do great things.

As founders and engineers, it’s our bid to turn back the tide and reinvigorate innovation.

Expansive teams ruin innovation

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

Big companies have enormous teams now, and their agility has suffered because of it. In the old days, small teams could simply decide to work together on a new project. Now, companies like Volkswagen have dozens of engineers designing new gears by committee, and it can take weeks and even months to reach a simple decision.

It’s become part of the culture, but it’s stifling creativity thanks to an in-built risk aversion.

Technology is meant to be agile, efficient, and tight. But when it comes to project management, firms often revert to the “tried and trusted” departments that don’t allow individual engineers to really grab the project by the scruff of the neck.

Departments focus on their particular slice of the task before stitching them together at the end. Along the way, they make a series of compromises to get their job done, which can have a horrendous knock-on effect when combined with the other departments’ own hacks. In the end, everything runs over time and over cost. To me, that doesn’t come as a surprise. It’s just a result of the way teams work today.

Lessons in bloat with Microsoft Bob

Microsoft Bob was a classic example of a big project that had all the ingredients, but the final dish was a disaster. This user-friendly interface was meant to replace Windows Program Manager — only the end result wasn’t user-friendly at all and most potential customers couldn’t even use it.

By the time it was unveiled in 1995, the software demanded more performance than pretty much any computer on the open market could provide. Microsoft Bob was withdrawn from the market in less than a year and remains a salutary lesson.

The final objective of Bob was to be a user-friendly interface that runs on any computer. It was a classic case of losing sight of this very objective.  

Fred Brooks can also tell us all about the failure of big software projects. He did just that in his seminal 1975 book “The Mythical Man Month.”

Brooks took charge of IBM’s 360 Project, the largest non-military mainframe project of the day. It was a lesson in bloat. As the project fell further behind, IBM threw more resources and people at the project, only to watch it get worse.

Brooks came to the startling conclusion that every time the company added a programmer, the project fell further behind. This single thought formed the basis of his book, which revealed that as you add engineers, you also need to add unproductive and yet essential coordinators.

That comes with in-built communication problems and inefficiency. So adding more manpower to a software project will just make your problems worse.

A stain on the Blue Oval’s history

Elsewhere, the Ford Edsel project has become a case study in how not to build and market a product.

This goes to show that abundant resources and large teams can be a huge factor in failure.

This premier car for middle-class Americans was a disaster from the start. It was designed by a chaotic committee and the company revealed 18 different versions at the launch.

Worse was to come. It was meant to be a luxury product, and the first cars were delivered with oil leaks and push buttons that couldn’t be pressed without the help of a hammer. This is a clear example of different departments trying to force their own solutions through and creating square pegs for round holes.

Ford took the sub-brand off the market entirely in 1960 and the car that was named after Henry Ford’s son is a stain on the Blue Oval’s history.

The lesson is clear. You need individuals’ driving forces to take total ownership and focus on the design of the product.

That’s why small companies, with the founder at the helm, can often overcome impossible odds to make a better product. The results speak for themselves.

There’s still much to learn from Jobs and Wozniak  

Simply put, look at Steve Jobs and Steve Wozniak, who built the Apple I together in a garage in 1976. Jobs agonized over everything in his early computers, from the looks of motherboard design to sifting thousands of shades of beige for the casing of the Apple II.

In the very beginning, the pair had no engineers to oversee and they only had to coordinate themselves. That is how two men managed to design the Apple I and II, which would spawn one of the greatest tech companies of our time.

WhatsApp is another example of what you can achieve with less. Founder Jan Koum actually used a budget coder from RentaCoder.com and did most of the other work himself. When they got seed money, they rented cubicles in the HQ of Evernote. They opted to stay small and turned down the VCs banging on their door. They wanted to stay focused on the product and knew that a large team would have distracted them.

Together they could react to the constantly shifting app network to help WhatsApp evolve into a messaging app that Facebook later paid $19 billion to acquire. When the deal went through in February 2014, Whatsapp had just 100 employees.

Changing directions for a big team is like turning a ship around. It takes time. But a small team can react instantly and that’s a vital trait in a constantly shifting market.

Two pizza rule with Jeff Bezos

That’s why Amazon’s Jeff Bezos has the “two pizza rule.” He says he doesn’t have meetings with groups that couldn’t be fed with two pizzas. Amazon is the world’s biggest retailer and this clearly isn’t a financial decision. Bezos simply knows that communication in small groups is more efficient.

Realizing the benefits of small teams, other big companies are now splitting their own staff into startup-sized units. GlaxoSmithKline has de-scaled research teams into small groups of eight to 60 people and it believes this will drive innovation.

This isn’t a new concept. In the 1970s a small team of Volkswagen engineers took the company’s Golf and worked in their spare time, with passion and drive, to create the Golf GTi that went on to become one of the greatest performance cars of all time. It was developed in a private garage, by a group of eight people.

They followed in the footsteps of Lockheed, which has had a Skunk Works team since the 1940s and coined the term “Skunk Works” when first placing a handful of their best engineers in a circus tent outside their factory to work on a special project. Its greatest hits include the U-2 Bomber, SR-71 Blackbird and P-80 Shooting Star.

The latter was the first US jet fighter plane, developed by a team of 28 engineers, completed before schedule and under budget. Free from the shackles of management, Lockheed’s engineers created icons that remain unparalleled compared with today’s aviation industry.

So, it might be tempting to simply throw money and resources at problems, but it isn’t necessarily the answer. Many of our greatest innovations have come from small teams that have been given a free reign to create masterpieces. It’s a model that is open to us all, and it’s a model that more companies should think about using.