Building teams for the future - the Deliver, Evolve, Grow framework - Part 1

Organizations that are scaling up often face this conundrum: how do we balance the needs of the client, the organization and its people?

When building teams for client projects, having experienced team members for long periods of time helps retain context, ensures delivery excellence and a happy client. However, it will not offer growth for team members nor is it sustainable for the organization. On the other hand, moving people to new opportunities may result in a team that constantly experiences churn, affecting customer experience.

This two part series discusses a tried and tested solution that can help achieve an optimal balance.

We recommend the Deliver, Evolve, Grow (DEG) framework designed to ensure that teams are built to cater to the needs of all three stakeholders — client, organization and people, in a sustainable way. We focus on identifying and growing the right set of capabilities that equip teams for project-level success as well as for long term bigger impact. 

While this framework can be used irrespective of the stage the project is in, it works well for teams that have been working together for 3-6 months and have a basic understanding of the project goals, and what is required to deliver them.

But, before you make any changes to your team, assess your capabilities thoroughly.

Prepare: building a capability map for your teams

Identify the right set of capabilities

The capability map for a team typically covers the technical or functional skills required by each person on the team to perform their responsibilities effectively. Such teams operate as a collection of individuals with matching skill sets. Every team also has additional attributes required to address the client’s and the team’s needs beyond role-based asks. The shift from role-based to goals-based attribute identification is key for delivery excellence.

Here’s a sample set of capability parameters for a team:

• Core tech knowledge

  • Tech stack (Android)

  • Domain knowledge (retail, financial services etc.)

  • Specific models of working (Agile, SAFe, OKR etc.)

     

• Championing practices

  • Team practices (regular feedback)

  • Development practices (test-driven development, pairing etc.)

• Experience of working in different team models (distributed, co-sourced teams etc.)

• Relationship building/Influence (consulting skills, negotiation etc.)

• Team building (cultivator, innovator etc. — Belbin’s model of team roles can help identify similar capabilities)

   

Key considerations in identifying capability parameters

• Client needs (what is the success criteria for this project?)

• Team needs (what does this team need to meet the client’s objectives?)

• Past experiences (what have we learnt in similar projects?)

   

To ensure the right level of detail, focus on parameters that are not bound to change too often during the delivery. For instance, dependency management as a theme could be a capability parameter, but not all project dependencies may qualify. New parameters may emerge. And when that happens, revise the capability map to ensure alignment with the end goals.

Some parameters (for example, consulting) will be abstract enough to be considered integral to every team. This may lead to a laundry list of capabilities. In such cases, break down the parameters and clarify why it is essential for the client. Consider trade-offs based on current needs, timeline, budget and other constraints.

Map the current state of capabilities

Conduct self, peer and leadership reviews for each team member. This can also act as a litmus test on whether the team understands the overall goal of the project and why each of these identified parameters is essential to achieve the same goal. The capability map is most beneficial when it is used to drive conversations on an individual’s growth.

Here’s a sample of what a capability map could look like:

✔- identifies people who have demonstrated the capability in the current context

? - identifies people who have the capability but are yet to demonstrate it in this team

null - indicates that the capability is not applicable for the individual in their current role (or) is required and needs to be built 

Here’s a real-world example of a full-fledged capability map for an account running two streams of work:

There could be capabilities that an individual has, which may not be required for the current engagement, but could have high value in another project. Building capability maps at an organizational level helps leverage such capabilities and match people to the right opportunity.

Categorize the strengths and gaps in the map to identify actions

The capability map of teams provides an overview of the current state of the team and the gaps that exist. The Deliver, Evolve, Grow framework provides a pathway to fill these gaps and grow capabilities by categorizing them into three dimensions.

1. Capabilities not present, they cannot/need not be internally grown

2. Capabilities present, but not demonstrated in the current context

3. Capabilities present, demonstrated and can be spread/grown internally

    

The second part in this series discusses the action you can take to address each of the dimensions, discussed above.