1. 1 of 9
Managing Small Teams – Look beyond
Process Simplification
Vimal Kumar Khanna
Abstract
Managing large projects/teams is a complex problem. Hence, a significant amount of published work is
focused on addressing challenges in managing large projects/teams. However, a number of projects,
both in large and small companies, involve managing small teams – like most projects in small
companies/startups; pilot projects; rookie managers being initially assigned small projects even in large
companies; etc. Although, managing small teams seems easy but actually it presents a number of unique
challenges, which are immensely different from challenges 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 challenges in
managing the “human aspect” – deciding manager/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. We consider the cases of managing small teams both in
large organisations and in small companies/startups. We present approaches to be adopted both in
product development and services projects. The work is based on experiences of managing small teams
in global software companies like Novell, Cabletron, QLogic, Atheros, Mindteck, etc.
Keywords: Small team, small project, pilot project.
1. Introduction
It is a known fact that management of large projects/teams is quite complex and presents many
challenges. Hence, significant amount of published work addresses this aspect.
However, a number of projects in large/small companies involve managing small teams –
- Most projects in small companies/startups where overall company team size itself is small
- Pilot projects, even in large companies
- Rookie managers being initially assigned small projects, etc.
It should not be assumed that, unlike managing large teams, managing small teams is easy. Small teams
present a number of unique management challenges, which are immensely different from challenges in
managing large teams.

2. 2 of 9
Most of the published work on managing small projects/teams focuses on 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 we would
present techniques to successfully lead, train/mentor, motivate and meet aspirations of the manager/team
members of small teams.
The paper is based on experiences of managing small teams in leading global software organisations –
large companies, small companies/startups, product development and services companies – like Novell,
Cabletron, QLogic, Atheros, Mindteck, etc. We are considering maximum team size of eight members,
with complete team directly reporting to the manager.
We start by discussing the Related Work. We then discuss major challenges in managing small teams
and suggest solutions to address them – experience/skills/training requirements for managers; scientific
method for deciding multiple roles for lightly-loaded managers; techniques to motivate team members
despite constraints imposed by small team size; and mitigating significant impact of attrition on small
teams.
2. Related Work
It has been argued that small teams deliver better results than large teams since they result in greater
accountability/cohesion/commitment and reduced processes/paperwork [1].
Although, techniques to be followed in managing small projects/teams has received some focus in
literature, but most of the published work addresses the issue of simplifying management processes [2-7].
All these published works suggest that although managers should not skip planning process and basic
documentation requirements, but other management methodologies for large projects can be an overkill
for small projects. Hence, managers should simplify project management
methodologies/processes/frameworks.
Team members in small teams are generally flexible to take up any tasks/roles/responsibilities since there
is never enough manpower for available tasks [2]. We will suggest how managers should effectively
utilise this fact to motivate team members.
Manager of a small team is generally not sufficiently loaded. Hence, it has been recommended that he
should also act as a Technical Team Member or should manage multiple small projects [5]. We extend
that work extensively by proposing a range of possible multiple roles to be played by the manager in
product development and services organisations. We suggest a scientific method of assessing
“Personality Type” of the manager to decide his additional role.

3. 3 of 9
Methods for a manager to motivate small team members are presented in [6], suggesting the manager to
lead by influence and not by authority. We will describe many more actions that a manager should take to
motivate team members.
3. Desired Experience, Skills & Training Requirements for Managers
The characteristics and requirements of managing small projects/teams are different from managing large
projects. Hence, desired experience levels, management/technical skills and training requirements of
managers are different.
In large companies, the company has a pool of managers from which it can select the most suitable
managers to manage small teams. We will discuss the desired experience/skills of managers to be
assigned such roles.
However, in small companies/startups, the total manpower in the company itself is small. Hence, all
project teams are small, and all managers have to lead small teams. Hence, company does not have the
luxury to assign managers with specific skills. For such scenarios, we will suggest training requirements
to groom managers to meet the challenges of managing small teams.
Managers of small teams face the following challenges –
i) Managers generally look forward to managing large projects. Hence, it is challenging to
motivate them to take up responsibility of small teams.
ii) Since the project is small, senior engineers are not interested in joining such teams since the
tasks are not challenging as per their experience. Hence, managers have to lead teams of
young engineers. The managers need to groom these young inexperienced teams on project
requirements/technologies.
iii) 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 has to have expertise to act as the sole external interface for the product/project.
iv) 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 in managers
of small teams is much more critical than for the managers of large teams. Assuming a team
of only five engineers, even if two team members are having a conflict then 40% of the

