Collaboration vs Non-Collaboration
Working theory - Teams who decide what they’re going to build collaboratively are able to deliver value with increased velocity and quality over time. Even with the correct domain expertise, a non-collaborative environment can lead to several classic pitfalls.
The Team
This post will use an example of a cross-functional team at a SAAS company with some level of autonomy and a set of goals that are inline with the company’s strategy. The teams core domains are product, design and engineering.
Each domain on the team brings it’s own optimized expertise to the table:
- Product — business strategy, customer knowledge, growth models, etc
- Design — customer experience, branding & design consistency, UX, accessibility
- Engineering — technical complexity (delivery time), maintenance, tech costs (infra), system design
Collaboration
If all are present when deciding what to build - trade-offs are surfaced, constraints are established and a deliverable solution is formed. There’s more opportunity to ask:
- Is there another way to accomplish this that would be faster to build or easier to use?
- What if we delivered a smaller, simpler solution first?
- Can we make this a better experience?
- Will this project will drive customer and/or business outcomes?
With balanced collaboration, there’s also a reinforcing feedback loop. The team can build on it’s shared understanding and better navigate future unknowns as they encounter them.
Non-Collaboration
Here’s a few ways to think about non-collaboration, and what it might look like on this team.
Taking each domain’s approach to an extreme might look like:
- Product first - A solution that provides immense value - possibly difficult to use, technically complex or unsustainable.
- Design first - A solution that provides an amazing experience — possibly low value and technically complex
- Engineering first - A solution that is low complexity or technically interesting — possibly low value and difficult to use
If there are only 2 of the 3 domains present, there’s a higher chance of questions like:
- Product + Design - Why does it take so long to build? Why do refinement meetings take so long?
- Design + Engineering - Why are we building this? Why isn’t this profitable?
- Engineering + Product - Why aren't people using it as we thought? Why are there so many help desk requests?
Notes
Deciding what to build certainly depends on the overall culture as well. Do the company ship incrementally, to beta customers, or in a large features announcements? How does the team engage with customers and obtain feedback? What are the limits and constraints for the company - business, market, technology, etc?
Balanced collaboration remains a net-positive given any situation above. These are just more to consider and weight into the decision of “what should we build next”?