Continuous Collaboration

Earlier in my career, the idea of the “product manager as CEO” was pervasive.  The view held that the product manager set vision and strategic objectives and was responsible for the success or failure of the thing. As an impressionable young product manager, I took this to mean: control everything! When people deviated from my directives, there would be issues because I was somehow imbued with a vision of right and wrong with product decisions.  Looking back at that behavior, I feel great sorrow for the relationships I ruined and for the harm I caused others.

At my next job, my mentor taught me that “IT is a team sport.” He ignored my delusions of grandeur and helped me understand how to maneuver within an enterprise without alienating people.  I took this learning and went to a place where I worked on teams that taught me to take empathy even further.  At that next job, we practiced and coached a software development style centered around the product team as a balanced unit of social production that valued simplicity, feedback, communication, and courage. I started to see the product team as a potentially radical unit that could maximize the creative potential of its members. 

In traditional organizations, communication patterns can limit the ability for product teams to execute effectively.  Top-down directives from stakeholders demoralize those working closest to the problems experienced by users. Back channeled information creates a differential in who is valued on the team. Gate-keepers can weaponize Information silos against the people seeking shared context, or hold that information for personal gain. These modes of communication create conditions where product teams cannot thrive.  

When we work in teams that strive for mutual respect, systematic consensus, and collective ownership, the demand for communication shifts. Product teams require a new approach to communicate “horizontally” between team members. Since new information comes up frequently throughout the day, we often need to refresh our understanding of the conditions in which we are building a product. In theory, what this means is relatively abstract, but it results in what I call “continuous collaboration” in practice.

Continuous collaboration is the glue that enables product teams to function.  In a world where cross-functional roles need to collaborate on complex features under uncertain conditions, we need to communicate effectively and frequently to ensure the team is aligned.  Without continuous collaboration, product managers may make decisions that degrade the user experience or decide on an implementation that is far more complex than alternatives.  Engineers may assume a user story’s intent, leading to over-engineering, when they could make a more straightforward decision. Stakeholders may be able to undermine the solidarity within the team by incentivizing back-channeling and “hero” development.

When we collaborate in this way, we give team members a chance to have a voice in the decisions and choices that affect their lives - this is empowering. Continuous collaboration exists when the product manager and designer can walk away from a set of user research and say “yes, we feel confident, let’s build” or “nope, we don't feel confident; what's next?”  It’s when engineers can interrupt a product manager and say “hey, we want to go after this refactor that’s maybe a rewrite. Can we talk?” Or a product manager realizes a story is putting pressure on the user interface in an unexpected way and says to the designer, “Something feels weird here. Can we talk through our options?” There are numerous examples where a simple hop to a Zoom room or Slack message can prevent hours or days of extra effort. In short, continuous collaboration reduces wasted effort, promotes collective ownership, and lays the foundation for systematic consensus. 

Additionally, when the team practices continuous delivery and integration, the questions “Should we ship?” and “Can we ship?” are omnipresent. Formalized meetings to check in on status are not sufficient to answer these questions.  When teams are regularly shipping throughout the day, the time wasted waiting for a meeting becomes costly to the team and the users. Therefore, a dynamic method of communication is required to ensure the team is aware of the latest commit, the latest build, and when it is appropriate to push code through environments. In this manner, collaboration may prevent a developer from merging in a branch if the team is waiting for another person’s fix. On teams that deploy separately for the front-end and the back-end, it can mitigate the risk of deploying breaking changes because folks did not know a new version of an API was delivered. In organizations that need to coordinate with Sales, Marketing, or Customer Service teams, they should experiment with involving a partner from those teams with the product team, tied into continuous collaboration, thus enabling just-in-time training or support.

Finally, continuous collaboration creates solidarity within the team and insulates against an organization’s arbitrary limiting effects. When information is shared frequently and decisions made collectively, those involved tend to protect those conditions. Each team member acts as a beacon, sharing those side conversations or one-off requests (from executive leadership, stakeholders, or otherwise) that may undermine the goal of delivering value to end-users. For example, when an executive leader approaches a team member to “Spike out a quick feature for me”, they are introducing a power dynamic that an individual may not be able to confront. However, when that request is shared through continuous collaboration channels, the team can mobilize to process the request and collectively take action to learn more, push back, or build. Ultimately, the request might make the executive feel good, but the product team is in position to determine if it should be built. As leaders see continuous collaboration in action, there is a disincentive to privilege information. Communicating in this manner prevents organizational hierarchies from exerting power to isolate team members. Teams that practice continuous collaboration are able to defend decisions made, articulate strategic direction, and resist the temptation to unnecessarily acquiesce to stakeholder power.

From the outside, it is continuous motion. People are moving, talking, hopping between Zoom rooms, and facilitating their way through a decision. It looks like a full product team collaborating in both facilitated and ad-hoc settings. It’s what interdependence and mutuality look like. Team members bring each other into the conversation because they respect alternative opinions, want to share context, and understand that it takes a community to build great products. Taking a little time out from their “main” tasks enables a more powerful team - an investment into the collective unit’s strength. And yet, the team is anchored to the users it supports, which prevents them from communicating for the sake of talking. Context is shared to facilitate decision making. If a person is missing from an initial conversation, they are caught up in time, trusting that team has made the right decision with the information available.

So how is it done? In a future post, I’ll write about a few things I have done to encourage continuous collaboration.

One final thought, this approach is exhausting!  It requires self-awareness, communication skills, empathy, and the ability to process information on the fly.  Structurally, it necessitates the team finding ways to make the practice sustainable for them. I would encourage teams to reflect on this practice during retrospectives. I personally believe those that can make sacrifices for the greater good should - but I would leave it up to your team to figure that out.  For me, building a product is a powerful human endeavor. Continuous collaboration provides the mode of communication for doing that collectively.