Introduction

A couple of weeks back, I helped run a team building workshop for a potato seed startup in Kenya. The team was made of seven people with job titles such as agronomist, caterer and accountant, but when you asked them what they did, they had far more in common than not. Almost everyone was involved in the field activities. Everyone had marketed and sold seed. And when asked if there is anything they didn't want to do, the answer was broadly "no".

This was a team filled with passionate people who thought no role was beneath them or impossible for them. Which raised the question for me of what is the right approach to defining roles and jobs when a team is just getting started. Interestingly it reminded me of a different system design context, composition over inheritance.

Composition Over Inheritance

The idea of composition over inheritance comes from object-oriented programming. It is the idea of achieving code reuse through defining objects' properties that they share with other objects, rather than having them inherit properties from ancestors. To learn more about the programming application of this design pattern, the Wikipedia article does a good job of explaining it. The reason I bring it up is that in essence the distinction between approaches is how you define an object (has-a vs is-a) and this feels directly applicable to defining job descriptions.

While at Amazon Web Services, I found that job descriptions followed the "inheritance" model. I was a manager. I fell under the category of management and my day-to-day was largely defined by this categorisation. This approach creates uniformity, which is desirable in an organisation which values "fungible" employees. Management wants to know that they can move people around and just have them fill the gap. The problem is that this model creates calcified job descriptions that often prevent people from doing the thing that needs to be done. You are evaluated on specific metrics related to your business role and therefore going outside your role is not rewarded and can even be detrimental to your career progression.

When it comes to startups, the opposite model, "composition", is better suited to the business stage. The greatest benefit of composition is its flexibility. Creating a job from a composition of roles does two things. Firstly, it gives the person performing the job agency to determine what they are excited about and what of that overlaps with the needs of the company. Secondly, it establishes the premise that jobs are fluid and they evolve as the needs of the company and the interests of the person evolve. This flexibility is essential in startups.

Also, composition allows for and encourages lateral growth when job title or salary growth are restricted, as is commonly the case in startups. As mentioned above in my observations, employees often take on new but needed roles without being asked. Rewarding and formalising this allows you to celebrate the commitment and passion of those employees.

These discussions around roles can happen in 1:1s or in groups, but having a regular group discussion about everyone's roles will surface any unexpected roles and allow for effective distribution around the team.

Final Thoughts

This is a loose analogy, but one that I found felt natural and pleasing once I saw it. This is not a revolutionary way of seeing things, but it is helpful in understanding ways of getting a small team to cover the broadest range of roles while allowing them to grow and develop agency. Creating the discussions around roles and allowing the team to take them wherever they want to will bring the flexibility and ownership that startups so desperately need.