Collaboration Domination (part 1)

Coming from a background in Investment Banking and Venture Capital, teamwork has always been a critical component of my workflow. Of course, in the finance world, teamwork rarely involves working in cross-functional teams (in bigger banks that sometimes occurs, but less so in smaller firms). In the start-up world, you have many functions within an organization, and so working cross-functionally is a common occurrence. However, true teamwork, or collaboration, across those functions can vary by the organization. More traditional organizations tend to favor more of a “waterfall” approach, where work is handed down as it moves across functions – for example, in product development, workflow is handed down from discovery to concept to design to development. Others, often the more innovation-centric organizations, lean more towards true collaboration – where each member of the team is involved in major decisions and planning, and teammates work closely together throughout the work cycle.

When I first started as a product manager, our organization was tilted towards the waterfall approach. We operated in an agile development process (releasing after 2 week sprints), and we discussed development in sprint planning, but the workflow was separate. Product Managers handled discovery and requirements, sometimes handed down from the sales or executive teams, and then passed those to the engineering team, who divided up the work and began development. Occasionally the engineering team would refer back to product management for direction, but the work was done largely in silos. I didn’t know much else, and the process seemed to work, so I assumed it was the way to go.

At the end of last year, our organization brought in a new executive, with significant experience in collaborative environments, who pushed us towards that model.  All of sudden, the Product Management and Engineering teams were merged into a single Product Development entity, planning was done as a group, and the team was organized by project and staffed cross-functionally – our production and the quality of our work skyrocketed. Below is an example of our old website, build in a water-flow process between our head of marketing and the engineers vs. our new website that was built by a small, cross-functional team consisting of a product manager (myself), a designer, a front-end developer, two back-end developers and our head of Product Development.  Its just the front page, which doesn’t even do it real justice, but its a good example (if you click on it you can see a larger image).

This spike in output and quality got me to think deeply about why collaboration was so much more effective in the long run (particularly because it was slower and sometimes more painful in planning). While I’m certain there are many more drivers, I came up with two primary reasons for the productivity jump. The first is based on the Diversity of Ideas – the benefits of having multiple, varied perspectives and a wide-range of experience-sets at the table. The second rationale for our productivity boost was having everyone “on the same page.” With team members participating in the entire cycle of a project, each teammate was always up-to-speed, and could make quick decisions, pivots and changes. I’ll elaborate on the first idea now, and the second in a post next week.


Diversity of Ideas and the Power of Borrowing them from the Widest Base

There are several components of cross-functional collaboration that yield benefits, although as noted I mention only a few below. Top of mind is the benefit that comes from having a wide range of perspectives, experiences, and thought-patterns being in a single room. Often, in waterfall situations, its management or the Product Owner/Product Manager that develops the vast majority of ideas, and dictates what the result should ultimately look like. However, even though the product manager might have the most relevant experience, or be tasked with driving the product forward, it does not mean that they have a monopoly on good ideas. It also does not mean that they have only good ideas.

Gaining perspective from individuals with differentiated backgrounds not only provides a broader point from which to brainstorm but also generates the opportunity for true “out-of-the-box” thinking (an overused but I think appropriate term in this instance). The perspective of varied experiences allows each member of the team to adapt their thinking based upon insight gleaned from others experiences. Steven Berlin Johnson (@stevenbjohnson), the influential author and entrepreneur, talks a lot about this, in a term he borrows called “exaptation.” His latest book contains a chapter (and I recently saw a great talk he did on it) on this phenomenon, which is essentially the process of taking an existing process, technology or adaptation from one field and adapting it for another purpose. His classic examples include Johannes Gutenberg exapting the screw press, already in use as a wine-making device, for use in the printing press. This also leads into the impact of a “coffee-shop” culture in innovation – discussions with friends/colleagues/etc. outside of one’s normal “box” and learning about the tools and techniques they use in their lives and careers. With that added perspective, we have a much broader base of ideas to work with, and exapation can spark leaps in innovation rather than incremental advances. Indeed, in his book, Steven Johnson ties his exaptation discussion to Apple, a company that many consider to be one of the world’s leading innovators. Despite its insular culture, within its walls, Apple operates with a high-level of collaboration – in each step of the design, production and sales process, team-members from multiple disciplines are involved in planning, leading to a cross-pollination of ideas and ultimately cutting-edge technology and design.

From what I’ve experienced, this type of collaborative, cross-functional environment really does work. Its can be more difficult and painful in planning (as I’ll discuss further in the second half of this post), but the results can be extraordinary. Many of us know the power of a good brainstorming session, and one component of that is the differentiated perspectives brought by differentiated experiences and thought-processes. We can build upon the ideas of individuals, select the best, extrapolate new ideas, and ultimately wind-up in a far better position than when we started. We all think differently and our backgrounds help mold that. True cross-functional collaboration is like a great brainstorming session on steroids – ideas generated from different experiences, and thought patterns can help mold a good idea into a spectacular one.

For example, one of the projects were currently working on is a revised subscription experience for our users – making the options more flexible, better matching pricing to content received and making the entire process more easy for trailers that wish to subscribe. Unfortunately our service is quite complex (which I discuss in more detail below) and its not easy to develop an information architecture that easily describes the status/structure of one’s account. While I came up with an initial idea for our subscription experience, we’ve ultimately decided to scrap it in favor of ideas borrowed from the subscription experience of several tools that our designer and front-end developer use – services that I am aware of, but not enough to have experienced their subscription manager, price list, etc. Despite their original source, they fit with our product well, and we quickly adopted them after our team members were able to introduce the ideas in our planning sessions. Our end product will be further developed from those initial ideas, but they provided the base, and as a team we were able to move-forward and collaboratively determine how the end product would operate. Without cross-functional collaboration, our subscription manager would have never been as good as it will ultimately be (or at least as good as we hope it will be).

In part 2 of this post, I dig into the second half of the benefit of cross-functional planning – getting everyone in sync.

19. July 2012 by Jonathan Drillings
Categories: Imported from VC2BD | Leave a comment