There is a common understanding among startups that if you work for one, you’ll have to wear many different hats. Makes sense right? If you are a 4 person company, you’ll each have to share many different responsibilities to make things work. As many of these startups grow though — even those with 40–50 people, they continue to operate with the same theme. In most cases this is because startups hire people as per need without giving much thought to organization and structure. Establishing a proper structure that works well, early in a startup might be the difference between a company that grows successfully and one that dies a chaotic death.

But first, a disclaimer: I am not an expert of startups, neither do I specialize in organization structure. I have however had the opportunity to work at well known and extremely efficient big companies as well as small and unknown startups. These opinions are based entirely on my observation, and might not apply to every situation.

So let’s jump straight into it. A picture is worth a 1000 words so here’s a diagram representing what we see all the time… and what we should see instead. Once again, this is for a startup that has grown a bit(30–50 person, series A/B stage).

let’s go through the diagram and dissect it a bit…

User Experience Team

I cannot stress enough how important a User Experience Team is at a startup. This is the team that’ll do the deep dive into your users. They will define company’s identity, branding, the needs of the users, the scope as well as validate whether what you’re building is actually meeting any of your goals! Unsurprisingly, most startups have very little understanding of what this team does. So here’s a breakdown of typical roles that you need to have within this team (Note: you can have other roles here, but I’m listing the essentials only)

User Researcher — this person will know your users the best. They will research the user needs, personas, create strategy document (which will define the needs and goals of your products/features) and create/maintain scope documents. In a lot of cases user researchers can also do information architecture working closely with the interaction designer.

Interaction Designer — this person will work with the user researcher to come up with system expectations, content layouts, user flow diagrams and in a lot of cases, low fidelity mockups.

Visual Designer — this person is responsible for coming up with high fidelity mockups and wireframes for your product. They produce all the necessary graphics based on the interaction design work that has been conducted. Understand that good visual designers are not necessarily good interaction designers and if you find one who can do both… hold on to them!

Frontend Engineers — you need a few good ones. They need to be part of the UX team. Why? Because if you group them with any other development team, it will be difficult to break the “form fits function” habit. In other words, most of us software engineers naturally think of features and technology first and then determine what the screens should look like. While that is not wrong in all cases, it doesn’t work well with consumer facing, user-centric products. The mindset we want to inculcate is — user psychology defines product’s form. If your frontend team starts thinking from the user’s perspective, you will have much less conflict when it comes to implementing designs.

So you need to hire at least 4 roles for this team. I understand if this challenges what conventionally makes sense, but ask some of the successful startups — a sound UX team pays back more than 10 folds of what you invest in it.

Backend Engineers

This is one of those teams whose importance is well understood by the community. These are people that are coding up most of the logic for the software. They are experts of data structures and efficient code. One thing that can improve here is to hire people specifically for middle stack. There is quite a bit of logic that goes into the glue that connects frontend with backend — user input handling/sanitation, rest api endpoints, data massaging etc. If even one engineer is hired specifically for maintaining that layer, backend engineers can focus on coding up algorithms, app logic and managing storage without having to worry about http protocols, rest endpoints etc.

DevOps Engineers

DevOps! if there ever was a role that could be considered life savers for startups, this would be it. They play a critical role in making sure your demos go smoothly, your app is up and running, your bugs are caught before it reaches production.They are responsible for establishing the backend infrastructure, the deployment process and they keep an eye on the resources your tech stack is using. They make sure the servers are secure… and the list goes on. They are also a rare commodity so if you find good ones, you do what you have to, to hold on to them.

Data Scientists

Pretty much every company these days deals with massive amounts of user data and I haven’t seen a lot of new startups without at least a few data scientists. But please — stop using them as overpaid backend engineers! They don’t want that… they’re miserable coding up app logic… that’s not why they spent all that time understanding data science. Hire backend developers for that and let data scientists do what they love — data science. Let them run some regression analysis or matrix completion and flex their feature inference muscles. They will love working for you because very few other companies are letting them do what they are good at.

In closing, creating structure as your company grows is not as daunting once you understand the necessary roles and requirements. Structure also should not be confused with hierarchy/bureaucracy (the wretched enemy of fast-paced startups). Defined roles and the right hiring can definitely make a huge difference in how a company operates. This by no means is the only way to divide up your tech teams. I am sure there are many other breakdowns out there that work for you and I would love to hear about them!