A strong team is able to meet business needs and deliver on its obligations. As we organize the team, we try to consider current business needs and perhaps look at the road map to adjust the team based on future work.
However, in today's environment, the team's responsibilities may change from month to month and even from week to week. In addition, the number of different skills required for almost any decent project is big, and definitely bigger than the number of people on our team.
Having people that are versatile in what they can and are willing to do provides us with flexibility to react to changing conditions.
Similar to chess, it is pretty much impossible to plan all the moves from start to finish. Instead, we want to play strategically in order to put ourself in good position. Having a versatile team puts us in that strategically advantageous position. Only in the end phase of the game can we look at move by move - this is similar to our tactical plans for short term execution.
Versatile team members are critical
Let's define versatile team members as people who either have a wide variety of skills and/or have the ability to acquire new skills. In addition, these people need to be happy and excited about either doing what is needed to build a product or excited about learning and developing new skills.
From a Personal Map perspective - we're looking for people with large circles for skills and desires.
So why are versatile team members critical?
When a project requires a skill that is not present in the team we need to look for that skill set either in other teams or outside the organization. Getting a contractor to do the work means delay in work, time spent on finding contractors, often lower quality and high cost for the contract work.
When the skill set is present in the organization but with a different team it means delays as different teams may have conflicting priorities and schedules. Team A may need to wait for Team B to finish what they're working before they can pick up Team A's work.
In addition, moving team from team creates queues which inherently create inefficiencies. Queues are a large topic worth discussing on its own but a few inefficiencies worth mentioning here are: communication overhead, rework on miscommunication, irrelevancy to end user by the time work is done.
Delays due to mismatch in quantity of skills
Wrong quantity of skills will also lead to delays.
Have you run into a case where some team members are working on low priority items? Have you heard the explanation that "there is nothing critical in their area at the moment"?
For example - we may have a team of two, one developer is a back-end developer building server side (back-end) functionality and the second developer is a web developer familiar with graphical interface (front-end) functionality. We know that we need to build both the back-end functionality as well as the front-end functionality in order to deliver the business needs so that team feels balanced.
But is the work really divided equally among these two developers? What if one developer is faster? Do we have some weeks where more front-end work is required and others where more server work is required?
Some weeks we have to tackle a complicated algorithm or performance issue on the back-end which creates more work for the back-end developer. Other times, we may have an elaborate interface we want to create but is simple to support on the back-end.
If the back-end developer can do some front-end work and if the front-end developer can do some back-end work we can adapt more easily to change in needs. Not every front-end or back-end task requires olympic skill to execute. It is possible that people can help with easier tasks in areas they are less familiar.
The above example showed just two skills and two team members. In real life, with more members and more skills involves, having (or lacking) versatility leads to a much bigger impact on the team.
Impact of fixed roles
When lack of versatility leads us to use fixed roles for people we may have several problems:
- We adapt the work to the skills that we have instead of to the priorities of the business
- Personnel changes leave a void which is hard to fill.
- Attitude and focus on role vs. customer - we may hear the reply from team members "this is not my job".
Organizational & Cultural Problem
One of the biggest issues with lack of versatility is its possible impact on company culture and overall structure.
As companies grow, you see a large number of dedicated teams organized based on skills set. Database architects (DBA), general architects, operations, IT, installer team, QA team, sustaining team.
At first, it may seem that having dedicated teams is great -
- Dedicated qualified people / resources that can better service the needs of other teams.
- It also makes human resources happy - we can optimize our resources. Having a database architect (DBA) on each team may mean their expensive skills are not fully utilized 100% of the time. Instead, having a smaller and dedicated DBA team allow for better utilization.
While the above reasons look great, they are fundamentally risky. In scrum, there is an expression "watch the baton, not the runners". An HR manager looking at a relay race may not see a winning team, instead they'll see 3 people idle at each moment.
Dedicated teams inevitably lead to local optimization - teams have their own goals that are no longer directly tied to business success. Any given user deliverable may be spread across multiple teams. As such, it makes it hard to set goals based on user deliverables as for specific teams. What usually happens is functional-based goals. QA may want to limit number of bugs and will slow releases. IT may want to reduce costs and will limit the amount of test servers.
In addition, separate teams often leads to increase in process overhead. The DBA team wants to approve database changes. QA wants to approve test plans, developers may test their code even less because it is not their role, we may need larger planning meetings, etc. Suddenly we need project managers and organizers to facilitate work across team boundaries. We increase dependencies and through that organizational complexity.
It's not my problem
Last but not least, by creating separation of responsibilities into teams we take away from ownership. Instead, we create a system that allows a problem to "not belong to me". "They are responsible for this". As managers, we set ourself up with playing judge. Should the development team have caught the bug in automated test or was QA responsible for running a regression test?
Scrum teams
Scrum - one of the most popular development processes - suggests that engineering groups are divided into small cross-functional and independent teams of 4 to 7 people. The team has all the skills to deliver end-to-end functionality for the user. The team focuses on the user needs and not on internal functional structure within engineering.
Having small dedicated teams negates some of the issues mentioned above. However, to be successful, the team needs to be able to tackle the various tasks given to it which means it needs to have a wide-enough range of skills and be versatile.
Not everyone needs to be versatile
While versatility is important, it does not mean that every team member must be versatile. In some cases, we need a guru in specific areas. Someone who is a super star in some difficult aspect of our product. In other cases, we have enough dedicated work in specific area of skill set that makes it OK (not great) to have some less versatile players.
From a practical perspective, finding great people is hard and not everyone can be a superstar in all areas. We also have a limited budget.
Not Limited to Development
The examples here focus on development teams but versatility applies to many other areas. Sales, marketing and even outside of high tech.
For example - American Football teams highly regard versatility as a way to compensate for limited budget (due to salary cap), limited number of players on the team (due to rules) and large number of positional skills.
No comments:
Post a Comment