Examples of Infobip Teams

There's a no one size fits all answer to how life looks in an Infobip team. They can be affected by multiple factors, from the scale of a product, the number of teams within their Requirement Area to the type of their end customer (internal or external). But here are a couple of examples of "average" teams from 4 of our Requirement Areas:

Internal clients

Requirement Area #1 works with internal clients, which means they mostly build stuff for other developers. Since they're developing the core "framework" for the rest of the Infobip‘s platform, the dependencies they have are connected to other Infrastructure RAs. These are the engineers they know really well and collaborate most with during their sprints. They are often contacted to answer questions about infrastructure or implement features that help solve other developer's problems. Part of their job is to educate other engineers on how to use internally developed tools or to advise on which approach to take to solve a task.

As a part of this team, you would come into contact with about 10 different components, and the the number would grow the longer they're in Infobip. Some of this contact would be through direct work/development of a component, some would be through troubleshooting. You aren't bombed with 10 different things when you join this team. As you become comfortable working on one component you can progress to another either because it's important to cover it or because you have a personal interest in learning this.

As you might have figured out, these engineers like to work on challenging projects. When it comes to the structure of these teams, they have on average about 5 people per team, mostly mid and senior level devs with a ratio of 50:50. Since they work on a lot of different components they come into contact with a larger number of different technologies, so they like to learn and innovate through practical work.

SaaS team

Requirement Area #2 works within the SaaS area, so they're completely external facing when it comes to clients. The teams within this RA work together a lot, so in an average sprint they collaborate with 1 to 2 other teams from their own RA. This doesn't mean they don't have contact with the rest of Engineering at all, on average they work with 2-3 other Requirement Areas they directly depend on, like for instance the Data RA.

They divide their technology stack to: Backend, Frontend and (sometimes) Databases. The Backend/Frontend ratio would be around 70:30.

Currently everybody is working on one big service, but considering how fast the project is growing it'll split into multiple services in the very near future. Ideally each team would have 2-3 services they would work on continuously, which would bring more focus and free up extra time for education and innovation. Average team structure? About 5 people, junior to senior ratio equals 1:8

SaaS team dependent on core services

Requirement Area #3 also works within the SaaS products area, so these teams also have external clients. They work more closely knit, and their dependencies are geared towards Infrastructure RAs. What differentiates them from the previous example is that their main challenge is their teams are dependent on the core service of their RA. Simply put, they build the core, and everything around it, which means that everything is dependent on the core service. An average person would work with 3 to 4 different services, and each team might be more proficient in some services. This is mostly based on their delivery history. An average team size is 6 to 7, while the junior to senior ratio is different from team to team, but in average it's one senior per 3-4 mids and juniors. Their main goal? Build up senior capacity!

External telecom operators team

Requirement Area #4 works with external telecom operators and deploys their services on operator premises. This means they have different infrastructure and maintain it themselves so the whole Requirement Area is a mix of developers and system/operation specialists working closely together. Even though the service runs in the operators network it is completely managed and used by an internal team so their stakeholders are internal. This is due to the nature and business model of the product where they sell monetization with a prepaid commitment and after that it is up to internal teams to block all grey routes and fraud so the traffic is properly monetized and this generates us revenue. Since this is a really specific use case, the teams within this RA collaborate between themselves, but don't collaborate with teams outside of the RA. They have practically zero dependencies with the rest of the department.

This kind of specialization means that a single person can work with 10 to 15 different technologies, taking care of 3 to 4 different services. These numbers can be higher or lower depending on how complex a single service is. They have dedicated learning days and focus on maximizing the spread of their specific knowledge. A team has 4-5 people on average, with over 40% of people being seniors or higher. The majority of people are mid level engineers.