The key to any successful startup is close collaboration between product
and engineering. This sounds easy, but can be incredibly difficult. Both
groups may have conflicting goals and different definitions of success that
have to be reconciled. Engineering might want to build a product that is
perfectly scalable for the future with the best developer experience.
Product might want to quickly validate their ideas, and put features out
that will entice customers to pay for the product. Another example that’s
common to see is an engineering-led “engineering roadmap” and a product-led
“product roadmap” and for the two to be completely independent of each
other, leading to confusion for product engineering. These two mindsets
put two parts of your organization at odds. The easy path is to skip the
difficult conversations and operate within silos, coming together
infrequently to deliver a release. We believe that aligning these two
disparate organizations into cohesive team units removes organizational
friction and improves time to value.
How did you get into the bottleneck?
At the beginning of a startup’s journey, aligning is natural because
you are a small team working closely together, and likely the product and
tech leaders had close personal relationships before the company was
founded. The initial startup idea is very strong and as it quickly gains
traction, what to work on next is obvious to all groups. As the company
grows, however, skill-based verticals begin to appear with more layers of
management, and these managers don’t always put the effort in to create
an effective working relationship with their peers. Instead, they focus on
urgent tasks, like keeping the application running or preparing for a
funding round. At the same time, the startup faces a critical juncture where the company needs to
to decide how to best invest in the product, and needs a holistic
strategy for doing so.
Well-run startups are already working in cross-functional product
teams. Some functions will naturally work well together because they fall
under the same vertical hierarchy. An example would be development and
testing — well integrated in startups, but often siloed in traditional
enterprise IT. However, in the scaleups we work with, we find that product
and technical teams are quite separated. This happens when employees align
more with their function in an Activity Oriented
organization rather than with an Outcome Oriented team, and it
happens at every level: Product managers are not aligned with tech leads
and engineering managers; directors not aligned with directors; VPs not
aligned with VPs; CTOs not aligned with CPOs.
Ultimately, the bottleneck will be felt by reduced organizational
performance as it chokes the creation of customer and business value.
Startups will see it manifest in organizational tension, disruptive
exceptions, unchecked technical debt, and velocity loss. Fortunately,
there are some key signs to look for that indicate friction between your
product and engineering organizations. In this article we will describe
these signs, as well as solutions to lower the communication barriers,
build a balanced investment portfolio, maximize return on investment, and
minimize risk over the long term.
Signs you are approaching a scaling bottleneck
Finger pointing across functions
Figure 1: Friction across a typical
hierarchical structure
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.
At its worst the “us vs them” posture can become truly toxic, with little respect for each other. We have seen this manifest when product leaders throw requirements over the wall, and treat the engineering team as a feature factory. They might abruptly cancel projects when the project doesn’t hit its outcomes, without any prior indication the project wasn’t meeting its KPIs. Or conversely, the engineering team continually lets down the product team by missing delivery dates, without warning that this might happen. The end outcome is both sides losing trust in each other.
Engineers often stuck due to lack of product context
When product managers pass off features and requirements without reviewing them with the
engineers (usually within the constructs of a tool like Jira), critical business and customer context can be lost. If
engineers operate without context, then when design or
development decisions need to be made, they must pause and track down the product
manager, rather than make informed decisions themselves. Or worse, they made the decision anyway and
build software based on an incorrect understanding of the product
vision, causing time delays or unused software. This friction disrupts
flow and introduces undue waste in your delivery value stream.
Missed dependencies
When engineers and architects operate with minimal context, the full
scope of a change can be overlooked or misunderstood. Requirements or
user stories lack depth without context. Customer personas can be
ignored, business rules not taken into consideration, technical
integration points or cross-functional requirements missed. This
often leads to last minute additions or unintended disruptions to the
business or customer experience.
Work slipping between the cracks
Tasks slipping between the cracks, team members thinking someone else
will be responsible for an activity, team members nudging each other out
of the way because they think the other team member is operating in
their space, or worse, team members saying “that’s not my job” – these
are all signs of unclear roles and responsibilities, poor communication
and collaboration, and friction.
Technical debt negotiation breakdown
Technical debt is a common byproduct of modern software development
with many root causes that we have
discussed previously. When product and engineering organizations
aren’t communicating or collaborating effectively during product
planning, we tend to see an imbalanced investment mix. This can mean the
product backlog leans more heavily towards new feature development and
not enough attention is directed toward paying down technical debt.
Examples include:
- Higher frequency of incidents and higher production support costs
- Developer burnout through trying to churn out features while working
around friction - An extensive feature list of low quality features that customers quickly
abandon
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. Having regular status meetings where teams give updates
on different components doesn’t mean a team is collaborative.
Collaboration happens when teams actively try to understand each other
and openly seek and provide input while working.
