What happens when you don't define your project roles properly

Our project structure used to be pretty simple. Tech leads usually wore many hats, depending on how many responsibilities they decided to take on their shoulders. They used to play a role of a software engineer, architect, project manager, product owner, and mentor for their teammates. Sometimes they even took the burden of account management and handled everything from what the project should look like to how to set up payments with clients. All at once.

And guess what happened?

Important issues on the project have been handled on the basis of urgency, which means some areas have been overlooked. The team doesn’t know who is responsible for what.

There is no doubt that this approach was not wise and sustainable over time. It was time to change it and give it a better more meaningful structure. As a first step, we identified the typical project roles that needed to be covered.

Project Responsibilities split before the change

• Account management - nurturing the relationship with clients takes a lot of time and usually, the tech lead covers this role, including communication with the client, issuing invoices, transforming the client's ideas into tasks for engineering

• Product ownership was missing almost completely and usually tech lead covered it.

• Agile dev. processes were not aligned across the projects, as every tech lead did it in his/her own way. This complicated the transfer of engineers from one project to another if needed.

• Technology governance was and still is the main responsibility of the tech lead. Designing a technical solution and architecture, selecting appropriate technologies, and ensuring code quality.

• People Management - in order to ensure the growth and development of every team member, it is vital for everyone to have his/her manager, with whom he/she can have regular 1:1s to discuss work and non-work-related issues.

But the question remained, who should be responsible for what?

Main motivations and goals

Before we outlined the changes, we summarized our main motivations and goals for why we wanted to undergo this process.

1. Clearer project roles and their responsibilities

To avoid chaos and misunderstanding between different project roles, it is crucial to clearly define the responsibilities.

• clear ownership and areas of responsibilities

• clear expectations on abilities and skills for aspiring tech. leads and other project roles

• one standard for managing projects, so when somebody transfers from one project to another, he/she doesn't have to adapt to completely different processes

• easier onboarding of new people on the projects

2. Product Lab & Engineering Lab collaboration

In 2021 we transformed into an end-to-end product building company. Product Lab emerged inside Sudolabs to cover the product discovery phase as well as whole product management for our clients. It's important to know the difference between these two labs.

• clear responsibilities of Product Lab

• clear responsibilities of Engineering Lab

3. Clear structure of managers and their responsibilities

As we deeply care about career and personal growth, we consider it important that everybody knows who is his/her manager and what he/she needs to do in order to progress further.

• everybody knows who is his/her manager

• everybody has a manager to openly discuss any work-related topic

• everybody has a manager who is giving and receiving feedback

• everybody has a manager to consult for career development

• everybody knows who is responsible for their promotion

• have a group of people responsible for knowledge sharing between teams and the outside world

• have a group of people responsible for hiring

4. Ensure a long-term systematic approach to company growth

• be prepared for scaling and growth

• have a future-proof solution

• ensure consistency in new projects

Job position vs. project role - what's the difference?

Knowing how to grow within the company requires clear career pathways. These ensure that everyone knows what their options are and how they should proceed.

Although this view differs from what is needed for the project, it is crucial that the project has clearly defined roles, which may change from project to project and can be taken by people with multiple different job positions.

As many companies do, we started to distinguish two terms - Job Position and Project Role.

→ Job Position defines skills, seniority, background, and career ambitions. We have defined a career path for every job position in the engineering lab.

→ Project Role is what you do momentarily on the project and it can change in time and from project to project.

In the picture below, you can see defined Project roles and recommended job positions for every project role. Although each project role has several recommended job positions suitable for the role, each project must clearly outline who is responsible for what at the beginning.

Example: You can be a product owner (project role) on the project and your job title is product manager, but also you can be an SW engineer (job position) and you can take on the role of product owner (project role) somewhere on the other project. Each Project Role has its own responsibilities and activities, and one person can hold several project roles depending on the project complexity and client. For example, if it's a small project, less complex, then Senior Engineer (job position) can take these project roles at once - scrum master and tech lead.

This structure helped us fix some major issues we faced before. Currently, every team member has a long-term manager, and every role on the project has clear ownership and responsibilities.

We may change it again at some point, as we always strive to improve our processes and frameworks to secure the finest possible environment for our team members. 

We're working on the next article where we will cover each role separately and its responsibilities and what we did differently from most companies. So follow us, to learn more about how we function. 

The article is part of a series that takes a look behind the scenes at Sudolabs. Our goal is to give you a better understanding of our structure, how we work, but also how we approach things. We will be coming up with various topics about how Sudolabs work gradually, so follow us.