The ‘tiny team’ era is here

Software engineering teams are slimming down.

According to Gartner, six in 10 companies will adopt smaller software engineering teams at scale by 2029. The research firm refers to these leaner crews as “tiny teams.”

Small world. Gartner Principal Analyst Aliyah Camacho credits the emergence of tiny teams to AI taking away the grunt work from engineers, allowing for the compression of different roles.

“For example, software engineers or developers can take on more product management or product ownership type of roles,” Camacho told IT Brew. “That’s one example of roles that we see coming together, and as a result, we’re seeing that the size of teams will get smaller, hence the tiny teams.”

She said today’s tiny teams have an average of four or five members, but can have as little as two or three.

Trevor Stuart, SVP at Harness, told IT Brew his company is no stranger to tiny teams, given their “startup within a startup model,” where teams start off small and eventually scale up. But AI is allowing his company to see more efficiency gains from those petite teams, he added.

“AI has allowed us to continue to scale that startup-within-a-startup model further than you could even imagine, in terms of thinking about, ‘Hey, maybe the startup had to scale to 100 developers,’” Stuart said. “But in today’s world, we don’t have to scale to that size and I think that’s kind of at the core of it.”

Think big? Camacho said tiny teams are best suited for companies with a product operating model (a framework where teams focus on delivering a product or product feature, with a priority on customer outcomes) as opposed to a project operating model (a framework where teams focus on a short-term initiative, often involving temporary teams), because smaller teams typically are focused on “delivering specific products or features.”

“If that’s just not how the organization is set up to work yet, it’s likely not a good fit,” she said.

Stuart added that not every software engineering team would benefit from being tiny, adding that Harness has a few teams that are kept larger for various reasons.

“There are likely products that require larger teams due to the complexity of that product, the critical infrastructure nature of that product,” Stuart said. “But then there will be pockets within that organization that are focused on moving quicker, finding routes to innovation, finding ways to move faster, and I think that’s where those smaller teams might kind of fit more.”

Forewarning. There are also a few caveats when it comes to having tiny teams within your organization, said Camacho. One is that your tiny team should be small, but, ironically, not too small because of the risk of losing institutional knowledge.

“If one person who’s very skilled on a tiny team leaves, it shouldn’t endanger the future of that team,” Camacho said. “So, tiny teams are smaller, but not too small.”

Camacho said the best tiny teams also still have diverse perspectives: “One benefit of tiny teams is that they can move faster, but it’s good to still have enough diversity of thought, even if that has some friction to it.”

And finally, Camacho said companies adopting tiny teams shouldn’t neglect their junior talent pipeline: “What we think is a key to success in the future is continuing to hire junior talent to upskill them to have a strong talent pipeline for the future.”