Friction Between Product and Engineering
Signs the relationship has become a limiting factor for the business and how to address the problem.
Occasionally I’ll summarize a paper or talk that is not from a research study, but instead shares learnings from experience in an area. This is one of those — an actionable read that I hope you’ll enjoy.
This week I read Friction Between Product and Engineering, an article in a series called called “Bottlenecks of Scaleups” by Tim Cochran, Carl Nygard, Kennedy Collins, Keyur Govande, Rick Kick, and Roni Smith from Thoughtworks. (I summarized an earlier article from this group in October.) Like others in this series, this paper distills lessons from the authors’ experiences partnering with engineering organizations through Thoughtworks.
Here, the authors describe how product and engineering can begin to operate as cohesive team units.
My summary of the paper
As a startup gains traction and grows, two dynamics may surface. More layers of management are created and managers don’t always put in the effort to create an effective working relationship with their peers. The company also needs to decide how to best invest in the product, and needs a holistic strategy for doing so. The authors note that while some functions will naturally work well together, “in the scaleups we work with, we find that product and technical teams are quite separated.”
Startups will see this problem manifest in organizational tension, disruptive exceptions, unchecked technical debt, and velocity loss. “Ultimately, the bottleneck will be felt by reduced organizational performance as it chokes the creation of customer and business value.”
To help with this problem, the article outlines the warning signs that friction between engineering and product is becoming a bottleneck, and strategies for overcoming the problem.
Signs you’re approaching a bottleneck
1. Finger pointing across the organization. “Team members align themselves with their management structure or functional leadership as their primary identity, instead of their business or customer value stream, making it easier for teams to assume an “us” versus “them” posture.”
Examples of this may include product throwing requirements over the wall, treating engineering like a feature factory, or cancelling projects abruptly. Or conversely, engineering missing delivery dates without warning.
2. Engineers often stuck due to the lack of product context. “When product managers pass off features and requirements without reviewing them with the engineers, critical business and customer context can be lost.” A lack of collaboration between product and engineering on requirements can also result in overlooking important dependencies. This often leads to unintended delays or engineers needing to make decisions without context.
3. Work slipping between the cracks. Team members thinking someone else will be responsible for an activity, or conversely nudging others out of the way, are signs of unclear responsibilities and poor collaboration.
4. Technical debt negotiation breakdown. “When product and engineering organizations aren’t communicating or collaborating effectively during product planning, we tend to see an imbalanced investment mix.”
5. Teams communicating but not collaborating. “Teams that meet regularly to discuss their work are communicating. Teams that openly seek and provide input while actively working are collaborating.”
Strategies for addressing the bottleneck
These are the strategies Thoughtworks has applied to overcome this bottleneck when working with their clients.
1. Reinforce the “First Team”. It’s important to identify and reinforce a team dynamic around the creation of value rather than an organizational reporting structure.
The authors suggest two paths for reinforcing the First Team mindset: changing the language used in the organization (encouraging the desired use of the term ‘team’ as well as naming teams can help), and changing behaviors. The latter may be achieved with the help of setting expectations of how teams should operate, and regularly inspecting and holding teams accountable for adoption these behaviors.
2. Define and communicate your value proposition. Ensure that every Product Team member knows how they create value for your business and its customers so they have a shared focus. The authors recommend creating assets (models, diagrams, and maps) that help describe your customer value, economic model, and strategy.
Note: I recently watched a talk about leading teams with maps that may spark ideas here.
3. Create multidisciplinary stream-aligned teams. Form end-to-end Product Teams with every skill and capability needed to create and deliver measurable value. Ensure that they are fully resourced at all times.
4. Establish team working agreements at all levels. Within a lightweight governance framework, allow Product Teams and functional leaders to self negotiate and align on roles and responsibilities. Constantly reevaluate and adjust until balance is achieved.
That may include creating working agreements for cross-functional teams as well as for cross-functional leaders.
5. Negotiate a balanced product investment mix. The diagram below explains the sweet spot of a balanced investment mix. “Over investing with a product feature heavy backlog likely indicates an underinvestment in technical debt and runway, leading to under-engineered solutions, whereas over investing with a technology heavy backlog likely indicates an underinvestment in customer valued features and over-engineered solutions.”
It’s important to spot when the mix is imbalanced and correct it. The authors suggest using data as a guide, which may include:
Collecting individual opinions – does an engineer feel productive and motivated? Does a product manager think the team is efficient?
Productivity metrics – How fast can we test and build a new feature?
View of current state and near-term future state – Are we overcomplicating build out for the sake of future scalability?
Product growth – Do we know how we are progressing towards a product’s goal? Are there enough analytics, user testing and customer feedback to confirm that our product investments are paying off?
Trends – As we build more features or increase users, how are metrics trending? For example, look at metrics like the build time, the lead time to deploy to production, and the amount of incidents. As complexity increases, technical investment should bring them under control, and reduce toil for developers.
The authors also provide this helpful visual for understanding how the relationship between product and engineering changes as the company grows.
Final thoughts
The relationship between product and engineering is talked about often, but it is an area that can appear more as an art than a science. This article serves as a guide for evaluating the relationship between the two functions in your organization and correcting any areas that are off track.
That’s it for this week! As always, reach out with feedback about this newsletter on LinkedIn or reply to this email.
And if you know someone who might enjoy this issue, please consider sharing it with them.
-Abi