Managing challenges of leading, motivating, and grooming talent in small teams

Abstract

Managing large projects/teams is a complex problem. Hence, a significant amount of published work is focused on addressing the challenges in managing large projects/teams. However, a number of projects, both in large and small companies, involve managing small teams (e.g., most projects in small companies/startups, pilot projects, agile methodology projects, rookie managers being initially assigned small projects even in large companies, etc.). Although managing small teams seems easy, actually it presents a number of unique challenges that are immensely different from challenges faced in managing large teams. However, most of the published work on managing small teams/projects addresses only the issue of simplifying project management processes. A major issue not being sufficiently addressed is meeting the challenges in managing the “human dimension”—assigning managers/team members roles based on their strengths, building their skills through training/mentoring, motivating them, managing their growth aspirations, managing the significant impact of attrition on small teams, etc. This paper explores such challenges in managing small teams and suggests solutions. I consider cases in both large organizations and small companies/startups, and present approaches to be adopted in both product development and services projects. The work is based on experiences of managing small teams in global leading software companies like Novell, Cabletron, QLogic, Atheros, Mindteck, etc.

Keywords: Small team, small project, pilot project.

Introduction

It is a known fact that management of large projects/teams is quite complex and presents many challenges. Hence, a significant amount of published work addresses this topic.

However, a number of projects in both large and small companies involve managing small teams, including:

•    Most projects in small companies/startups where overall company team size is small
•    Pilot projects, even in large companies
•    Agile methodology projects
•    Rookie managers being initially assigned small projects

It should not be assumed that, unlike managing large teams, managing small teams is easy. Small teams present a number of unique management challenges that are immensely different from the challenges faced in managing large teams.

Most of the published work on managing small projects/teams focuses on the need for simplifying management processes. However, simplified processes alone cannot ensure success of projects since it is the team members who finally have to deliver using these processes. Hence, in this paper I present techniques to successfully lead, train, mentor, motivate, and meet aspirations of managers and team members of small teams.

The paper is based on experiences of managing small teams in leading global software organizations— large companies, small companies/startups, product development and services companies like Novell, Cabletron, QLogic, Atheros, Mindteck, etc. I consider a maximum team size of ten members (including the manager), with the complete team directly reporting to the manager.

I start by discussing the related work and then discuss major challenges in managing small teams and suggest solutions to address them—experience/skills/training requirements for managers; scientific method for assigning multiple roles to managers with light loads; techniques to motivate team members despite constraints imposed by small team size; and ways to mitigate the significant impact of attrition on small teams.

Related Work

It has been argued that small teams deliver better results than large teams since they display greater accountability, greater cohesion and commitment, and reduced processes and paperwork (Baker, 2009).

Although techniques for managing small projects/teams have received some focus in literature, most of the published work addresses the issue of simplifying management processes (Ladika, 2008; Kroll, 2007; Larson & Larson, 2004; Fuezery, 1998; Rowe, 2007; Rincon, 2006). All these published works suggest that although managers should not skip the planning process and basic documentation requirements, other management methodologies used in large projects can be overkill for small projects. Hence, managers should simplify project management methodologies, processes, and frameworks. In this paper, I look beyond process simplification and focus on people management in small teams.

Team members in small teams are generally willing to take on any tasks, roles, and responsibilities since there is never enough manpower for available tasks (Ladika, 2008). In this paper, I will suggest how managers should effectively utilize this fact to motivate team members.

The manager of a small team is generally not fully loaded with responsibility. Hence, it has been recommended that he should also act as a technical team member or should manage multiple small projects (Fuezery, 1998). In keeping with this idea, I propose a range of possible roles that may be played by the managers in product development and services organizations. I suggest using the scientific method of assessing the manager's “personality type” to assign his additional roles.

Rowe (2007) presents methods for a manager to motivate small team members, suggesting that the manager lead by influence and not by authority. I will describe many more actions that a manager should take to motivate team members.

Desired Experience, Skills, and Training Requirements for Managers

The characteristics and requirements necessary for managing small projects/teams are different from those necessary for managing large projects. Hence, the managers' desired experience levels, management/technical skills, and training requirements are different.

In a large company, there is a pool of managers from which to select the most suitable managers to manage small teams. I will discuss the desired experience/skills of managers to be assigned such roles.

