Product documents, engineering builds.

That is how most product and engineering teams are structured. Where the product team decides what to build and the engineering team executes.  

And while on paper it sounds like an efficient division of labor, in practice it introduces a whole host of issues. This includes building the wrong product, taking too long, focusing on the wrong goals, low-quality software, low morale, and abandoning the user as the heart of the work.  

But what if it does not have to be that way?  

What if product and engineering got along? Where they are not two different silos trying to work together, but rather two equal partners with shared goals, incentives, teams, budgets, and purpose.

To help us figure out how to create this one team model, where product and engineering are really One Team with One Heart, I interviewed Joel Hames.

Joel Hames, was most recently the Chief Product Officer for Paper (an ed-tech company) where he led the vision, strategy, and execution of its high equity and high-impact educational support system.  

Prior to Paper, Joel also led products at PowerSchool and Schoology.  He has been a product leader for over 11 years and in the education space for over 27 years. His experience spans building products with relatively small teams of just a couple of people all the way up to teams of 30 to 50 product professionals, spanning product management, design, data science, and content.

What follows below is a condensed and lightly edited version of our interview.

Joel, thank you for joining us. This is such a great topic. In almost every organization that I have seen, there is a disconnect between product and engineering.  

But before we talk about how you have tried to fix this problem. Let’s take a step back.  Can you please share with the audience the symptoms/antipatterns you have seen? When product and engineering don’t get along?

Joel Hames:  Mustafa thank you for having me.  I have been looking forward to this myself.  

Let’s start with the question of antipatterns. It’s a good one. I typically see three types of dysfunctions.  

First is the division of labor on product vision and strategy. In a disconnected team, it is common to see that the product owns defines the vision and strategy and does so in isolation from engineering partners. And engineering is responsible for building out that vision, waiting until it’s well-defined to act on it. The two teams may be working on the same thing, but their focus is fragmented and lacks cohesion in purpose.

Second, this divide shows up in budgeting and planning. Each team has a separate budget with a different plan. Everything is done separately. Yes, the leaders may talk. But it is never well integrated, and certainly doesn’t cascade to the team. In a previous experience, the product had one roadmap, and engineering had another roadmap. Reconciliation of this break in planning happened on individual squads and was haphazard and inefficient. This planning fracture undermines even the most talented of teams. 

Last, and this is usually a dead giveaway, is an ‘us vs them’ culture. Even with individuals who swim against this negative current, the overall environment is one where each discipline has separate meetings, issues escalate within departmental lines, and squads struggle with difficult issues due to a lack of a collaborative approach. We see the tension between product and engineering leaders that is expressed in private, and unproductive in public. Value is lost, squad patterns reflect leader biases, and trust and morale erode. 

Completely agree.  Especially your last point.  The lack of value creation is a dead giveaway.  

So let’s flip that around.  What does a good relationship between product and engineering look like?  

JH:  For me, it comes down to this concept of One Team, One Heart. The enculturated belief that the traditional dividing lines between product and engineering are counterproductive, and only by embracing the shared vision and goal of combined teams work, and putting into action with specific, intentional behaviors, can we realize the true potential of building amazing products that delight our users and build our business.

Examples abound. For one, as a product leader, if I get hit by a bus tomorrow, then can my engineering leader partner speak fluently about the challenges we face and where we’re heading? Do they believe and understand the vision and strategy sufficient to collaboratively inspire our teams? And if the opposite happened and I had to lead our technical teams, can I inspire confidence in how we address quality technical construction and delivery? Do our engineers see the product leader as a champion for both the ‘cool’ things we build and the importance of how we build them?

This shared partnership, which starts with leadership and extends to the entire team, must be tightly aligned and clear to all. Where the two teams have a common purpose and work in tandem, individuals are engaged, inspired, and empowered. 

I like that example.  I have never heard the “hit by a bus” example in this context.  But it makes sense.  Tell me what does this concept of One Team One Heart means in more practical terms?

JH:  Yes…sure.

First, to continue with the bus metaphor from above. It is the ability to talk about each other’s work seamlessly and with confidence. This requires the product team to deeply understand what engineering is doing. And for engineers to understand what the product is up to. It’s not like engineering builds and product documents. You can’t have that. You need the two completely in sync with each other complementing each other.    

Second, there is tight alignment on the top. With shared goals and responsibilities. This includes the ability to plan together, budget together, and present to the board together. As one team. Not as product and engineering separately or silos.  

A good example of this is some kind of joint incentive structure for product and engineering leaders. Where the two need to be aiming towards a common goal. Now, in some organizations, that’s going to be some set of top-line metrics that everyone needs to achieve and maybe that’s okay, that’s fine. But in other organizations, where there are more granular incentives, there need to be shared bonus structures as well as aligned personal goals. The key is that you need the two leaders tied at the hip. You can only get anything close to a One Team One Heart mindset.  

Third, is the team composition. And it usually includes representation from product, engineering, design, or data. Depending on what you need. Think of it as an ‘iron triangle’. In fact, this is something I have done in each of my previous roles. Where we create a framework or a standard for team composition, ensuring clarity and consistency in balanced staffing that represents the three key dimensions of our builds: our users, our business, and our technology.

