The art of building software: August 2010

Wednesday, August 18, 2010

Multiroling

I'd like to introduce a new term into our team culture / process lexicon: multiroling.

Multiroling.  Noun.  The carrying out of two or more roles at a time.


When assembling a team, you first have to think about the roles you want on the team, and then you go about assigning people to those roles.  You ignore formal HR role names when doing this - you pick the best people for the job.  When a person is assigned to a particular role, they act in the capacity of that role rather than in their formal Human Resources Management Title.  So when I, for example, act in the capacity of product manager, then I do not exercise any authority that my official HR title would give me.

Multiroling is one of the key techniques I use when building a team.  The problem is that you usually don't have an instant, fully functional team.  You build it up over time, usually a few months.  During that time, you don't have all the skill sets needed, but you still want the team to build stuff.  So you create place holder positions for people you haven't hired yet, and you multirole other people into those empty positions until you fill them.  As the team grows, members may shed roles, to be assumed by new team members.  This creates the proper culture and process for the team so that you can grow quickly.

In larger organizations, if a person assumes multiple roles, they may need to engage in matrix management (also known as "dotted line" management) while assuming roles that cross managerial boundaries.  In addition, you may need to become fluent with multiple cultures.

During the course of a typical day, I assume different roles from hour to hour, depending on the type of meeting I'm in or what team I'm interacting with.  Here is the actual current set of roles I'm multiroling:

  1. Interim-vice president of Engineering / Executive team member
  2. Director of Engineering
  3. Product Manager
  4. Architect
  5. Project Manager
  6. Senior Salesman

In order to pull this off successfully, I've found that it works best to be clear about what role I'm assuming before starting a meeting or discussion or email.  I might even start a conversation with something like, "In the role of Architect, I'd say that..."

This is one of the dynamics that makes start-up companies so explosively successful - they are able to multirole.  What happens as an organization increases in size, though, is that people tend to be pigeonholed into one role only.  Some people really like multiroling, so if a company loses its multiruling culture as it grows, then those people move on.

The primary challenges with multiroling are two: First, you simply may not have enough time to do the new role justice - something has to give somewhere.  Second, you may not be well trained in your new role (although maybe you're the best your team has got).  You need to assess whether your skill level is high enough to do the job justice.  It doesn't make sense to take on a multirole you can't really fulfill in any meaningful way.

Perhaps this points to a short coming of our traditional HR organizational structure.  Perhaps we ought to adopt a more flexible HR title that reflects the multiple roles that people assume over time.  Oye, we'd have to print so many business cards as we added and dropped roles over time!  So that's why my current business card actually has the role name "Omelette chef" on it.  Really it does!