Behold, My Stuff

[Home] [Writing] [Links] [CV] [Contact]

Thoughts on Startup Roles

We’re entering our second year of TicketBay being live, and I now see the value of having formal roles within a startup.

It ensures that your team members each have an area of responsibility. This is critical to making sure that team members can specialize and be an expert in their domain. By making sure that each member has a focus, you can simply do more than if everyone does a bit of everything.

There’s an ongoing debate in the TicketBay team about having everyone do a bit of everything so that we can all learn. I think that everyone can try stuff out and see what they like. I also don’t think everyone needs to know the breaking changes from Expo SDK 33 to SDK 34, but at least one person definitely needs to know.

Again, I don’t want to say that only the technical leader can write code. That’s not true; in a team of CS students, everyone can write a React component or an API call. But one person needs to be responsible for making sure all the code actually gets written. Ideally, the person isn’t also in charge of making sure the user base is growing as fast as possible.

As an example, there will be someone in charge of technical work (actually creating the product, maintaining, etc). He/she also will need help, and if there are other capable team members, it’s his/her responsibility to ask for help and not fall behind deadlines.

Note: you could replace technical in the paragraph above with any adjective describing work your team does and it is still valid.

This separation of areas of responsibility ensures that one person needs to worry about the long term goals for one thing.

Without roles, everyone is involved in everything. This is great for learning, but it’s been my experience that things get messy fast and stuff doesn’t get done, because not everyone knows what their job is.

So the moral of the story is assign areas of responsibility, not necessarily areas of work. This makes the team more productive.

Please email me if you have any comments or want to discuss further.


[Relevant link] [Source]

Sam Stevens, 2024