CTO

Why Product Development Turns Into Herding Cats As Tech Teams Grow

· 4 min read
Why Product Development Turns Into Herding Cats As Tech Teams Grow

Have you ever noticed how things can look so perfect from a distance but less ideal upon closer inspection? It’s like planning a vacation and choosing a hotel based on all the great pictures you see online showing a sea view. But when you finally get there, you notice construction on the hotel right next to yours that wasn’t in the pictures.

Work can be similar. We get swayed by the stories others tell. Everything we read and watch tells a story crafted by someone to achieve a goal. Most stories have an agenda — often to sell you something, whether a service, book, or idea. And the best sales pitch convinces you the product will solve your problems.

Think about it — have you ever bought something because it was sold as the solution you needed? I certainly have, many times, in fact. For instance, I recently purchased a treadmill, hoping to start running more. I used it consistently for about a week before realizing my real issue wasn’t lacking a place to run. The core problem was my lack of focus — I have too many things demanding my attention and can’t prioritize making myself run.

The Struggles of Being a CTO

I am a CTO, and I’m responsible for product decisions in my company — I design this process along with other team members. For a while now, we’ve struggled to get it right. We’ve tried all the trendy practices:

  • Using dedicated product management software
  • Organizing features in Notion
  • Building roadmaps
  • Logging and organizing user requests

But no matter our approach, product development turns into a mess before long. Why? We’re out of the capacity to maintain the proper process.

It’s like buying a treadmill — the purchase alone doesn’t cut it. You have to actually focus on using it daily, following a program.

The Limitations of Small Teams

Scaling a team becomes necessary at some point, despite how productive we may be individually. I learned this lesson working alone as a developer. I could design, code, and deploy an MVP in a week. But to build anything serious, I had to delegate tasks.

That’s why I started assembling a team — a manager to oversee projects, engineers to handle implementation, an analyst to crunch data. This enabled us to take on more ambitious work.

The next evolution level involved further delegation. My manager brought on her own managers, the analyst added analysts, and engineers became tech leads with their own teams. Now, one layer of delegation is not enough anymore.

Consider it like leveling up in an RPG. A talented engineer working solo is Level 1. That engineer founding a company and leading a team is Level 2. Level 3 is when their team members also have teams. Level 4 takes this one step further. This is the natural growth of a tech team.

With more layers of delegation, we gain the bandwidth to deliver more complex projects. But coordination also becomes more challenging. Striking the right balance allows us to scale up without getting disjointed.

The Time Factor

Most product development becomes a hot mess because we need more time. Product management guides often leave out how time-consuming the process is and the need for an entire team to do it properly. A dedicated person must be responsible for collecting all the feature requests, logging them in a database, and grooming that database regularly. Another person should work with product analytics like Mixpanel. Someone else needs to handle support requests — responding to users quickly, asking for details to pinpoint their exact problem, logging all responses, ensuring all requests get addressed, and so forth.

Technology teams need dedicated groups for new features, upgrading current capabilities, fixing bugs, and refactoring code. This separation matters for engineers and all roles — managers, analysts, designers, and QA specialists. When everyone tries to do everything and gets constantly distracted, hitting roadmap milestones becomes impossible.

Adopting New Tech

Adopting new technology poses similar challenges. Over the past year, AI has exploded onto the scene. Tools like GitHub Copilot seem ubiquitous now. AI can generate tests, docs, and perform code reviews — major productivity boosts. Integrating these innovations could benefit any team.

However, someone must actively trial and push adoption. This takes time — evaluating, testing, and training colleagues. It’s not just AI, either. New technologies constantly emerge — ElasticSearch faces TypeSense, Yarn competes with Bun, and Electron with Tauri. This waterfall applies to frameworks and libraries, too.

If tech leads stay swamped, they lack opportunities to research and integrate fresh options. Either free their time by offloading coaching and reviews or have dedicated staff for R&D.

Best Practices in Context

As for the best practices and tools out there, everything should be tried and tested, and taken with a grain of salt. It’s hard to tell what will work for your team or company. The reasons are many. For example, it’s hard to tell who the author’s intended audience was in the first place when writing advice. It’s impossible to directly apply advice from McDonald’s executives who operate a worldwide chain if you have a couple restaurants in your town. Similarly, when you have a 50-person team, listening to advice from a Facebook or Google product manager or tech visionary may not work.

There is, of course, the survivor bias to consider as well. All the approaches you read online are the result of trial and error and likely a million changes made by the teams over time. The advice you see is a product of adaptation to the context of that specific business and the particular people who ran the process. It’s unclear if the companies succeeded solely because of the extraordinary processes they follow now or if other factors like a fantastic marketing and sales department did such a good job.


Overall, while best practices can provide helpful guidance, it’s essential to carefully evaluate advice in the context of your own team and company to determine if it will work for your specific needs. The most effective approach will likely incorporate selected best practices, custom processes tailored to your business, and of course proper team in place where everyone is doing their fair share.


Originally published on Medium.com