How we structure teams and why

In this article, we will first walk you through what it looked like in the past and talk about the changes that we introduced before the company fulfilled (and even exceeded) its yearly goal of 100% growth in team size. After that, we’ll share what the organizational structure looks like today and how we addressed the various challenges.

Recognizing the need for change

In the first year of Sudolabs’ existence, the team wasn’t bigger than a dozen people, most (if not all) of whom were software engineers. The team was working on just a couple of projects and, collectively, we were expected to provide successful software delivery of our client’s products. Tech leads on the projects back then wore many hats throughout the day and they were responsible for many aspects of the project - ranging from technical ones, such as architectural decisions and code reviews, to product ownership and project management (which wasn’t standardized at this point), and even account and people management in some cases.

It is important that all of the above-mentioned responsibilities are covered to ensure a smooth and successful execution of a project and we were doing our best to do so in that setup. However, having one person in charge of all of these inevitably led to approaching them based on urgency - since there was a lot of ground to cover, there wasn’t enough space to dedicate the proper amount of time to all of it. Most of the time, the team was focused on shipping the product, and all the other important activities were pushed back and executed in worse quality, or not at all.

This approach is sustainable only up to a certain team size, where leadership can jump in and out of projects. When we outgrew that, we knew it was time to change our approach, and so we started to divide the responsibilities among other team members.

The first thing we did was hire and onboard a project manager to help with managing backlogs on some of our projects. After that, we started working closely with the tech lead on our biggest project and focused on improving agile methods and processes on the project. We began seeing some results almost right away.

These few specific changes improved the overall situation on our projects, but it was obvious that we needed the ownership of the responsibilities to be crystal clear and since the situation was different for every project we’ve been working on, we decided to sit down and re-think the organizational structure from the ground up and come up with a framework that will be capable of supporting us as we scale.

Current organization structure in Sudolabs

One of the discerning factors in our current organizational structure (versus what it used to be like in the past) is that it separates job positions from project roles.

Job position is based on the selected career path and functional orientation of a team member. At the moment, there are 3 main tracks in Sudolabs - Engineering, Product Management, and Design. The engineering track is split into Managerial and Individual Contributor tracks. Position describes the seniority and experience level of the candidate and also determines their salary, reporting lines, and skills expectations. It is project-independent.

Project role describes responsibilities and activities on an assigned project for a team member - generally, a project needs:

• Delivery Lead

• Product Manager

• Tech Lead

• Sales Owner

• Product Designer

• and a team of Software Engineers.

It is not uncommon for the client or their internal team to assume one or more of these roles. For instance, in early-stage startups, the CEO might often function as the Product Manager. Additionally, there are scenarios where a designer or even the client's technical team is already engaged, with whom we then collaborate closely.

Transformation into a product-building company

As we mentioned before, we were aiming to have clearly defined areas of responsibilities for our project roles. We also needed to have one standard of managing projects, which would result in simplifying the onboarding process, since everybody knows what to expect from the roles on the project and who to reach out to with a specific question. The main motivation behind these changes was to provide a great experience for our clients by ensuring a smooth delivery.

The transformation of Sudolabs into a product-building company (the inception of the Product Lab) was also a big part of the reason for revisiting the organization structure as a whole. Before this change, the structure was all about streamlining the software delivery. Product management was mainly about collecting the requirements from the client before the work started and then communicating the results of the engineering effort back to the client.

The product management we are doing now involves collaborative definition and validation with our clients, positioning our product managers as strategic partners. Doing product management properly this way requires a distinct skill set, differing from that of a tech lead, and a more substantial time allocation.

At the same time, our objective is to allow the tech leads to focus on the technical aspects of the product, while the product manager manages the product scope, represents the voice of end users, and ensures that the whole project goes smoothly and toward the initially set goals. Also, the majority of client communication rests with the product managers, but mainly, they serve as the primary advocates for the end users of the product. Furthermore, product managers possess extensive product knowledge, acting as the bridge between the client and the delivery team.

Having all project role descriptions documented and responsibilities split was also important for our aspiring tech leads as it would provide them with clear expectations of what would await them if they decide to go down this road.

We also devised a structured framework centered around career development. This resulted in the introduction of (people) managerial roles. As we scale, these roles ensure that each team member has a direct manager who:

• has regular 1:1 meetings with them

• provides regular feedback for them

• they can give feedback, and ask any work-related questions that are not related to a project

• helps them with their career development

Our managers are also responsible for their report’s promotions and salary increases, oversee the hiring process, and help with knowledge sharing between the teams and the outside world.

They also play a pivotal role in our projects, leveraging their expertise to enhance the operations of our engineering and product teams. They streamline communication with clients and within the team, refine workflows and organizational processes, and help with work organization.

From humble beginnings to strategic roles

Adaptability and clarity in responsibilities were among the most important considerations in Sudolabs' journey to achieve its current organizational maturity. From our humble beginnings with a predominantly engineering-focused team to our present-day structure that differentiates job positions from project roles, this evolution has been marked by introspection, proactive change, and a lot of learning.

As we carved out paths for better product management, focused tech leadership, and managerial roles, the intent remained the same: fostering an environment that ensured clear responsibilities and streamlined project execution.

While this article provides an insight into our structure and the motivations behind creating it, many other layers remain to be explored and we’re looking forward to sharing them with you in future articles.