July 5, 2022 · 7 min read
Not long ago at APSL we celebrated our first 13 years of history, with a staff of more than 100 people. 12 years ago we were 4 people, we have been growing and learning along the way.
The growth of the company has been accompanied by more bureaucracy (Thank you administration!), random surveys from the INE where we always seem to have the right numbers, various regulations that apply from 50 people onwards (Has no one wondered why there are so many small companies and so few medium-sized ones?), etc. Upon reaching certain volumes, a mandatory audit must be passed by a certified auditing company. With the figures that we will reach this year, 2022, we will have to pass this audit in 2023.
As one surrounds oneself with people who give very good advice, we decided to pass the 2021 audit, even though it was not mandatory. For those of you who have not experienced it, I must tell you that it is a very interesting experience, at least with our auditors, from which we have learned a lot. Of course, it takes much more work than we had initially anticipated.
In the audit we explain how we work, type of clients, billing, etc. And that brings us to the object of this article, the concept of a Delivery Team made up of FTE (Full Time Equivalent). It seems to us the most normal thing in the world, but when we described it we saw that it was not so. That's why I think it's interesting to explain.
At APSL we are committed to agile methodologies, whose fundamental focus is the contribution and delivery of value to the client. Methodologies such as Scrum always assume that you have a multidisciplinary team, capable of doing everything and that it is completely autonomous. The figure of the full stack taken to its maximum expression. And that directly does not work when the team is small and the project is very specialized, with a front and back layer, a systems layer, or where there may also be a part of data science. A multidisciplinary team is needed, but it cannot be the same people who do everything. We have a problem and that is what we want to solve.
We want to reach a compromise between what an Agile project team is and development efficiency. What we do is estimate the dedication of each profile to the team and based on this we look for the profiles that best fit together with their dedication, thus forming the project team.
This also allows us to manage roles and capacity. If the front layer, for example, is not going to be involved in development for the first few months, you can keep the people who are going to be involved informed and trade the planned dedication for more back development components.
In the end, the average workload of each of the profiles will be what it should be, but we can decide the workload and involvement throughout the life of the project. An FTE is the time equivalent of having the capacity of a person, but without that person always having to be the same.
In this way we have a fixed monthly cost, management of the project budget and dedication of suitable profiles, with a team totally oriented to delivering value, which takes advantage of the best of each one.
If it's so beautiful and efficient, one might wonder why all companies don't do the same when it comes to developing. Not all companies are prepared to organize themselves in this way. It has taken us a long time to achieve this way of working and we are adapting and improving it every day, with everything we are learning in the projects. We believe that this way of working is optimal for agile projects, since following the philosophy of delivering value, it also allows us to be very efficient in what we do.
Developing a product in this way requires that a few minimums be met:
We can only have this type of management and structure if both the client company and the company that offers the service are medium to large in size, although it also fits very well in the world of startups. The client must be aware of how product and value-oriented work is done, where the requirements flow as the business changes. The team has to be able to manage itself and be fluid enough to incorporate new people as the project evolves. This assumes that there are people available to bring on board as needed, which may not be the case if the development company is small. A few years ago we ourselves would not have been able to structure ourselves in this way.
Also oriented to the size of the company, trust and customer involvement is very important. It is not about a closed project and discussing scope, it is about generating value for the business. The client knows what adds value and what does not. So the team's job is to evolve with the client, adapt to the priorities and create an architecture that is robust enough to be able to meet the client's needs. This collides head-on with fixed price and feature projects. In our case, we are also budget managers, ensuring that our work has the maximum value contribution for the client and notifying in time of possible deviations.
Working with a delivery team implies that part of the team is going to change and that in order to do so, the company cannot be at 100% of its capacity, since if it is, it could happen that the incorporation of the person or people that the team needs slow down the project instead of speeding it up.
Working in this model means that the supplier company, APSL in this case, is not going to maximize the billable time, but rather is oriented towards minimizing the waiting time and increasing the value of the deliverables.
The technological choice is fundamental. Many times we will have to say no to projects that do not fit us technologically in order to maintain the focus on the technologies in which the company has an expertise. We have opted for very few technologies and we say no to many projects that, although interesting, would imply losing focus on what we are good at.
We have focused on developments in Python, using Django for the back tasks and creation of APIs and Vue or React in the presentation layer and deploying it on the AWS cloud platform.
This focus has allowed us to process the integration and continuous deployment systems, to have an alarm system for both the application and the system, and ultimately to be more efficient at work. People know what to expect when they tackle a project, whether it's early or in development. In this way, we reduce the cognitive load, the anxiety of facing the unknown. Each project is unique, but having a common and defined technological base allows us to focus on the problem rather than the tool.
Coordination in the teams is fundamental and everyone must be aware of the abilities and strengths of each person on the team. There must be a broad base of common knowledge and to achieve it, a training and apprenticeship stage must first be passed. This is what we are also doing at APSL Academia, where in addition to the technological part we also focus on processes and methodology, on achieving this common base we are able start working in a team without friction.
A team with these characteristics requires being completely transparent with the client. In other words, when a more specialized profile is needed, the team itself is in charge of making the arrangements to have this additional support.
In addition, our client must always be informed of the tasks that we are carrying out, of the capacity that they are reserving and using at all times, so that they can also make their own decisions regarding the efficiency of the team.
It is a job that must be done as part of the day to day management and this provides the means to have visibility of what is being done, and to be able to have a history of the complexity of tasks and thus be able to estimate better and better.
If you have come this far, you will surely wonder if this type of team fits your project. It must be evaluated case by case, it depends a lot on whether the company is prepared to work focused on value and not on budget.
The flexibility provided by having a liquid team, with profiles that can change throughout the life of the project, but which maintain knowledge of what is being done and good practices, compensates for the extra effort of management and coordination between supplier and client. . The supplier becomes a partner, a partner of the client, adding value through experience and knowledge. It does not fit when you are only looking to expand the team with a certain profile, it does not fit with the body shopping modality.
Each company is a world, at APSL we believe that this type of work is the most appropriate to minimize the risk inherent in any project and ensure that the client has what he needs, which sometimes is not the same as what was thought at the beginning of the project.
Are you interested in knowing more? Let's talk!
Return to the APSL blog