One more thing, and it’s related to the last point, is that the team that does discovery is also the team that does delivery. There is no discovery team that hands off to the delivery team.  The iron triangle stays intact. Now the number of people might change. For example, discovery may need only one individual from each of product, engineering, and data. During development and delivery, the engineering and data team can grow. But the composition, and the representation stays intact.  

The last one, and I can’t overstate the importance of it, is shared success. So one of the most important things I’ve found in bringing the team together is to identify and celebrate short-term successes. This does two things. First, it brings people together because the celebration is essentially a recognition of meaning and contribution. Second, it empowers teams. It builds trust. And third is that it reinforces this culture of experimentation.  

At Paper we used to celebrate as soon as the team got to the earliest testable, earliest usable, or earliest lovable products.  

Do you mind if I pick on the idea of the shared goal you just talked about?  In theory, the idea is that both product and engineering should have the same targets. For example, drive adoption by X%. But in reality, it never works out that way. How were you able to make it work?

JH:  Good question….for it to work you have to go one step deeper.

It’s ok for product and engineering leaders to have the same goal. But then that goal has to be broken down further at the team level and the individual/function level.  

I talked about the iron triangle organization concept above. In this case, the entire team has a shared goal. For example, the team can have a shared goal to improve adoption.  But if engineering wants to improve the developer experience. Then the team shares that goal too.  The team is empowered to debate/discuss/decide how to deliver the adoption goal and to implement internal improvements that help them increase confidence and quality.

The point is that there has to be enough room to allow both partners to do what they want to do and succeed.  And that give and take has to happen first at the top. That is where the tone is set.  And then that allows teams to get much more granular.  

Makes sense.  BTW, I am curious.  How did you come up with this concept of One Team One Heart?  Where have you implemented this in the past?  

JH:  Every organization that I have worked for has been different.  I got my first taste of this concept during my tenure at Schoology.  I was fortunate enough to get partnered with an amazing head of engineering who truly believed in this principle. He championed it, and even wrote a book about it! 

So at Schoology, we had the opportunity to build a great foundation and try some things out. It’s the first place where we did joint budgeting and planning.  We made hard decisions together.  Not in our separate rooms.  

I remember one time, engineering had a ton of headcount but the product team did not. Recognizing the imbalance and how it hurt our productivity, we came together during the planning process to look at our budget holistically. So that we can get more product managers.  I didn’t have to go and make a case elsewhere. I just sat with my engineering leader and we hashed it out.  

It was a game-changer for me.  And then I took this concept and started to build it out at PowerSchool and then at Paper.  

Awesome.  And when you started to bring these two teams together, did you see an improvement in any kind of metrics?  Time to value?  Defects etc.?  

JH:  Yes, of course.

I have to start with this – it takes time, and you have to have patience. At Schoology, we did not see outsized improvement in the first six months. We were improving but the metrics didn’t change overnight. It was about sustained improvement that had an immediate benefit and long-term recognition. Over time, we saw improvement in key metrics like deployment frequency, quality delivery, and roadmap acceleration.  

At Paper, we saw greater value creation and higher adoption rates. We also saw much higher quality deployments and more frequent deployments.  Which we had been missing on our historic OKRs at the beginning. 

And we saw benefits not just in product and development metrics.  We also saw improved morale, retention rates, and it was easier to attract talent.  Especially at Paper, where we scaled the team from 20 to about 180 within 18 months.  It really helped us across the board.

I love it.  The impact is not just in product but on the whole team’s morale.

JH:  Absolutely.  In fact, you can see the effect of the One Team One Heart catchphrase in other parts of the company culture too.  

For example, the team has extended the catchphrase of One Team One Heart, one stomach. Where we were ordering food for our offsites.  Or if we talked about budgeting, it was One Team One Heart, one wallet.

When I saw that, I knew we had created something special.  And I think it is the reason why we were able to build such a fantastic product at Schoology.  Which is why we got acquired by PowerSchool.  

What a great story.  You know you have made it when others start to use your words and make it your own.

JH:  Exactly.

Joel, we are almost out of time.  So let me ask one last question.  Any words of advice or wisdom for product leaders who are trying to bridge this gap?

JH:  Well, I shared a lot of my secret sauce already. But the most important thing that has helped me as I have tried to build this One Team One Heart philosophy is empathy.

This type of change requires a ton of empathy.  In order for you to get close to your engineering partner.  You need to not just understand each other’s work.  But you need to feel their pain and celebrate their success.    

I think this is absolutely critical. It’s about advocating for each other.  If you get this right, then the rest becomes that much easier to implement.  

Great advice.  Joel, thank you for being our guest.  This has been absolutely fantastic.  Oh and one last thing, I know you are looking for a new adventure.  Any thoughts on what type of company or product you would like to build?

JH:  Thanks Mustafa.  This was a lot of fun.  Thanks for having me.  

As for my next adventure, I am taking a moment to reflect on what works, where my talents and passions lie, and where to apply them. I’m quite confident you’ll find me building something amazing, and soon.

Well, I think that is a great idea.  Everyone should take some time off and reflect.  Best of luck.  And then, if you are open to it, come back here and I would love to learn about your new adventures.  

JH:  Thanks.  And yes, I would love to be back as a guest.