Engineers and Product Managers: Striking the Balance in Tech Teams

by Will Sertório

In tech, who reports to whom can have a big impact on how fast you build and how well your team collaborates. Should engineers work under product? The CTO? A combination of both?

Hey, I’m Will Sertorio, Head of Product at Revelo, and today I want to dive into a topic that comes up often when structuring tech teams: Who should engineers report to—the CTO or Product? It might seem like a small detail, but the reporting structure can have a huge impact on how your team collaborates, ships features, and builds a great product. Different companies approach this in different ways, and while there’s no one-size-fits-all answer, I’ve got some strong opinions on what works best based on my own experiences. Let’s get into it.

Different Approaches to Engineering Reporting Structures

In the world of tech, you’ll see various approaches to who engineers report to, each with its pros and cons. Let’s break down the three most common models:

All Engineers Report to the CTO: In this model, engineers across the organization report to the CTO. This means that technical leadership drives all decisions related to architecture, tech stack, and engineering processes. The CTO sets the vision for the engineering organization and makes sure it aligns with the company’s overall goals.

• Pros: Clear technical oversight, consistency in engineering practices, and a unified approach to technical challenges.
• Cons: Risk of engineers becoming isolated from the product vision and user needs, especially if the CTO is focused more on high-level technical strategy than on day-to-day product development.

Engineers Work in Squads with Product and Technical Leads: Here, engineers are embedded in cross-functional squads or teams that include product managers (PMs), designers, and technical leads. The engineers report to their technical leads, who then report up to the CTO, while PMs report to the Head of Product or CPO. This creates a balance between technical guidance and product direction.

• Pros: Better alignment between engineering and product priorities, quicker iteration cycles, and close collaboration between engineers and PMs.
• Cons: If the communication between technical leads and PMs isn’t strong, it can lead to misaligned priorities or tensions between what’s technically feasible and what the product team wants.

Engineers Work Separately from Product Managers: In some companies, engineers are kept separate from PMs entirely. They work with technical leads, but there’s little to no interaction between the engineers and PMs. Instead, the technical leads translate product requirements into technical tasks and manage the engineering team’s work.

• Pros: Engineers can focus solely on technical challenges without being distracted by product discussions.
• Cons: This model often results in a lack of shared vision between engineering and product, which can slow down decision-making and result in a product that misses the mark for users.

My Preferred Model: Product Leading Through Influence

After seeing these different setups in action, I’ve found that the most effective model—at least in my experience—comes down to product leading through influence, rather than direct reporting structures. Here’s what I mean:

In an ideal world, engineers and product managers should be tightly aligned, but that doesn’t mean engineers should report directly to PMs. Instead, I believe that PMs should lead through influence—building strong relationships with technical leads and fostering a shared understanding of what the team is building and why.

In this model, engineers report up through their technical leads to the CTO, but those technical leads work closely with PMs. This way, technical leads remain accountable for the quality of the codebase and technical decisions, while PMs are focused on the product vision and user outcomes.

Why Influence Beats Direct Control

Leading through influence is about building a shared vision that engineers and technical leads can get behind. Here’s why I think this works best:

• It Respects the Expertise of Technical Leaders: Engineers and technical leads bring deep technical expertise that PMs often don’t have. When they have ownership over the technical direction, they’re more motivated and feel empowered to solve problems in creative ways.
• Better Collaboration and Buy-In: When PMs don’t just hand down requirements but instead work closely with technical leads to understand the trade-offs and challenges, it creates a sense of joint ownership over the product. Engineers are more likely to buy into the vision when they feel heard and included in decision-making.
• Focus on the Right Problems: When PMs influence through vision rather than mandates, it encourages a product-first mindset in the engineering team. The focus shifts from purely technical solutions to solving real user problems, which ultimately leads to a better product.

How It Works in Practice

So, how do you actually make this work? It all comes down to communication, trust, and alignment:

• Build Strong Relationships with Technical Leads: As a PM, you have to invest time in understanding your technical leads’ perspective. This means being open to feedback, learning about the technical challenges, and finding common ground.
• Align on Goals and Priorities: Make sure that technical leads understand not just what you’re building, but why. Share user feedback, business goals, and the rationale behind each feature. This makes it easier for them to communicate those priorities to their teams.
• Create Space for Engineers to Innovate: Trust your engineers to find the best technical solutions. Give them room to push back if they see a better way to achieve the same outcome. This way, they feel ownership over the technical implementation, and you maintain alignment on the product goals.

Why This Approach Wins

At Revelo, this approach has led to some great results. Our engineers are empowered to focus on their craft, while PMs work to ensure that the team is solving the right problems for our users. It’s a model that values the strengths of both sides—technical depth from engineering and user insight from product. And most importantly, it allows us to ship quality work without getting bogged down in rigid reporting structures.

So, whether you’re leading a team of five or fifty, consider how you can focus on influencing rather than controlling. Create an environment where product and engineering work hand-in-hand—where the PM shapes the vision, and the technical leads and engineers bring it to life. That, in my experience, is where the magic happens.

Final Thoughts

At the end of the day, there’s no single right way to structure your team, and every company needs to find what works for them. But for me, the sweet spot lies in a model where product leads through influence, not through direct control. It’s not just about who reports to whom, but about creating a culture where everyone is pulling in the same direction.

After all, building great products is a team sport—and the best teams know how to play to each other’s strengths.