Typical Roles in a Software Startup
What are some of the roles in a typical Software Startup?
Given the situation we all find ourselves in 2024, I’ve surely seen an increase in the number of LinkedIn Posts that relate to unemployment where, in many cases, folks have been looking for a while. And while I’ve always had the urge to try and provide some help (as small as it may be), it has not been without its share of challenges either. One of the first bottlenecks I’ve run into is that my knowledge and experience are limited to Software Development, and while I believe it covers a whole gamut of roles (almost) within that area, that isn’t what everyone who is looking for work is hoping to get into. Obviously.
Folks from all walks of life are looking for jobs at any given time, but I’ve had people ask me what they should do if they wanted to switch careers into the world of computing. While I am not a career guidance expert, and I am surely not going to be pretend to be one, I feel like it may be useful to call out (even if at a high level) for a typical set of roles in a small Software Company so it helps anyone who is looking to make that switch. I want to stress on small because that’s where I’ve spent a lot of my recent years, and I am not certain I am exactly sure how the division of labor works in a large organization. Take what I mention here with a grain of salt, but I hope it helps you understand a little bit about how things work. Remember that there are bound to be a lot of gray areas where roles and responsibilities spill over but so long as you’ve learned at least one more thing, this article would’ve been worth your time, in my opinion.
I am going to list the roles in an atypical order simply because it is easiest for me to think that way (given our development process). So, don’t look at these as the right order.
UI Developer
This person is generally responsible for implementing the User Interface, and while they will work closely with the other members of the development team, they will try to stay focused on ensuring that the look and feel of pages in your application conform with the specification, and that the pages support the necessary actions so the end user can interact with your product.
Take the page below, for instance. This is one of the many pages that our platform comprises, and is the Dashboard. The UI Developer would be responsible for implementing all aspects of this page.
API Developer
In the above screenshot, you see some data. There is 1 Pod Due, 0 Tasks Due, the pod due is called Team Members, there are a number of Recently Modified Pods, etc. Now, all of this data has to be coming from somewhere, and that somewhere is the API layer (as you can imagine, Software Architecture can get as complex and distributed as you wish but in the interest of not overwhelming someone who is new to this world, I am going to trivialize a lot of this stuff).
The API developer is primarily concerned about storing user’s data (along with metadata) in a persistence layer (typically, a database), and returning that data to the client. The UI Developer is agnostic to where this data is stored, how it is retrieved and so on and so forth, much like the API developer is agnostic to whether the returned data is rendered in a grid, or a tree component.
They would likely return a JSON response that looks something like this -
{
"dashboard": {
"podsDue": "1",
"tasksDue": "0",
"recentlyModifiedBlocks": [
{
"name": "Implement Unsplash"
},
{
"name": "Dashboard Improvements"
}
]
}
}There are other formats they could choose to return this response in, say XML, but that’s rather unlikely. Regardless, just so you know the difference, here is what the XML representation of this content might look like -
<?xml version="1.0" encoding="UTF-8"?>
<root>
<dashboard>
<podsDue>1</podsDue>
<recentlyModifiedBlocks>
<element>
<name>Implement Unsplash</name>
</element>
<element>
<name>Dashboard Improvements</name>
</element>
</recentlyModifiedBlocks>
<tasksDue>0</tasksDue>
</dashboard>
</root>They would implement what’s called an API, and that could be implemented in a variety of ways as well, but if they used a RESTful interface, it could look as simple as this:
https://api.snowpal.com/dashboardNow, if you wrote a new API today, I suggest you go with GraphQL but that discussion is for another day :)
The UI and API Developer will exchange a contract so each of them knows what the other person’s expectation is. This is called a Specification.
UX Designer
We now know that a UI Developer will implement the User Interface but what they would implement is driven by what a UX Designer gives them. Think of a UI Developer’s role as one that is made up of 2 parts:
Implement the page from a cosmetic standpoint
Implement the page from a functional standpoint
The UX Designer provides the requirements so the UI Developer can take care of #1 above. And how do they do it? They have many options as well but what they will likely end up giving the UI Developer are Wireframes or Mockups.
Think of a Wireframe as something that is drawn digitally (doesn’t have to be digitally created to begin with, as sometimes, it is quick and efficient to hand draw it and then, share a photo of it) and represents the look and feel of the page.
A Mockup, on the other hand, goes a step further and shows how the page might literally look, along with navigation as well (so the UI Developer knows what should happen when the user clicks a button on the page, or hits a link).
As to how detailed the artifact should be, regardless of which of the above 2 it ends up being, that’s entirely left to the designer, and/or the organization. It can range from giving the UI developer an idea to defining it to a tee.
Or, it could be like the image below that, believe it or not, was one of our “wireframes” and in such cases, it is much like telling the UI developer to Go, figure!
But, ultimately, what matters is that the end result is what your Product Manager has in mind — something like this!
And that’s not a good segue to discuss the next role — Product Manager.
Product Manager
This is the person who determines what is it that your product should even be doing to begin with, but more specifically (and for an existing offering), they determine what that next page your team builds should be, and what problems it should aim to address, and how competitive it might be.
If you are building an internal product for a mid-sized or large company, this person will work with your Business team to identify gaps, requirements and the whole nine yards, and put together artifacts that dictate the next set of things your team should work on.
If you are building an external product, their job would entail doing market research, competitive analyses and more to come up with that next list of things to do. I know a lot of people who were developers at one point, and then moved on to do Product Management work. This is a very exciting role as well! After all, in this role, you get to make the call on what gets done, and when it gets done. So, it ought to be exciting.
Requirements
In a smaller organization, the Product Manager ends up playing this role as well but in larger organizations, this person is responsible to define the requirements at a Business level. They will then hand it over to the Product Manager who will translate these requirements in plain English to a more technical document (aka, specification) that your developers would understand, and can work off of.
Architect
An application is made up of several pages (Dashboard being just one of the many pages), and many APIs, and multiple tiers, and numerous integration with both internal & 3rd party systems and services. And a number of applications will collectively work together to make your ecosystem. Now, how they do all interact amongst and within each other?
It is up to the Architect to answer that question. There are a number of Architecture related roles, some of which are:
Application Architect
Systems Architect
Network Architect
Database Architect
Integration Architect
Security Architect
Platform Architect
and the list goes on…
For a smaller shop, it is usually the same individual (or same group of individuals) who handle all these areas. As to what separates these roles, I think it is beyond the scope of this article, so I’ll try to cover that in a follow-up article (at some point) but it should suffice to know that this person has a complex set of responsibilities.
While you could be an architect who’s hands off, I have never done that role so I can’t speak to it. I’ve architected a number of applications (across all tiers and stacks) over the years and I’ve contributed quite a bit to each of their code bases, and it is my (strong) personal opinion that this role should be hands on at all times (but I am sure not everyone might agree).
CTO
Once again, in a smaller organization, the architect would play this role, alongside doing development as well (hint: Snowpal!) but in a company that can afford this role, this person would oversee all the engineering teams, work with Architects and Developers in all teams, and ensure that the product(s) owned by the company are sound from an engineering standpoint, needed from a market standpoint, jazzy from a coolness standpoint, secure from a security standpoint, extensible from an architectural standpoint, stable & performant from a credibility standpoint, and more!
Tester
Sure, you have a nice product but before you release it to the larger world out there, someone (someone other than your development team, for sure!) needs to bless it so it does what it is supposed to. This responsibility lies with the Tester. They test your product in more than 1 way to make sure it works, and it works consistently.
They can do this in one of many ways:
Test it manually every single time (unlikely for many reasons, but a possibility)
Write test/automation scripts to test the various tiers in your application(s)
Write unit tests (though developers would do this), functional tests, integration tests, performance tests, end to end tests and so on and so forth.
Their job is to break your application so your development team can fix it, and make sure it is all good to go before your end user encounters a problem. This is a another important role because if you find a bug in development and fix it, it will cost you (both in terms of money and time) a whole lot lesser than if the same bug were to be reported in production.
DevOps Engineer
You have a great product, and a wonderful team but it isn’t complete (not by a stretch) till you have a DevOps Engineer who can ensure that your changes make their way (aka, deployed) to the various environments continually. This area has grown in recent years and while your developers might play this role in a smaller shop, as your company grows, you will need dedicated engineers to handle all the Docker, & Kubernetes stuff.
Your API Developers might be a tad more eager to pick up these tasks as they blend quite well with the tiers they work on.
CEO
In a small company, there is only C* role but, of course, in larger companies, you will need a CEO, a CFO, a CIO, a COO, and more…
I can’t write more in this section because I would merely be speculating :)
Creative Team
At Snowpal, we don’t yet have a Creative Team, but that will be one of the first areas we will expand on as we grow. This team will create our Campaigns for Facebook, LinkedIn, Pinterest, Apple and more. Right now, we take turns to do this, and it is certainly not easy (and definitely not if you don’t have the part of the brain that contributes to this — I surely don’t).
I am sure this team is part of the larger Advertising Teams, but I honestly don’t know more about the roles and responsibilities of this team in larger organizations.
Project (or Development) Manager
You need someone to make sure all your teams understand their asks, their dependencies, deadlines and so on. This is the Project or Development Manager’s role. They will organize daily stand ups, identify blockers, create and manage Sprints, and work with all the stakeholders to make sure your ship is sailing smoothly.
They may play the role of a Scrum Master as well, but some organizations separate these roles. In our case, and in smaller organizations, the Architect handles this responsibility.
HR, Legal, Sales, Marketing, etc.
I have an idea about the roles and responsibilities of the other teams but not enough to write about them (or answer follow-up questions) so I am going to leave them be!
That’s basically it. Hopefully, you’ve learned at least one thing that you didn’t already know from this article.
Snowpal Products
Backends as Services on AWS Marketplace
Mobile Apps on App Store and Play Store
Web App
Education Platform for Learners and Course Creators