---
title: "How to build a growth plan for a small team"
source: "https://www.matteovincenti.com/en/blog/how-to-build-a-growth-plan-for-a-small-team"
language: en
author: "Matteo Vincenti"
published: 2026-10-28
category: "Team management"
tags: ["Team management", "Evaluation"]
---

# How to build a growth plan for a small team

Build a shared growth plan with six-month expectations, feedback and a 50-point framework. Examples, calculations and limits for a small software team.

![An open green binder shows five abstract indicators, with two speech bubbles and a pencil beside it.](https://cdn.sanity.io/images/xrqkwry7/production/7ab11a84c2d6494c97af9ee2370bd2da341e550a-1672x941.png?w=1400&fit=max&auto=format)

Category: Team management · Tags: Team management, Evaluation

A growth plan makes explicit what someone wants to develop, which behaviours their role calls for, and what support they will receive. To make it useful, you also need shared criteria for observing progress and opportunities to discuss it before the final review.

In a small development team, context matters. People work on different tasks, have different levels of experience, and do not always have the same opportunities to demonstrate their abilities. A common framework provides direction, provided those differences remain visible.

For my fully remote team, I built a process connecting career conversations, six-month development expectations, feedback, and assessment across five areas. This article describes its structure and how to interpret it. The numerical examples are hypothetical: they explain the reasoning and calculations without sharing individual team members’ assessments.

## Develop the rules with the team

The manager’s first task is to gather information: what the company needs, which difficulties arise in the work, and what people say they need. That information provides the basis for a proposal to check for consistency and bring to the team.

This is the approach I followed. I wrote the draft process and shared it with every team member before making it official. I collected feedback, adjustments, and requests for clarification. I wanted the rules to be understood before they became the basis for assessment.

The discussion also covers consequences: what will be observed, how scores will be assigned, which development opportunities may follow, and which decisions depend on the company. Questions about these points should be addressed while the proposal can still be changed.

Each individual plan has its own discussion. I prepare it and go through it with the person in a one-to-one meeting. It becomes official for the six-month period after that discussion and approval. This step clarifies both the expectations and the work needed to support them.

For me, participation matters beyond understanding a procedure. People contribute to the company’s development through what they notice and propose. The manager needs to account for that contribution when building the process.

## Understand the person before assigning goals

A difficulty observed at work is a starting point. Turning it into a development plan also requires understanding the person’s interests, the conditions in which they work well, and the direction they want to take.

The model includes three career conversations, separate from performance assessment. This structure has a precedent in [Russ Laraway’s Career Conversations](https://www.radicalcandor.com/blog/how-to-have-career-conversations), which connect personal history, aspirations, and actions available today.

_Understand the person before assigning goals_

| Conversation | What to explore | Shared outcome |
| --- | --- | --- |
| Personal history | Experiences, motivations, strengths, and conditions that help or hinder work. | A useful account that helps the manager understand and support the person. |
| Vision and direction | Interests and desired direction: specialisation, stability, or broader responsibilities. | A map of skills and opportunities to focus on. |
| Alignment and action plan | The connection between aspirations, team needs, and practical opportunities. | An adaptable plan with goals, learning opportunities, and mutual support. |

The document schedules these conversations during onboarding, annually, and when someone changes roles or reaches a different career stage. Their value depends on what follows: the information gathered needs to influence expectations and the opportunities offered.

Growth can mean becoming more independent, developing a specialisation, or consolidating a reliable contribution. The process does not require everyone to become a manager or continually expand their responsibilities.

## Turn that direction into one or two six-month expectations

The annual plan establishes a direction; the six-month period provides a focus for the work. In my model, each person has one or two active development expectations, discussed and agreed together. These can continue into the next period when further consolidation is needed.

An expectation concerns a capability to develop. A concrete task can provide an opportunity to practise it: delivering a feature, for example, can help someone work on independence or on raising risks promptly.

The plan should make this connection clear:

- **Expectation:** the capability or behaviour we want to develop.
- **Value for the company:** the work-related need it addresses.
- **Value for the person:** how it contributes to their development.
- **Observable actions:** what we will be able to see in daily work.
- **Agreed support:** what the manager will do and which opportunities will be available.
- **Checkpoints:** when we will discuss progress and obstacles.

Consider a hypothetical example that we will also use for scoring: a mid-level developer needs to improve communication about their work.

“Communicate better” is too vague. A more useful expectation is to make progress, blockers, and decisions understandable in both tickets and conversations. The team benefits by being able to coordinate work and pick it up during an absence; the person gains independence in working with colleagues and non-technical stakeholders.

Observable actions might include updating a ticket when the task’s status changes, explaining the context of a blocker, and making clear during a conversation which decision or help is needed. Support could include reviewing some written updates and debriefing after difficult conversations. These are suggestions for this example, to adapt with the person.

The goal can then be discussed in concrete terms. If promised support is missing or suitable opportunities do not arise, that also needs to be part of the conversation.

## Keep the plan active throughout the six months

In my case, the practical work has mainly involved giving and receiving feedback: periodically reviewing samples of tickets, gathering observations in one-to-ones, and discussing them with people. The document’s structure helps maintain continuity.

The model distinguishes meetings and activities with different purposes:

_Keep the plan active throughout the six months_

| Activity | Purpose | Outcome |
| --- | --- | --- |
| Monthly journal | Collect a brief reflection from the person. | Learning, achievements, support needs, and difficulties to discuss. |
| Regular one-to-ones | Discuss work, feedback, and obstacles as they arise. | Clarification and support actions without waiting for the review. |
| Quarterly check | Assess progress against expectations and adjust the plan. | An interim view of progress and areas to investigate. |
| Six-month review | Consider the period as a whole. | A reasoned assessment and decisions about which expectations to complete, continue, or update. |

Before formalising the cycle, check its workload. The document allocates 45–60, 60–75, and 60 minutes respectively to the three career conversations. A complete cycle therefore requires between 2 hours 45 minutes and 3 hours 15 minutes of conversation per person. These are planned durations in the model, rather than measured times from my team. Preparation, reviewing evidence, and following through on agreed support add to that time.

The calendar must also account for journals, checkpoints, and reviews, considering what can fit into existing one-to-ones. Before extending the cycle to everyone, it is useful to try it on a limited scale: can the manager prepare for the meetings and fulfil the commitments that follow? If the workload makes that impossible, reconsider the number of expectations, the organisation of discussions, or the support available. The schedule written into the plan must represent a sustainable commitment.

The journal can start with simple questions: what have I learned, what have I done well, where do I need support, and what has frustrated me? A manager who asks for these reflections needs to return to them in conversations. The answers should influence the plan.

The quarterly check also includes a scale from 1 to 5 for progress on individual expectations: not started, minimal progress, steady progress with support, good independence, and beyond expectations. This scale answers “how is this goal progressing?”. It is separate from the five-area assessment out of 50 points. The two results must not be added together.

The principle connecting the cycle is to avoid surprises at the six-month review. Significant difficulties should be discussed when they emerge, giving the person time and support to address them.

## Gather evidence that can be discussed

A well-maintained ticket can demonstrate clear written communication. A code review can provide evidence of technical quality and collaboration. A conversation with a client can show how someone adapts their language to the audience.

Each source captures part of the work. Tasks in my team differ in nature and complexity, so counting closed tickets is insufficient for comparing contributions. [SPACE, the research on developer productivity](https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/), also describes the limitations of relying on a single metric or individual activity.

When I collect feedback from a colleague, I discuss it with the person concerned. I need to understand what happened and what context might be missing. A general observation about someone’s personality does not provide the same basis as a specific event we can examine.

A useful record can include the date and context, the observed behaviour, its effect on the work, the person’s perspective, and the agreed follow-up. This structure also applies to progress: evidence should help us recognise what is working.

Recurrence matters. An isolated event needs cautious interpretation; a difficulty that returns after being discussed raises different questions. Multiple pieces of feedback about the same event should also be connected to that event, rather than automatically counted as independent confirmations.

In remote work, this evidence comes from written channels and frequent conversations. Direct knowledge of the team helps interpret it; discussing it with the person also allows the manager’s interpretation to be checked.

## Make the assessment areas and their weights explicit

The framework I defined has five areas with different maximum scores. The total available is 50 points.

_Make the assessment areas and their weights explicit_

| Area | Maximum | What to observe |
| --- | --- | --- |
| Technical growth and awareness | 13 | Code quality and maintainability, independence, handling complexity, and learning. |
| Alignment with objectives and strategic contribution | 13 | Understanding product impact, sustainable choices, adapting to priorities, and documented decisions. |
| Culture and collaboration | 10 | Supporting colleagues, review quality, handling feedback, and shared responsibility. |
| Communication | 7 | Clarity, timeliness, and adapting language in written channels and conversations. |
| Proactivity and continuous improvement | 7 | Reasoned proposals, improvements to code and processes, and experimentation aligned with priorities. |

The maximum scores add up as follows:

**13 + 13 + 10 + 7 + 7 = 50.**

Technical work and strategic contribution together account for 26 of the 50 points, or 52% of the total. Collaboration accounts for 20%; communication and proactivity each account for 14%. These are the actual weights represented by the maximum scores.

The distribution makes an organisational choice visible: technical quality and the connection to product needs receive more weight, while a substantial part of the total concerns how someone contributes to shared work. The technical area accounts for up to 13 points; it includes code quality, independence, handling complexity, and learning.

These weights should be discussed before the framework is used. The evidence behind this process does not establish 13 as the ideal maximum for every team. Anyone adopting it needs to decide which responsibilities they want to represent and check that the distribution reflects those expectations.

The points already incorporate each area’s weight. After assigning, for example, 8 points for technical work, do not multiply them by 26% again: that would apply the weighting twice.

## Choose a score within an area

The arithmetic follows the interpretation of evidence. For each area, the model describes four conditions: below expectations, partially meeting expectations, meeting expectations, and exceeding the expectations of the role.

_Choose a score within an area_

| Observed condition | Areas worth 13 points | Area worth 10 points | Areas worth 7 points |
| --- | --- | --- | --- |
| Below expectations | 0–3 | 0–2 | 0–1 |
| Partially meeting expectations, inconsistently | 4–7 | 3–5 | 2–3 |
| Meeting the expectations of the role | 8–10 | 6–8 | 4–5 |
| Exceeding expectations | 11–13 | 9–10 | 6–7 |

Technical work and strategic contribution are worth 13 points each; collaboration is worth 10; communication and proactivity are worth 7 each. The ranges provide a shared reference and must be read alongside the behavioural descriptions.

For communication, for example, 2–3 points describe an inconsistent situation: the main information is conveyed, but clarity, timeliness, or adaptation to the audience remain partial. A score of 4–5 calls for clear communication through agreed channels, useful updates on blockers and progress, and language appropriate to the context. At 6–7, the impact extends further: the person anticipates misunderstandings and helps improve the team’s practices.

This explains why a good ticket alone is insufficient to justify the highest score in the area.

The framework contains no formula that converts every event into a point. Choosing between 8 and 9 still requires a reasoned judgment. One practical way to make that judgment open to examination is to identify the range that matches the behaviour, then explain how consistently the contribution is established within that range. If two values remain plausible, acknowledge the room for judgment instead of inventing precision that the evidence cannot support.

The person should be able to discuss both the facts and this interpretation.

## Calibrate expectations to seniority and opportunities

The same result can mean different things for a junior and a senior developer. The level defines the expected behaviours; the score describes how the person fulfilled that role during the assessment period.

For a junior developer, learning, progress, asking questions, and seeking help before getting stuck matter. At mid-level, independently managing a task and involving others when a decision needs care become central. A senior developer is also expected to anticipate problems and contribute to others’ development. For a Staff engineer or Tech Lead, the scope includes decisions that improve several people’s work and connect technical and strategic needs.

Calibration must account for actual opportunities. Requiring someone to mentor junior colleagues would make little sense if there were no junior colleagues to support. The model allows alternative contributions, such as useful documentation, knowledge sharing, or improving a technical process.

Organisational limits also need recognition. If the team lacks the capacity to sustain a practice systematically, that limitation cannot automatically be attributed to an individual.

Stability can be a positive outcome: someone can fulfil their role well and consolidate their skills without continually taking on new responsibilities. An unchanged score alone does not mean the six-month period was unsuccessful.

## A complete example: from behaviour to 30 points

Return to the hypothetical mid-level developer working on communication. Suppose the six-month period produces the following picture.

_A complete example: from behaviour to 30 points_

| Area | Score | Reasoning in this example |
| --- | --- | --- |
| Technical work | 8/13 | Delivers reliable work and manages tasks appropriate to the role. Small readability and testability refinements already discussed still recur in reviews, without substantial rework. The expected range is reached, but these aspects need consolidation. |
| Strategic contribution | 8/13 | Understands priorities and documents key decisions. For some choices, the comparison of alternatives becomes explicit only when requested. This supports the lower end of the expected range. |
| Collaboration | 6/10 | Provides support and useful review contributions. During busier periods, agreed collaboration commitments still require reminders. The expected contribution is present; consistency needs consolidation. |
| Communication | 3/7 | Tickets have become consistently clear, including through AI assistance, while recurring difficulties remain in conversations. The improvement in writing supports 3 rather than 2, within a range that still indicates partial fulfilment. |
| Proactivity | 5/7 | Regularly proposes useful improvements throughout the period and connects them to priorities without repeated prompting. This consistency supports the upper end of the expected range, without claiming impact beyond the role. |

The details and the choices within each range are illustrative. Here, the calibration criterion is how firmly the expected behaviours are established: the lower end indicates aspects that still need consistency, while the upper end indicates stronger consistency. This is a convention for the example, to discuss before adopting it, rather than an additional rule attributed to the company’s process.

For technical work, 8 therefore recognises generally appropriate quality and independence while keeping the recurrence of previously discussed refinements visible. A 9 would be plausible if, on comparable tasks, the person incorporated that guidance more consistently and those same refinements became occasional. An exceptional contribution would not yet be required: that belongs in the 11–13 range. Nor would code review comments be counted as automatic penalties.

The same reasoning supports 8 for strategic contribution and 6 for collaboration: the question is how firmly the behaviour is established within the expected range. The 5 for proactivity recognises the consistency described in the example. These reasons remain open to discussion; they do not make each score the only possible value.

The sum is:

**8 + 8 + 6 + 3 + 5 = 30 points out of 50.**

The profile says more than the total: the areas generally meet the role’s expectations, while communication remains inconsistent. The next step needs to account for that difference.

Suppose communication scored 2 in the previous comparable assessment. Moving to 3 means a one-point improvement in that area. If all other values remained unchanged, the total would move from 29 to 30.

The improvement in AI-assisted writing is recognised. Reaching 4, however, would require evidence matching the next range, which also includes communication in conversations. Using AI does not justify a penalty; the question is which part of the expectation has actually improved.

The “+1” describes the change between two assessments. It is not a reward to add to the total again. If the role or criteria have changed in the meantime, the comparison with the previous period also needs reconsideration: the numerical difference alone may lose its meaning.

## Read the overall bands without letting them decide everything

The model connects total scores to four indicative profiles:

_Read the overall bands without letting them decide everything_

| Total | Profile | Focus of the discussion |
| --- | --- | --- |
| 38–50 | Sustained growth | Examine broader contributions and development or recognition opportunities supported by evidence. |
| 25–37 | Stable contribution | Recognise reliability and identify where to consolidate or broaden the contribution. |
| 13–24 | Consolidating | Focus on consistency, independence, and the support needed. |
| 1–12 | Support needed | Agree on narrower goals, closer support, and more frequent checks. |

In the example, 30 points fall within stable contribution. That recognises the overall picture without erasing the communication difficulty.

The aggregate thresholds need a consistency check before adoption. For example, the highest scores in the “meeting expectations” ranges add up to **10 + 10 + 8 + 5 + 5 = 38**. Entering the band labelled “Sustained growth” therefore does not, by itself, demonstrate that someone has exceeded expectations in any individual area. Read the total alongside the profile and the evidence.

Another boundary needs defining: the bands shown here cover totals from 1 to 50, while the individual scales allow zero. Anyone adapting the framework must explicitly decide how to handle a total of zero and distinguish assessed performance from an area lacking evidence. These rules need agreement before use, rather than improvised decisions during the review.

This check applies to any numerical model: correct addition is necessary, but it does not guarantee that the consequences attached to the sum are coherent.

## Separate growth, training, and recognition

Assessment informs different decisions, each with its own conditions.

Training supports development. In the model, the training budget is available regardless of the six-month result: someone who needs to grow should be able to receive support even when their assessment is low. Its use is agreed in relation to individual goals and company priorities.

A bonus concerns agreed criteria and results; a salary increase also considers progress over time and financial sustainability. A move to another role requires evidence of the next level’s behaviours and responsibilities sustained over time. A high total in a single period does not settle any of these decisions on its own.

The manager must explain the proposal and clarify who makes the decision. The person needs to know what follows: what is being recognised, what support will be available, and what remains to be addressed.

My process took effect in January 2026. As I write, the first year’s compensation outcomes are still pending. I can describe the structure and the discussions that have taken place, without attributing salary or bonus results to the model before they are available.

## A plan that remains useful beyond the current company

To adapt this process to another team, I would start with expectations and real opportunities to work on them. The weights come afterwards: they need to represent a contribution that the manager and the person can describe and discuss.

A usable initial plan should connect role, expectation, observable behaviours, support, and a checkpoint. Evidence is collected throughout the period; at the review, each area’s assessment is explained and the total is read alongside the profile. The conversation also helps improve the next plan.

There is a question I often ask team members: “If you interviewed for a job tomorrow, would you get hired?”. It helps me discuss the capabilities someone could bring to another setting.

With AI helping to write code and text, I consider explaining work, collaborating, and standing by a position when needed even more important. These are professional skills to practise through daily work and discussion.

Someone might choose a different offer or a project closer to their interests. I want the development work we have done together to remain useful to them then. That is why the plan connects the benefit to the company with the benefit to the person: the skills they develop should stay with them, whatever their next job may be.