4. 4 of 9
project gets impacted. The project is bound to be doomed. In comparison, a conflict among
two team members in a large project has a very low impact.
We suggest the following solutions to address these challenges –
i) It is preferred to assign small projects/teams to rookie managers – i.e., managers who are
recently promoted from Project Leads/Senior Engineers roles (say, 7-9 years experience).
Since they are learning new management techniques, they would be excited and motivated
on their role despite the team being small.
ii) However, some small projects are complex and rookie managers cannot manage them.
Further, in small organisations/startups all managers need to handle projects with small
teams, including senior managers. Hence, a major challenge is to keep them motivated even
when handling such responsibilities. We suggest such organisations to hire managers who
are technically-inclined. Managing small teams allow them time to jump technically quite deep
in the project/product, an opportunity not provided in large projects where they are loaded
with a huge set of 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 in the team to handle complex
technical tasks.
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 inputs and incorporate them in the product/project.
iv) Further, small teams have low experience team members. A technically strong manager can
quickly train/groom young engineers on the project requirements. Further, the impact of
attrition within a small team is much higher than on large teams. A technically strong
manager will have a deep understanding of the project requirements/design/technologies,
and hence can ensure that the impact is minimised and new replacement joinees can be
quickly brought up to speed on the project.
v) As discussed earlier, unique management skills are required for managing small teams.
Hence, we suggest the manager to at least undergo Covey’s “Seven Habits Training”. He
should also get extensively trained on skills like – managing interpersonal conflicts;
training/mentoring young team members; motivating team members; etc.
4. Multiple Roles for Managers

5. 5 of 9
Managers leading small teams have low workload. This low workload can sometimes demotivate the
managers, especially if they are senior experienced managers. Low workload also results in managers
having more time on hand, which leads to their micromanaging the team members and making them
unhappy. Hence, we suggest utilising the additional time of these managers judiciously. As discussed in
previous section, these managers generally have good knowledge of technical/business domains of the
product/project. Hence, organisations should utilise their knowledge and assign them a dual role related
to the product/project being managed by them.
We suggest one among the following additional roles in product and services companies, respectively –
i) 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.
- Customised 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 play the role of gathering inputs from key customers and suggesting
customised solutions for them, which evolve into new services projects.
- Architect/SME: Usually projects have dedicated Architects/Subject Matter Experts (SME).
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 when the manager is technically very strong and can
balance his technical tasks with management responsibilities.
ii) Services Companies:
- Business Development: The manager has good expertise in the technology/business domains
of the services projects he is managing. He can play additional role of being a “Business
Development Manager” in these domains. He can approach other customers having similar
services projects requirements, present company’s expertise in the specified technology/business
domains, convince the customers and win new services projects.
- Architect/SME: for the services project.

6. 6 of 9
The decision on choice of the additional role for the manager depends both on his technical expertise and
his psychological personality. We suggest that manager should undergo a scientific “Personality Type”
assessment using Myers-Briggs Type Indicator (MBTI) assessment [8-10].
MBTI measures psychological preferences in how people perceive the world and make decisions. MBTI
defines “Personality Types” as a combination of the following attitudes/psychological functions –
Attitudes: Extraversion/Introversion
Extraverts (E) are action-oriented, operating in external world of behaviour/action/people/things.
Introverts (I) are thought-oriented, operating in internal world of ideas/reflection.
Perceiving (information-gathering) Functions: Sensing/Intuition
Sensing (S) individuals trust information that is present/tangible/concrete. For them, the meaning
is in data.
Intuitive (N) individuals trust information that is abstract/theoretical. For them, the meaning is in
underlying theory/principles that are manifested in the data.
Judging (decision-making) Functions: Thinking/Feeling
These are decision-making functions based on data received from above 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/empathizing with the situation, weighing the situation
to achieve the greatest harmony/consensus/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) show
their preferred perceiving function.
Let us consider example of a technically “Moderate” manager with Personality Type “ESTJ”. Since he has
only moderate technical skill, he cannot play the Architect role and should take up one of the other
described roles. Since he is an “Extrovert” (E), he likes interacting with external world/people. Hence, he
can be considered for a “Product Manager” role since he needs to interact with customers to understand

7. 7 of 9
their requirements. His Sensing (S) function allows him to gather tangible data about features/capabilities
of competing products. His Thinking (T) preference, which is also his dominant Judging (J) function,
allows him to logically evaluate customers’ inputs and competing products’ feature-set and decide right
product features.
5. Motivating Team Members
Since the team size is small, its members have limited challenges and growth opportunities. Hence, they
could 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.
We suggest the following techniques to motivate the team –
i) To start with, 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 organisation has very senior
engineers/project leads, who aspire to grow fast to management roles, then they should not be
included in small teams. They fit better into large teams where they can get the responsibility of
leading a subset of team for specific project modules. A small team should ideally consist of
either young engineers or technically-inclined senior engineers, who aspire to grow in technical
ladder (not management ladder).
ii) The major benefits for members of small team are that they generally have 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 only with their immediate
Project Lead, have limited interactions with the overall Project Manager and have minimal
interfaces with external entities.
The managers of small teams should utilise these facts to motivate their team members through
following means –
The Project Manager is responsible for interacting with external entities, like Product
Manager and internal/external customers. In 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 feature-set of modules being managed by them. However, in
small teams, the manager does not have the luxury of having Project Leads. The
manager should utilise this fact to increase exposure of young team members. 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

