Collaboration vs Non-Collaboration
Working theory - Teams who decide what 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 poor outcomes.
The Team
We'll use an example of a cross-functional team at a SAAS company with some level of autonomy and goals that align with the company’s strategy. The teams core domains are product, design and engineering.
Each domain brings their own optimized expertise to the table:
- Product — business strategy, customer knowledge, growth models, etc
- Design — branding & design consistency, customer experience, UX, accessibility
- Engineering — technical complexity (delivery time), maintenance, tech costs (infra), system design
Collaboration
If all domains 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:
- Can we make this a better experience?
- Will this project will drive customer and/or business outcomes?
- Are there compounding effects we should consider?
- Can we solve this in a way that would be faster to deliver or easier to use?
- What if we delivered a smaller, simpler solution first?
Balanced collaboration also builds a reinforcing feedback loop. As the team navigates the project and future unknowns, they have a shared map with all the context and trade-offs that can be continuously updated.
Non-Collaboration
Here are a few ways to think about non-collaboration, and what it might look like on this team.
If each domain’s approach is taken to an extreme, it might look like:
- Product first - A high value solution or large collection of features - possibly difficult to use, technically complex or unsustainable.
- Design first - A beautifully designed or seamless experience — possibly low value or technically complex
- Engineering first - A technically interesting or low complexity solution — possibly low value or difficult to use
If 2 of the 3 domains are 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 depends on the overall culture as well. Does the company ship incrementally, to beta customers, or all at once in a large announcement? How does the team engage with customers and obtain feedback? What are the limits and constraints for the company - business, market, technology, etc?
In any case, balanced collaboration remains a net-positive. A team that has a shared understanding of the context and trade-offs is much better equipped to keep momentum and answer the question "what should we build next?"