Team Growth Strategy: How to Build a Digital Transformation Capability from Scratch
Arjo van Oosten / July 6, 2017
You have defined your vision and strategy for digital acceleration and innovation. You have identified several initiatives within your digital transformation framework (e.g. legacy migration, innovation) to achieve your strategic goals, whether increasing revenue, customer engagement, or operational efficiency. You have decided to use a technology platform to enable these strategic goals. Now how do you build a team that balances delivering a quick first win with setting up your program to scale in the long run?
To avoid resource challenges after the first project, it is important to think big picture from the start. By that, I mean focus on building not just an app, but a strategic digital capability. To do that, you must define a team growth strategy from that very first project.
The important components of defining your team growth strategy:
1. Strive to enable your team to split into multiple teams
Building a team growth strategy enables you to structure a team that can take on a profile of applications. From purely a product point of view, it is possible to build an application with only one developer using a low-code development platform like Mendix.
However, if you have ambition to deliver a portfolio of mobile and web applications, your first team needs to be working in a slight overcapacity. This way, you can easily split the team after your first initiative goes live to enable multiple teams to tackle different size or types of initiatives.
Splitting your team helps accelerate results by allowing you to tackle multiple initiatives in parallel. With the proper team growth strategy, your first team and the incubation zone should prepare a seamless team split into two or more teams.
Once you split teams, two important areas need attention:
- Look at the skill level of your developers and your portfolio, and match the team to the initiative regarding size, complexity, and exposure. One team could take on small innovation projects, while the other focuses on more complex, rebuilding projects. You also could create multiple swim lanes where team A is working on legacy migration, team B is working on greenfield innovation and team C is working on components made available through an enterprise app store for other teams to reuse.
- The teams are still in learning mode, so make sure you have a multi-level meeting structure: projects (weekly), program (monthly to discuss capability creation) and strategic (quarterly to discuss strategic value creation).
2. Your first team consists of two kinds of developers
To set your organization up with a team growth strategy, your first team should preferably consist of two kinds of persona:
- Tech Tom: Tom is your traditional developer who is interested in solving technology challenges, learning new skills and likes to code. He knows the IT landscape, how to build an application, and how apps fit into the bigger picture of the organization.
- Solution Sam: Sam is a tech-savvy business analyst who can learn a low-code platform quickly and is interested in fixing business problems.
It is important to make sure your team has the right ratio of Sam vs. Tom personas, depending on the type of project each team is focused on. For innovation projects, for instance, the ratio should be 80 percent Sam and 20 percent Tom.
3. Your first team also needs a Product Owner and UX Designer
The product owner knows what needs to be built and owns the sprint content and constant prioritization of requirements. Their role is a nearly full-time job and normally each project needs its own product owner, so you need to consider this when growing your team. It is important to make sure the product owner understands the responsibility and level of commitment required for the project.
It’s important not to underestimate the importance of UX design in ensuring the success of your app. Therefore, be sure to include a UX designer from the start.
4. Create an Incubation Zone
While your first team is working on the first initiative, a second wave of team members should be lined up and getting ready to take on the next projects. This will enable the first team split to go smoothly. We call this the incubation zone.
In the incubation zone, a new set of developers is trained through the platform vendor or even partner training programs. In addition, if you are satisfied with the first Product Owner, use his “new” talent to peer coach new product owners as they come on board. Now is also the time to ramp up acceleration roles like operations, architects, and testers.
In conclusion, in order to avoid any challenges with scaling your projects in the future, it is important to create a capability, not just an app. By thinking big picture with a team growth strategy, you are focusing on solving a specific problem to your process that will help with every application you want to build in the future.