8. 8 of 9
entities when the feature-set/module being handled by them needs to be discussed.
Hence, young team members get opportunities of interacting with 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 these inputs into features. This exposure gives them a broader
perspective, trains them on tasks that usually engineers of their experience do not handle
and prepares them for future major responsibilities. Hence, engineers are excited about
their work.
The manager should regularly interact with the team members and share with them the
complete understanding of the product/project and show how it fits in overall company
goals. This systemic view of the product/project and understanding of the criticality of
their own role to the success of the overall activity, motivates team members to perform.
The Architect in the team should be motivated by informing him that he is developing
complete product/project architecture, instead of architecting a single module for a large
project. Hence, he is handling major/complex/challenging task that prepares him for
future responsibilities.
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/apply multiple
technologies/techniques, an opportunity that a small module in large project may not
provide. Hence, the challenges being offered by the project keep him motivated.
iii) Since team is small, the growth opportunities for team members are limited. Companies
sometimes have very strict policies on percentage of team members who can be rated high, since
they want to maintain a “Bell-Curve” in the organisation for performance ratings. E.g., the
company may have a policy that only 15% team members can be rated at level “A”. In large
teams, this aspect is not an issue since the possible number of members who can reach this high
rating is limited and can fit within this limit. E.g., for a 30-member team, five members can be
rated “A”, which is a reasonable number. However, if the team size itself is, say, only 6 then
maximum 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.
The solution is for the manager to convince the organisation not to force bell-curve on individual
small teams but to spread it across multiple small teams. Say, create a pool of five small teams of
6-members each, to create a virtual team of 30 members. In Performance Rating Meetings, the
managers of these teams can present their cases to “Engineering Head” to select the top 5
members among these teams for “A” rating. Since Engineering Head is aware of relative

9. 9 of 9
performance of each team, he can judge which teams have higher number of high-performers,
and thus more members of those teams can be rated “A”.
6. Mitigating Attrition Impact
The impact of attrition on small teams/projects is much higher than on large projects. E.g., even if a single
member leaves a 4-member team, the project loses 25% of its manpower! The impact on his module and
on 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. Manager can
additionally apply the following techniques –
i) As a first step, the manager should avoid choosing team members with the same last name!
Say, if the team has a husband-wife combination then there is a very high possibility that both
will leave together, in case one leaves the organisation to move outside the city.
ii) 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.
iii) Manager 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 are always constrained of resources and hence cannot plan a
backup within the team. The manager of small team should work in tandem with a manager
of a large team in the organisation, 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 to be aware of the tasks being performed by other members. E.g., he can
act as project design/code/test-cases reviewer. Hence, if a member of small team leaves
then he is ready to join the team and takeover the leaving member’s module fast.
iv) However, if the company itself is small/startup then the manager cannot fallback on another
large team for creating backups. In such a case, the company should offload some project
tasks to a services company. Hence, the services company’s resource can act as a backup
for the small team.
7. References
1. Baker, B. (2009). In praise of small teams. PM Network, March.
2. Ladika, S. (2008). Bigger isn’t always Better. PM Network, March. pp. 36-39.
3. Kroll, K. (2007). Small Projects, Big Results. PM Network, July. pp. 30-33.

10. 10 of 9
4. Larson, R., & Larson, E. (2004). The Critical Steps to Managing Small Projects. PMI Global
Congress – Prague.
5. Fuezery, G. (1998). Managing Small Projects. PM Network, July.
6. Rowe, S. (2007). Managing and Leading Small Projects. PMI Global Congress – Atlanta.
7. Rincon, I. (2006). Mini and Micro projects: Are the principles of project management
appropriate for managing small companies or small projects? PMI Global Congress – Madrid.
8. Myers, I., & Myers P. (1995), Gifts differing: Understanding personality type. Davies-Black
Publishing.
9. Jung, C. (1971). "Psychological Types". Collected Works of C.G. Jung, Volume 6. Princeton
University Press.
10. Damle, P. (2010). Application of select tools of psychology for effective project management.
PMI India Conference 2010, Mumbai, India.
Author’s Profile
Vimal Kumar Khanna is Founder and Managing Director of “mCalibre Technologies”, a software product
company. He has over 28 years industry experience and has won multiple international honours. He is
listed in “Marquis Who’s Who in the World”. He is also among 30 select experts in the world on “IEEE
Communications” (pub. New York) Editorial Board (invited honorary position). His multiple independently-
written papers have been published in leading international journals/conferences, including PMI North
America, APAC & EMEA Global Congresses; multiple “PMI Asia Pacific e-Link” issues; PMI India
Conferences 2010, 2011 & 2012. He has been interviewed in “PM Network” magazine.