While scaling, Businesses and Startups face many difficulties in keeping business as usual and the increasing growth of demand in application improvements and new features. Usually, it is addressed with scaling of capacity. At a first glance, larger teams are much faster, however, there is always a burden of coordinating efforts. In this article you will discover the efficient practices presented by Altamira expert – Alexandra Rostovtseva, telling how to successfully scale your team while maintaining your efficiency.
Keeping the circle of recruitment – off-boarding during the team scaling
Due to the high demand on software engineers, the lack of those at the nearshore and offshore market, and rising cost of the software development, a lot of companies start to re-evaluate the efficiency of the talents they already have and re-assess the way they approach the team scaling.
The problem becomes so huge that even Google development team, one of the top tech companies is cutting their in-house software development teams, and despite this, the efficiency and speed of production remains at the same level. The paradox is that the software developers and other experts, being part of the software team development infrastructure, agree with the statement that we need to switch from the approach of scaling through the increase of capacity to the approach of more vertical or efficient scaling. In Altamira, we get a lot of requests to add XX number of engineers to the team starting from tomorrow because the Scaling Business is so in a hurry to finally fix the release schedule, get the product to market or even to make a stable bug-free release, that the only way to do this they see in ASAP team scaling.
The irony is that it leads to exactly the opposite result, Team Leads and existing team get overloaded even more, slowing the process down, new software engineers are not onboarded properly, which leads to low retention rates and necessity to again onboard more and more people, keeping the circle of recruitment to off-boarding. The working capital is burnt, and the product releases still do not reach their end users, which causes the business stalling.
Finding WHY and HOW
In order to find the solutions, in Altamira we have worked out the framework that allows to answer two questions that should help to build the plan of exiting the business stalling and to get to the “smart” scaling of the pods, squads and software teams.
The questions are:
1. Why this happens?
2. How big the existing problem is?
Then you can form the reliable plan on what to do next and how to move forward. In Altamira we do the discovery of these two items by having the so called “TSPP (Tech, Scope, People, Processes) Workshop” that helps to form the recovery plan. Below we are sharing some of our exclusive materials as well as our experience and the best practices in finding the way out of the circle of overload, growing overhead, and lack of product development progress.
TSPP Workshop: Discussing the critical points
The workshop itself consists of several meetings or, as we call them, sessions. Each of the session needs to be driven by a facilitator. It is aimed to bring a deeper understanding of the current situation inside the team, core processes and responsibilities, identification of critical points and processes to focus on and improve.
Who can be a facilitator during the team scaling workshop?
We recommend picking an assertive person non-involved in the actual development process of the team but that is aware of the development cycle to a sufficient level to understand the conversation, keep it active and point out the missed points for conversation. By having someone non-involved in actual software development process or project that is discussed allows to keep the neutral “cold” head in moderating the hot topic.
Who are the participants of the workshop?
Very often tech leaders, management and executives think they know what the problem is, missing the whole hidden gold of the knowledge that actual teams hold. So for the sake of this workshop, it is recommended to have actual product development teams working on the project be the main core of participants in the workshop.
Other stakeholders such as marketing, product teams, and business executives can also be invited at least for the first session to identify their goals and align with the development team.
For bigger team organization the framework can be scaled, where there are the workshops at the level of the development teams, development squads or development pods, and then the representative of each team (Team Lead or Project Managers, Engineering Managers, Human Resources Officers, etc.) takes part in the common workshop that accumulates all the outcomes gathered within the previous workshops.
However, the team composition should at least include stakeholders that cover the areas, based on which the full workshop is built, which are:
- Business goals representative
Apart from the existing team, we in Altamira, being the usual software development partner to our customers, take part with stakeholder representative mirroring the roles of the in-house team and adding “missing” roles. This allows to get 360 view on all aspects of the project, enables to boost productivity, distribute core tasks and ensure efficient business strategy.
Ensure quick and efficient scaling with Altamira team! Leave the request and get a free consultation to get more info
Ensure quick and efficient scaling with Altamira team!
Leave the request and get a free consultation to get more info
Session #1 – Where our ship needs to sail?
The team that is supposed to meet the goals that you put for it should not just understand what it’s doing but also be aligned in the approaches, methods it uses.
Our best customer relationships were built when we were able to align the values that a client’s team sticks to and those that we propagate. And this goes from company mission, vision, values, and strategy and down to short-term, middle-term and long-term goals.
In order to build the right culture in the software teams where each member is kept interested and involved, it is necessary to bring the missions and values from the paper into the actual work routine of software developers. Communicating this down to the software development team and teaching the managers to apply those during the regular day-to-day work would allow you to gain:
- The more involved software development team
- Culturally aligned team
- The collaborative distributed team, in-house team or dedicated team
- Team working towards the company goals with their understanding and realization.
- Better retention team rates, since when a team feels they are contributing to one mutual goal they are more willing to stay in such environment. And this is especially important in the growing race of demand for software developers.
The purpose of this session is to remind what exactly we are trying to reach aka what our “Mission, Vision, Goals” are as well as what methods we are ready to use to reach them aka “Values”. This allows bringing all distributed teams or dedicated teams to the same cultural environment around the goals they need to meet. But since the context can change over the period, we want to differentiate between “Now”, “Soon” and “Later” time scale, where Mission, Visions and Values will stay the same across time, but the actual software development team goals and company goals are going to change.
You want to discuss what Now, Soon and Later actually mean. For smaller projects we recommend keeping Now as 30 days, Soon – 3 months and Later -6 months. For bigger and scaling businesses, Now as 3 months, Soon – 6 months and Later – Year, and reiterate in case of changes.
The outcome of this meeting should be a fully filled canvas concentrated around the goals and company’s mission that we have put for the outlined period of time and each scaling software team member should understand those.
If a company uses the OKRs, they can be outlined here per divided categories that are adopted in your company. E.g. Product Team Objectives, Marketing Team Objectives, etc.
Session #2 – Is our ship able to sail?
So once we know where our ship needs to sail, now we need to understand what the actual state of our ship is, which means to start talking about all the problems (the big elephant in the room) that everyone knows about but doesn’t speak about due to deadlines, urgencies, lost revenues, psychological safety etc.
This is a very sensitive session, where the facilitator plays a key role, cause needs to make sure the team focuses on naming and not blaming. Usually, the facilitator addresses to values that were aligned during the previous session and has them in front of the team.
If the development team is an external software engineering agency team, not the in–house one, this is a particularly challenging exercise. In this case you might just ask for the outcomes of this session and not participate at all, as a client, to make sure the software development agency gets transparent results. The problems that we need to outline are within the categories that we already mentioned above, which are:
Some of the bigger projects also require adding “Quality” or “Infrastructure” categories, but the smaller ones can be covered within technologies section.
This is actually very similar to a scrum Retro session but where we do retro on the current state of the project rather than a sprint. Feel free to use the canvas below to fixate the outcomes:
If the right environment is built, you get this canvas filled very quickly, since the development teams are hungry to finally tell and get the overall view of troubles they see.
You can cover several projects at the same time, this will allow to spot the systematic problems that are repetitive across program or organization.
During this session, talk to the team and make them feel comfortable talking about the challenges and problems they face. E.g. it can be “lack of time for legacy code”, “no well-established processes” at tech level, or “no backlog vision for 6m”, or “overloaded people that keep working extra hours”, or “lack of regular releases”, etc.
Canvas categories can be extended with the Executives’ goals such as “problems from sales, marketing, etc” that have direct impact on software, which can be particularly useful for the tech based scaling companies.
Session #3 – Now, Soon, Later plan to scale a team
So now we know where our ship needs to sail and we know if our ship might sink as it goes there. So, the Session #3 should help you to put the solution plan together. If you turn to some consultant company that is supposed to help with the software engineering practices, they will provide you with 100 pages long pdf file telling that you need to invest thousands of dollars into rewriting whatever you have and then maybe in 6-12m you can get to a quicker pace of releases and finally be up to speed with the market.
Eventually, this never happens or business just doesn’t have the luxury to stop development for such a long time. The aim of Session #3 is to find a compromise between the best practice, the good enough state and the actual business needs.
What can we do NOW just enough to get to to Now goals and Fix the most urgent problems? Usually, the answers would be around releasing capacity of the current development team.
Then we focus on what can be done SOON? What actions do we need to take to get closer to the “perfect” state as we see it, allow us to meet the Soon goals and not have our ship sink.
And the same with the Later.
By having the canvas from Session 2 in front of your eyes, fill in the solutions that your software development team suggests. At this stage do not let the scaling software teams argue much, healthy discussion is acceptable though, write down everything they come up with using the next canvas.
When you have the possible solutions filled in, you need to validate them across the Goals, Mission, Vision and Values.
This should help to align on which problems it makes sense to concentrate now and which problems can wait till later or soon stage. So, on each of the problems within sections you need to answer the set of questions:
Does this suggested solution contribute to mission or vision completion? Or this solution contradicts those?
The answer to this question should help you to decrease the number of suggested solutions on the canvas, leaving the ones that really contribute the overall business goal. Cross out those solutions that are not contributing or breaking the company mission, vision, goals.
Is the suggested solution within our values? Does it break any of our values?
This should allow you to remove those suggested options that break the culture you want to build within the team and decrease the number of options even more. As you keep doing this workshop in your organization, the number of suggested solutions that break the values will get decreased with time because software teams will learn not to even suggest such, building the right culture.
Does this problem/challenge keep us from reaching our NOW goals? Does this problem/challenge keep us from reaching our SOON goals? Does this problem/challenge keep us from reaching our LATER goals?
The answers to these questions should allow you to play with the solutions and revise their arrangement within Now, Soon, Later columns by properly prioritising those across these three-time spans. You can shift solutions that resolve the later goals, to the later column, releasing the time of the scaling software teams to concentrate on more urgent Now things.
The outcome you are looking for is the clear Now, Soon, Later plan, which is a compromise between what scaling software teams feel should be done from a tech perspective for a ship not to sink and what business needs so that ship can keep sailing and reaching that goals. This plan is later put into the action plan and is tracked across the timeline.
This framework allows concentrating on fixing the problems and meeting the most immediate team growth goals, instead of procrastinating on the huge scope of problems & goals that different teams put in front of you, and which are often contradictory and confusing. It also allows releasing some of the team capacity from doing things that are not urgent right now but are assigned as a result of misalignment or wrong priorities.
In the end you will notice that you do not need to add more developers to meet the “Now” goals, but you would probably need them for Soon or Later stage, and by that time you will be able to set everything you need to have them successful in their jobs, like:
- the right knowledge base,
- established communication channels,
- onboarding plans,
- clear scope to work on,
- Tech Leads and project management specialists that are happy they get to work with new team members instead of feeling the burden, etc.
Altamira has successfully applied this framework on a number of projects. It works well with highly disciplined web and mobile development teams or with fast-scaling startup teams that are at their 4th or 5th round of investment, pressed by KPIs and thus concentrated on fast results.
At the same time this framework is challenging with the Enterprise level clients, where cultural shift is required, and communication alignment is usually a challenge. However, if you have the buy-in from the Business Executives, especially those that just came into the teams management and struggle in assessing and coordinating the current state of technology themselves, the framework is a big help.
This effort not only brings you to the actual alignment of the general vision of the state of your project, but also gives the environment in which scaling development team can talk free about the problems they experience during the work on software development, engages them into the product and as result teams become more collaborative, involved, which eventually leads to higher retention rates.
Easy and most importantly in-time recruitment of team members, the release of capacity of current teams, and higher retention rates, allow efficient smart scaling with lower expenses rates versus the horizontal increase of capacities by throwing more talents to deal with the same problems.