Defining Roles

Josh Hanson
Greaterthan
Published in
3 min readNov 20, 2017

The goal of our company, Best Water, is to encourage people who live in regions with safe, clean tap water to choose to drink that water instead of spending millions of dollars on bottled water, with all the extra waste and energy that entails. The specific approach is to install taps in public places — unlike water fountains, these would be designed to easily fill a water bottle rather than for drinking directly from the fountain, and they would be built with aesthetics as a primary concern.

This mission involves a wide range of different responsibilities in a huge variety of disciplines — marketing, art, design, manufacturing, sales, law, and policy, to give a few examples. At many traditionally run companies, an executive would design discrete job descriptions, and then try to find employees to fit those descriptions. Our company, instead, is modeled on Percolab’s system of roles: first, the employees (or in this case, the founders) figure out individual areas of responsibility, called roles — smaller and more discrete than traditional job descriptions — and then, an iterative democratic process is used to assign roles to each employee. An employee can have multiple roles, and individual roles can be moved between employees as appropriate.

I joined the team late — in fact, I joined the cohort at the end of the first day. My teammates had already built the company idea, and assigned themselves roles. As I looked through their work, I found they had done an extraordinary job of defining the broad strokes of the company and the variety of roles needed, but there were still lots of details to flesh out — so I took on the role of filling in details — breaking roles into more specific, well-defined roles, and setting clear responsibilities for each.

One part of Percolab’s process was a challenge for us — they set “metrics” for each role, by which the success of the role’s practitioner may be judged. No metric is perfect: metrics are merely a proxy for some aspect of the company’s underlying mission, but the very existence of the metric can encourage employees to seek it out instead of, and even to the detriment of, the mission itself. I feel that, if metrics are to be used at all, they should be defined by whoever is performing the role, only after they have had some time to learn first-hand the challenges and opportunities associated with the work.

Another source of significant discussion was the role that ended up being called “Employee Advocate.” This started out as “Happiness officer,” which seemed too narrow. There was discussion as to whether it was needed at all, since ultimately in a self-managed company, every employee is responsible for advocating for themselves — making sure they are happy and satisfied with their roles, and have whatever they need to work effectively.

At first, I was skeptical about the role’s importance. However, I soon found myself staunchly defending it. I argued that the best way to empower employees to take responsibility for their own success is to give them access to someone who can help them with that very task. If an employee’s needs aren’t being met, finding a solution might be a difficult and complicated process that can only be done by someone with strong people skills, strong emotional intelligence, and detailed knowledge of the skills and roles of everyone else at the company. As I understand it, Percolab solves issues like this with company-wide meetings — an Employee Advocate might be able to resolve many issues much more directly, and could still call for a meeting when necessary.

A slide presentation summarizing our roles can be found here:

And our planning document with detailed role descriptions can be found here.

--

--