Team Composition and Performance: for OutSystems (and beyond)
(Target audience: Managers and Development Community in general)
OutSystems projects are (in a way) similar to other software projects, when viewed from the perspective of the team’s composition: it’s competences, size, and seniority. All of these factors influence a team’s performance.
Motivation
This topic is often a subject of interest for managers and leaders, and also developers (the team’s composition). While it might seem to be a trivial one, when diving into the details it’s more complex than what appears.
A team composition is one of the drivers for successful project execution, where members contribute in certain perspectives to the team’s output, and their efficient collaborations contribute to a good delivery and adoption.
Defining an optimal team composition is not trivial, and is almost like having an equation of several variables. But we can try define approaches to help reduce this complexity.
This is what the article is about, tips with approaches that you can use to structure a team. These are not meant to be rules, but a set of guidelines.
1. Limit Up
An upper limit for the number of elements in a team, will limit the number of communication lines between people, which can increase very fast. Probably you noticed this already, in your work day, that communication channels tend to grow wild because collaboration requires a lot of interactions.
In Agile projects the teams are usually small, to allow faster decisions. When we align work (from requirements analysis, to code review, performing testing, and other tasks), the size does matter: teams too big lead to an increased coordination time (and can compromise agility).
Above we see that by having more people, we add more communication channels. It exists by default (even if we would align everyone in only one channel or meeting). Because it’s not only about work, there are also other conversations which need to take place (because we are Humans… I think).
One typical example is that when projects are running late, a tendency exists to keep adding more people to solve the problem, but it just makes things worse. This is because more communication lines are needed and are time consuming. It may seem obvious that this leads to wrong results, but it’s amazing how it is still the case for many situations. The impacts are only visible later and as result the quality or quantity of deliverables decreases.
Agile methods require a tighter and flexible connection of people (business/technical). Developers need to be aware of core business concepts and implications. Most problems are caused by miscommunications, when a message is misunderstood after passing by different intermediaries.
An upper limit to the number of people in a team, might be beneficial to coordinate easier and deliver faster (or with quality).
2. Limit Down
A lower limit is also important, since it’s not ideal to have a single person in a team. There is no purpose for this, a team too small does not collaborate, and only risks a delivery of quality software. Work should be done not by one or two persons but usually a team with more people.
There are some misconceptions about this, that small teams can work faster because communication and meetings are removed (e.g. Scrum events).
Meetings (e.g. of Scrum) exist to plan, review, retrospect aligning a team on it’s goals. Meeting time should not be considered waste, when done correctly a team can inspect and improve it’s processes.
Most of the time we need someone else in our team, more than one person is needed to support us with ideas, help to solve problems, or do a code review. If you are in a one-person-team doing all the work, try to get at least a peer to review your code, anti-patterns, or provide feedback on requirements!
3. Mix Competences
When starting a project, sometimes it’s hard to understand what should be the team composition, or even during projects to extend it. Knowing what roles exist and which one is important for certain project types is crucial.
Note that this article doesn’t have the purpose to explain all roles, for that I’d advise you to read the Talent Playbook of OutSystems (see bottom reference),
From my point of view, all teams’ compositions should be mixed to fulfill the different activities that are to be performed. And the way we choose between the different roles usually depends on the project complexity and criticality (not considering here project phases and capacity allocation).
In this diagram four quadrants are numbered and represent four different project contexts. The horizontal dimension is the complexity (from simple to complex), and the vertical dimension is the criticality (from non-critical to critical). Based on this, roles that are usually part of a project team are:
In diagram B) for each project context (represented by number) a certain group of roles are usually added to the team. These roles were divided into two domains: business or technical. The reason for dividing this way the roles, is to distinguish specific knowledge of business aspects and transversal knowledge to any business (technical).
Agile methodologies (as Scrum) are more process oriented, not focused on team composition (besides product owner and scrum master). And often we see organizations that impose hard structures. Priority should be a flexible model that can be adjusted to each situation and promoting (in first place) the self-organized and cross-functional teams.
Consider this a general approach (rather than a rule), to help define a team composition (and notice also that other factors might need to be considered).
4. Mind Your Business
Responsibility and accountability are bound to each project role. Having a good decision making process corresponding to each role, helps to understand what not to decide over what we shouldn’t.
Many times occurs a “phenomenon” of deciding for a solution, over a problem that belongs to others. While this undermines established relationships, it’s also a dangerous risk for the project itself.
Avoid decision making without consulting the corresponding persons (technical or business matters), they are there to defend the feasibility of the project and avoid future problems.
Sometimes we need to manage the managers, and the reasoning is simple, people with hands on software are professionals who know best how to solve problems. The role of management is to give the resources needed, and then get out of the way.
Above all, promote communications between different points of views to come up with solutions to problems.
5. Match Seniority Ratio
The ratio between senior and junior team members is usually the motive for long thread discussions, but while not everyone agrees on the number, such an aspect is acknowledged to contribute to either a failure or a success.
It’s common to see projects that do not have enough seniors, where a ratio of 3 juniors per 1 senior is perhaps a cordial number to a harder reality. To be honest, two reasons impede increasing the seniority ratio in most cases: 1) budget constraints; and 2) scarce resources are hard to find.
However this might lead to problems such as: a) technical debt; b) missing requirements analysis; c) poorly designed architecture. But not only, another problem is that until the ramp-up of juniors is completed (and shortly after), about 50% of a senior person’s effort goes to them (roughly speaking), to get on track into the way of working and best practices. In such cases, the senior person either proceeds on his work focused, or helps juniors ramp-up.
In my opinion a good seniority ratio is roughly 2 seniors per 1 junior. Or when that is not possible, at least have 1 senior and 1 medior per 1 junior. Putting it even simpler, consider this pyramid of team roles seniority:
Here are represented 3 seniority layers, to help explain the concept, where a medior can also give support to juniors and seniors. The advantages are clear (or should be) by having a match of seniority ratio.
While it’s hard to say what characterizes a medior and a senior, it’s easy to say probably is more associated with experience than certifications — a senior can make certifications, but a certification does not make a senior.
Conclusions
Team composition is a broad topic and several factors contribute to different structures. Besides being applicable to OutSystems, it’s also a common subject in many professional areas.
Here are the five tips to consider:
- An upper limit to the number of team elements.
- A bottom limit also.
- A mix of competences in the team.
- A decision making process and responsibilities.
- A match of seniority between elements.
I hope this will help you to setup a team. Building a team takes time and it’s better to organize it well from the start, than leaving things to chance.
