Valuing Roles over Titles

At Argo Digital Ventures, we have a pretty rigid mantra towards “roles over titles.” This is not to say that there is no hierarchy or no leadership, but that it occurs as a more organic process. We like to break our responsibilities into separate disciplines involved in shipping a product, and then further break those disciplines into their required roles. Our team will then assign themselves to the roles (usually multiple roles per person) and work together to achieve success. Every 6–8 weeks, give or take, the team gets together to revisit the roles and re-assign them, redefine them, and add or remove them as necessary. As a result of this process, egos are left at the door, and everyone has a shared responsibility to the team’s mission. This can seem a bit daunting and out of the box, so I think it’s important to see how we got there.

To us, job titles can be useful, but they’re also confining. They can stifle entire projects and hold back personal development. They’re labels, and just like a label on a can of soup, they create a clear expectation of what is inside — if anything else emerges, it comes as a nasty surprise. This kind of uncompromising structure can really bog down projects, leading them into “passing the buck” territory. In this type of environment, people skive off responsibilities that don’t fit the narrow scope of their title. As a team that prides itself on being fast and iterative, in true agile fashion, this sort of gumming up of the works was simply a non-starter.

Additionally, there was a practical reason for having roles drive our team. When we started out, there were only three of us (and at the time I’m writing this, there are still fewer than ten), and we were given titles commensurate with our position within the greater structure of the company — Vice President, Software Architect, and Designer. However, our ideal of operating more like a young Silicon Valley startup did not mesh with typical structuring, so we took an inventory of all of the responsibilities we were going to have to cover in order to push out a product, grouped them into roles, and came up with a list like this:

Roles for a Product Team

  • Product Owner
  • Technical Owner
  • Designer
  • Front End Developer
  • Back End Developer
  • DevOps
  • Communications Liaison
  • Marketing Lead
  • Partnerships Liaison
  • Archivist/Documentation Expert
  • Customer Service Lead
  • Meeting Facilitator

We realized immediately that we were all going to have to take roles outside of the scope of our titles, and things really snowballed from there. We had a meeting where we took our list of roles and defined responsibilities, estimated hours, assigned them to ourselves, and put them down in a big Google doc that’s available here. The estimation, we have found, has been a wonderful tool in determining when it’s time to expand, and when we need to shift things off of someone’s plate.

A bit deeper into this process — when we onboarded our first hire outside of the initial three — we decided to go back to the doc and make some edits, and found that we were able to evolve seamlessly and without any interruption. The new hire took on his new roles with gusto, and the rest of us were able to delve deeper into some of the roles since our plates were not as full. The same thing happened with hire #5, as she too was very eager to come into a team that valued culture over ego.

Being a developer, I’ve been doing a lot of thinking of how this approach is going to scale once we start growing over 20 members or so, or what might happen when there are more people than roles, and I think the solution is a simple one. Divide and start over. As you grow, especially if you are going to be making and maintaining multiple products (I have also started to think of projects as products, but that’s for another post), the best way to stay true to your “lean team” culture and attitude is to have small teams working on those products. Over time, this can naturally get a little hierarchical, as the founding team is looked to for facilitation and guidance. But when you really think about it, that’s just another set of roles to take on, and the process recycles itself anew.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.