Roles and Responsibilities

Facilitating a Shared Understanding

Context Setting

Working at a start-up is challenging for any number of reasons, but one particular problem that stood out to me during my time at Maven Machines was role confusion caused by inexperience and rapid organizational growth. When a company is very small, individuals are often required to wear multiple hats, such as playing both Designer and Product Manager. This model works well when you have one person making a few decisions. However, as you begin to increase and distribute the number of decisions that need to be made everyday and specialize those decisions, it is important to define who takes primary ownership of what and how collaboration is defined in a team environment.

In my experience, employee burnout is often caused by unclear expectations of responsibilities and the inability to hold boundaries with teammates around them. When members of Maven’s growing Product Organization discussed this as a growing concern, I offered to facilitate a multi-part workshop with both Product Management and Product Design to define our roles and reach an shared understanding of expectations of one another.

preparation

Product Team Framework

While I don’t believe that any one ‘formula’ for product design works in all scenarios, I have had personal success with the balanced team approach that I learned from Pivotal Labs. I chose this particular framework and division of responsibilities as the starting point for discussion. We all came from different backgrounds - some with more experience in product than others. I had all participants watch a talk by Janice Fraser on Balanced Teams before our exercise to create a shared foundation on which to build.

Exercise

As a framework for this exercise I chose a Bull’s-eye Diagram. This exercise is especially good at showing relative importance of things to different people. This would allow us to highlight major differences in understanding and address them as a group to reach alignment. The idea of levels of responsibility also opens up room for more nuanced discussions around shared responsibility and collaboration across disciplines.

Note: I only conducted this exercise with Product Design and Product Management, not with the third pillar of a balance team - Engineering. This was because there was a distinct lack of buy-in from management at that time to take away time from engineers to discuss this. While I firmly believe engineering needs to be involved in these discussions, I felt that after two of the teams reached alignment, it would be easier to bring engineering into the conversation. This would result in a faster, more productive follow-up session. Trying to balance two points of view at a time is always easier than trying it with three.

Execution

Round 1 - Product Design

I set up the Bull’s-eye with Primary, Secondary and Tertiary levels of responsibility. I then defined each level to help guide the discussion. I had made a list of product team activities on the left to kick things off and allowed 5 minutes at the beginning of the session for the design team to brainstorm any additional things I may have missed.

Next, I pulled each sticky note from the left and had the team discuss/vote on where we felt an item fell for them. If it fell either in secondary or tertiary for Product Design, I had us also decide whose primary responsibility we felt it was and I tagged the sticky accordingly.

Overall, this exercise went quickly because the Product Design team was largely in agreement. It was time to move on to do the same exercise with the Product Managers.

Round 2 - Product Management

I repeated the same steps for this exercise as with Product Design. However, unlike the previous session, my role became that of an impartial facilitator instead of also being a participant. The time for discussions between Product Design and Product Management would come in the third session.

The Product Managers had a bit more trouble coming to alignment than the Product Designers. This was probably because while all the designers had education/previous work experience in this environment, the Product Managers were a mixed group: some had education/experience, others had neither. As a result, there was much more discussion and the session ran over-time.

Bringing It All Together

It was finally time to bring both teams together to discuss any differences in understanding. This was the longest session, lasting a full two hours. To prepare for the session, I listed out Product Management’s and Design’s expectations for each role and flagged those where there was misalignment.

Note: The goal of this final session was to reach alignment, not complete agreement. We looked for a majority agreement through voting: it did not have to be unanimous. This was so that we could establish a shared understanding and move the team forward. Any given point could be discussed and re-evaluated in the future but the only way to make progress is to hold each other accountable to something (that something can always change).

After a lot of discussion/voting/re-voting. We were able to place the sticky-notes in one of the three places on a balanced team Venn Diagram. This diagram represented the Primary Responsibilities for each role that we would take forward and hold ourselves/each other accountable to in our day-to-day work.

Next Steps

Mitigation Strategies

My next proposed exercise involved managers evaluating their teams to determine, based on the responsibilities we had outlined for each role, if there were any gaps in skill/performance that needed to to be addressed at Maven. This was beyond my personal qualifications to do to my peers, so I gave the managers some suggestions on how they might approach this in the table below.