However, in small companies/startups, the total manpower in the company is small. Hence, all project teams are small, and all managers have to lead small teams. A small company does not have the luxury of assigning managers with specific skills to teams that require those skills. For such scenarios, I suggest training requirements to groom managers to meet the challenges of managing small teams.

Managers of small teams face the following challenges:

1.  ii.    Managers generally look forward to managing large projects. Hence, it is challenging to motivate them to take responsibility for small teams.
2. iii.   Senior engineers are not interested in joining small teams with small projects since the tasks are not challenging as compared to their previous experience. Hence, managers have to lead teams of young engineers. The managers need to groom these young, inexperienced teams on project requirements/technologies.
3. iv.    In large projects/teams (product development/services projects), there are multiple senior personnel handling various responsibilities (project manager, program manager, project leads, etc.). Since a small project is being managed by a manager with a young team, the manager is generally the sole senior person knowledgeable about the activity. Hence, the manager needs to have expertise to act as the sole external interface for the product/project.
4.  v.   It is generally assumed that since the manager is not handling the challenges of leading large teams, he need not be highly expert in tackling interpersonal conflicts. Hence, interpersonal trainings for managers are generally ignored. However, on the contrary, this skill is much more critical for managers of small teams than it is for the managers of large teams. In a team of only five engineers, if two team members are having a conflict then 40% of the project gets impacted. The project is bound to be doomed. In comparison, a conflict between two team members in a large project has a very small impact.

I suggest the following solutions to address these challenges:

1.   i.   It is preferable to assign small projects/teams to rookie managers (i.e., managers with seven to nine years of experience who have recently been promoted to project leads/senior engineer roles). Since they are learning new management techniques, they will be excited and motivated in their roles despite the small size of their teams.
2.  ii.   However, some small projects are complex and rookie managers cannot manage them. Further, in small organizations/startups all managers, including senior managers, need to handle projects with small teams. Hence, it is a major challenge to keep them motivated even when handling such responsibilities. I suggest that such organizations hire managers who are technically inclined. Managing small teams allows them time to jump quite deep into the technical aspects of the project/product, an opportunity not provided in large projects where they are loaded with a huge set of project management responsibilities/tasks. Hence, technically inclined managers enjoy their tasks and remain motivated. If the managers are not technically strong then they should get trained/mentored in the technical domain of the project. A moderate level of technical skill is also acceptable since the manager can have an architect on the team to handle complex technical tasks.
3. iii.    There are other reasons for the manager to have moderate to high technical skill. Being the sole senior person in the team, he is the sole interface to the external world for the product/project. Hence, he must be able to technically understand the product/project, present it to external entities, understand their input, and incorporate it into the product/project.
4. iv.   Further, small teams have relatively inexperienced team members. A technically strong manager can quickly train/groom young engineers on the project requirements. Further, the impact of attrition on a small team is much greater than it is on large teams. A technically strong manager will have a deep understanding of the project requirements/design/technologies, and can therefore ensure that the impact is minimized and new replacement joinees can be quickly brought up to speed on the project.
5.  v.    As discussed earlier, unique management skills are required for managing small teams. Hence, I suggest that the manager undergo at least Franklin Covey's “7 Habits” training. He should also get extensively trained in skills like managing interpersonal conflicts, training/mentoring young team members, motivating team members, etc.

Multiple Roles for Managers

Managers leading small teams have relatively small workloads. Small workloads can sometimes demotivate managers, especially if they are experienced senior managers. Small workloads also result in managers having more time on hand, which leads to them micromanaging the team members and making them unhappy. Hence, I suggest utilizing these managers' additional time judiciously. As discussed in the previous section, these managers generally have good knowledge of the technical/business domains of the product/project. Hence, organizations should utilize their knowledge and assign them a dual role related to the product/project they are managing.

I suggest one of the following additional roles in product and services companies, respectively:

Product Companies:

•   Product Management: The manager can play a product management role—study competing products, gather new requirements from customers, and suggest new features to the product.
•   Customized Solutions: Customers sometimes look for an end-to-end managed solution instead of adopting only the core product. The core product needs to integrate with customers' existing systems/software and needs to offer a range of additional features specific to their requirements. The manager can gather input from key customers and suggest customized solutions to them, which can then evolve into new services projects around the core product.
•   Architect: Usually projects have dedicated architects. However, in the absence of such a technical expert, this role can be assigned to the manager of the project. This option should be exercised only when the manager is technically strong and can balance his technical tasks with his management responsibilities.

Services Companies:

•   Business Development: If the manager has good expertise in the technology/business domains of the services projects he is managing, he can play the additional role of a “business development manager” in these domains. He can approach other customers with similar services project requirements, present the company's expertise in the specified technology/business domains, convince the customers, and win new services projects.
•   Architect: For the services project.

The decision to give the manager this additional role depends on both his technical expertise and his psychological personality. I suggest that the manager undergo a scientific “personality type” assessment using the Myers-Briggs Type Indicator (MBTI) assessment (Myers & Myers, 1995; Jung, 1971; Damle, 2010).

The MBTI measures people's psychological preferences in how they perceive the world and make decisions. The MBTI defines “personality types” using a combination of the following attitudes/psychological functions:

Attitudes: Extraversion/Introversion

Extraverts (E) are action-oriented, operating in the external world of behavior, action, people, and things.

Introverts (I) are thought-oriented, operating in the internal world of ideas and reflection.

Perceiving (Information-Gathering) Functions: Sensing/Intuition

Sensing (S) individuals trust information that is present, tangible, and concrete. For them, the meaning is in the data.

Intuitive (N) individuals trust information that is abstract and theoretical. For them, the meaning is in the underlying theory and principles that are manifested in the data.

Judging (Decision-Making) Functions: Thinking/Feeling

These are decision-making functions based on data received from the information-gathering functions.

Thinking (T) individuals decide from a detached standpoint, measuring the decision by what seems reasonable, logical, causal, consistent, and matching a given set of rules.

Feeling (F) individuals decide by associating and empathizing with the situation, weighing the situation to achieve the greatest harmony, consensus, and fit, considering the needs of the people involved.

Judging Versus Perception Preference

Judging (J) individuals show the world their preference for judging function. Perceiving (P) individuals show their preferred perceiving function.

Let us consider an example of a technically “moderate” manager with the personality type extravert/intuitive/thinking/judging (EITJ) working within a product company:

•   Since he has only moderate technical skill, he cannot play the architect role.
•   Since he is an “extravert” (E), he likes interacting with the external world and people. Hence, he can be considered either for a “product manager” or a “customized solutions” role since in both cases he needs to interact with customers to understand their requirements.
•   His “intuitive” (I) ability allows him to think beyond the features data gathered from customers and from competing products, and allows him to think innovatively to suggest totally new features for the product. Hence, the role most suitable for him would be that of a “product manager.” His intuitive capabilities would be wasted in a “customized solutions” role, since in that role he just has to follow customer instructions to tailor the product to the customer requirements.
•   Further, his “thinking” (T) preference, which is also his dominant judging (J) function, allows him to logically evaluate competing products' feature sets and decide on the right product features.

Hence, he should take up a product manager role.

Motivating Team Members

In a small team, members have limited challenges and growth opportunities, and therefore they generally lack motivation. Hence, an important challenge for managers of small teams, as compared to managers of large teams, is to keep the team motivated despite these constraints.

I suggest the following techniques to motivate the team:

1.  i.    First, the manager should be careful in selecting the team members. In a small team, the manager handles most of the important functions with limited scope of delegating any major function to another senior team member. Hence, if the organization has senior engineers/project leads who aspire to ascend quickly to management roles, then they should not be included in small teams. They fit better in large teams where they can get the responsibility of leading a subset of team members dedicated to specific project modules. A small team should ideally consist of either young engineers or technically inclined senior engineers who aspire to ascend the technical ladder (not the management ladder).
2. ii.    The major benefits for members of small teams are that they generally have a complete view of the product/project and have direct interfaces with the project manager, product manager, internal/external customers, etc. In contrast, engineers in large teams have a narrow focus since they are exposed only to their specific project module, usually interact with only their immediate project lead, have limited interactions with the overall project manager, and have minimal interfaces with external entities.
3. The managers of small teams should utilize these facts to motivate their team members through the following means:
4.  •   The project manager is responsible for interacting with external entities, such as the product manager and internal/external customers. In the case of large projects, the manager generally includes the project leads of various modules in such meetings since they can share details of progress on the feature set of modules they are managing.
5. However, in small teams, the manager does not have the luxury of having project leads. The manager should utilize this fact to increase exposure of young team members.
6. The knowledge of the complete project is distributed among all team members. Hence, the manager should include the concerned team members in meetings with these external entities when the feature set/module they are handling needs to be discussed. As a result, young team members get opportunities to interact with the product manager to understand how product/project strategies and feature set are decided. They get opportunities to interact with customers to understand their requirements/issues and learn how to convert this input into features. This exposure gives them a broader perspective, trains them on tasks that engineers of their experience usually do not handle, and prepares them for future major responsibilities. This causes the engineers to feel excited about their work.
7.  •    The manager should regularly interact with the team members, share with them the complete understanding of the product/project, and show how it fits into overall company goals. This systemic view of the product/project and understanding of the criticality of their own roles to the success of the overall activity motivates team members to perform.
8.  •   In order to motivate the architect on the team, the manager should inform him that he is developing the complete product/project architecture, instead of developing a single module for a large project. He is handling major, complex, and challenging tasks that prepare him for future responsibilities.
9.  •     In small teams there is never enough manpower for the available tasks. Hence, each team member should be assigned multiple tasks that will make him learn and apply multiple technologies/techniques—an opportunity that a small module in large project may not provide. The challenges being offered by the project keep him motivated.
10. iii.    In a small team, the growth opportunities for team members are limited. Companies sometimes have very strict policies limiting the percentage of team members who can be rated highly, since they want to maintain a bell curve in the organization for performance ratings (e.g., a company may have a policy that only 15% of a team's members can be rated at level “A”). In large teams, this is not an issue since the number of members who can reach this high rating will rarely reach the limit (e.g., for a 30-member team, five members can be rated “A,” which is a reasonable number). However, if the team has only six members total, then a maximum of only one member can be rated “A,” which is very constraining for the manager, especially if he has more than one star performer. Hence, the bell curve has to be artificially applied to small teams, leading to employee demotivation.
11. The solution is for the manager to convince the organization not to force a bell curve on individual small teams but to spread it across multiple small teams. For example, he could create a pool of five small teams of six members each to form a virtual team of 30 members. In performance rating meetings, the managers of these teams can present their cases to the “engineering head” to select the top five members among these teams for an “A” rating. Since the engineering head is aware of the relative performance of each team, he can judge which teams have higher numbers of high performers, and thus more members of those teams can be rated “A.”

Mitigating Attrition Impact

The impact of attrition on small teams/projects is much higher than it is on large projects. For example, if even a single member leaves a four-member team, the project loses 25% of its workforce! The impact on his module and on the overall project can be drastic.

Hence, the manager must apply techniques to prevent attrition and mitigate its impact, if it occurs. The motivational techniques described in the last section can control attrition to a large extent. The manager can also apply the following techniques:

1.   i.    As a first step, the manager should avoid choosing team members who are spouses! If the team contains a married couple then there is a very high possibility that if one leaves (to pursue an opportunity in another city, for example) then the spouse will likely leave as well. Hence, such related personnel should be distributed among different teams.
2.  ii.    The manager should insist on team members holding regular knowledge-sharing sessions within the team about their modules. Hence, if one member leaves then others are still knowledgeable about his work, which reduces the impact of attrition.
3. iii.   Managers should also formally groom backups for team members. In large teams, the managers have the luxury of having additional resources who are earmarked as backups. Unfortunately, small teams always have limited resources and therefore cannot plan a backup within the team. The manager of a small team should work in tandem with the manager of a large team in the organization to earmark an additional resource within that large team as a backup for his team. That engineer should be regularly involved in the project functions of the small team so that he is aware of the tasks being performed by other members. For example, he can act as a project design/code/test-cases reviewer. Then, if a member of the small team leaves, he is ready to join the team and quickly take over the leaving member's module.
4. iv.    However, in a small company/startup the manager cannot depend on another large team for backups. In such a case, the company should offload some project tasks to a services company. Then the services company's resource can act as a backup for the small team.