I remember the situation like it was yesterday. I was leading the Product and eCommerce team for a large retailer, and Black Friday was only four weeks away. At our October check-in with the executive team, I’d told the CEO we’d be delivering several features to improve checkout conversion, which would increase revenue by as much as a million dollars.

I wasn’t just trying to make myself look good. Like any competent leader, I’d made the commitment only after discussing the situation with the appropriate teams, and my partners in Engineering were in lock step. Within a week of my meeting with the CEO, though, things had changed. During a load test, a scalability issue had been discovered, and it would require the full focus of our Engineering team.

The Engineering leader asked what I wanted to do. Should we continue to focus on the features we’d promised, or pull the team off of feature development to focus on system stability? I don’t remember it being a hard decision. “Those features aren’t going to do a lot of good if the system is down,” I said, “let’s shore it up.”

Healthy Tension?

A lot has been written about the importance of “healthy tension” between Product and Engineering teams, and on the surface, it makes good sense: if one team is focused on building new features and the other is focused on code quality and stability, the tension between them might encourage discussion and debate, and neither team will lead the company off a cliff. In fact, the theory goes, this “healthy tension” might lead to compromise, somehow delivering the best of both worlds. I disagree.

The problem, I think, is in the assumption that Product and Engineering teams inherently have different goals. They don’t – or at least they shouldn’t. Both teams are responsible for the growth and stability of the company, for revenue and scalability. Neither can succeed without the other.

When we assume otherwise, we sell each side short. Any good Product Manager will tell you there are times when addressing technical debt is the smartest use of development resources, that the push for new features needs to be balanced with a view towards system health. And any good software engineer will tell you that the world’s most performant system is useless unless it drives business results, that sometimes it’s worth taking on tech debt to take advantage of a market opportunity.

Think of it this way: if you were building a house, you wouldn’t expect your architect and your builder to simply hand off their work, you’d want them to collaborate around shared goals to make sure they were in agreement. A good architect would never design a house that couldn’t be built, and a good builder wouldn’t build a house that was poorly designed. We should expect the same from Product and Engineering teams.

A smart and logical group

“At a basic level,” according to this AHA.io blog post (and many others), “product managers should tackle the ‘why’ (product strategy) and ‘what’ (features) for the product. Engineers should determine the ‘how’ — the technical implementation of features.” While this may be true at a basic level, it’s not the way great Product Development teams work.  In my experience, great teams – the ones that are most engaged and produce the best work – are the ones where Engineers are involved in defining the “what” and Product Managers weigh in on the “how.”

This is because Product Managers and Software Engineers are often among the smartest, most logical employees a company has, and they tend to be very capable of both understanding business goals and coming up with creative ways to achieve them. When we neglect to give our teams the full context of what we’re trying to achieve, we make it harder to solve the problem, and also to commit to the solution.

This takes time up front, of course, but when a Product Development team has conviction that they’re solving the right problem in the right way, they can move fast with trust and confidence. And when something goes wrong, as it inevitably will, the team members have the context they need to address the issue in a way that still meets the goal of the project.

Product Development teams

I’m not saying there’s no place for “healthy tension” at a company. As this Product Plan article points out, “there’s a reason you don’t see titles like Vice President of Innovation and Compliance. A little tension is good.” For a company to be successful, it needs to have people with different perspectives, and there needs to be lively debate.

But tension between departments is different. I prefer to think of Product and Engineering teams as combined Product Development teams, making sure they’re in lock step as it relates to goals, strategies, and priorities. As this Martin Fowler article points out, “aligning these two disparate organizations [Product and Engineering] into cohesive team units removes organizational friction and improves time to value.”

I’d encourage all of us to adopt more of a Product Development mindset, acknowledging that Product and Engineering teams cannot thrive unless they’re joined at the hip.

A note on org structure

In my current role (as in my last few), I’m responsible for Product Development, which includes Product, Engineering, and Product Design. Despite my own experience, I don’t have a strong bias for all of these functions reporting to a single leader – I’ve worked with great CTOs and VPs of Engineering, and without the right leader, combining teams can be a mistake. My point in writing this post is not about having the right org structure, it’s about having the right mindset, which can exist in any structure.