Chapter 9 - Assembling Your Team
Many factors impact the success of a project. In my experience, the two biggest of the four factors are:
- The project management
- The project team
So far, we’ve covered the big keys to managing a project well. The last piece of the puzzle is the team.
You need to have the right team for your project.
What makes a good project team?
- Core competencies
- Clear roles
- Crisp communication
- Distribution of knowledge
- Compelling motivation
You’re going to need these elements whether you have an in-house team or contractors. No matter what the financing model is, it is essential. It’s crucial whether you have a very small team or a very large one.
For serious projects, you need people with the domain skills the project needs. While you can technically assign any roles/tasks to any team member, successful projects require serious domain expertise.
The precise domain skills needed differ for each project.
On a typical business software project, you’ll usually need frontend development, backend development, deployment and operations, as well as a problem domain expert, at the very least.
On a game development project, you’ll usually need character art, environment art, user interface design, gameplay programming, sound, music, marketing, user testing, and deployment.
You don’t necessarily need a different person to have a specific competency. If you’re working solo, you might be trying to tackle all the required competencies. Or, you might have one to three senior team members who have the strongest competencies and who can guide more junior team members. Nearly all projects are more successful with at least a small team, but sometimes cost limitations are a real constraint.
Before starting your project, ensure that the project can afford the core required competencies. Determine which project elements don’t require as much expertise and which elements require high-level mastery. If you are missing a mission-critical competency, the project is in big trouble, even if this doesn’t become clear until the end.
If you are interested in hearing the story of my worst project management failure, skip ahead to Appendix 1. It’s story will give you a clear picture of how essential it is to cover the core competencies fully and as soon as possible.
For a team to work well, everyone needs to know precisely what they are doing.
- Who is doing which part?
- Who should X ask for guidance or content approval?
Roles are usually organized around competencies, but not always.
From my experience, every key competency needs to have one dedicated lead role. So, for example, you can have 4 environment artists and 1 lead environment artist. You can have 3 frontend engineers, as long as you have 1 lead frontend engineer to make the tough architectural decisions.
If you are missing any lead roles, you will find that either wasteful conflict or directionlessness will occur.
For non-key competencies and non-lead roles, there is an excellent opportunity for teaching people, sharing knowledge, and expanding competencies. You can assign someone new to a skill to shadow or collaborate with someone more experienced on the project. Suppose you’ve got a UX Designer who wants to learn some frontend programming, you can assign them a Frontend Programming role on the project, and they can learn through practice.
People can also be assigned multiple roles. Sometimes different roles have a different amount of required work. As long as you don’t end up with any person allocated with more work than they can handle, people can definitely cover multiple roles.
One thing to be careful with when assigning multiple roles is that you need to realize there are costs to assigning multiple roles. In addition to the obviously larger workload, there is also the cost of the context switching, of additional communication, and a potential cost to quality due to a split focus. A person with one role can polish something until it’s really great. With multiple roles, usually, only one area of focus will end up superb.
If you do assign multiple roles to a single contributor, make sure you assign priorities to each role. If you have a UX Engineer who is also doing Sound Design and Music Composition, you need to set clear expectations for which role is most and least important of the three.
There are several elements to this. When you are working with a team that is already comfortable and trusts each other, a lot of the communication will flow naturally.
There is tension between having a team with too much communication and too little communication.
Too much communication can happen when there is uncertainty, an unclear vision, or team members that aren’t very confident in their role. It can also happen if you have a highly social team.
As a project manager, you want to ensure that the team is equipped to communicate:
- With directness and efficiency
- When conversations would be beneficial
- When there is a knowledge or requirements gap
But, you also want to be sure that there aren’t problems such as:
- Repeated conversations about the same things
- Playing telephone (the same message sent individually many time)
- Wasteful back-and-forth
For ad hoc and newly assembled teams, the key element is building team comfort and trust. If everyone feels that they can raise technical and creative issues or feedback without negative repercussions, this will greatly help the project!
If people are afraid to be the bearer of bad news, the project may be in danger in subtle ways that aren’t discovered until later. If people don’t know who to ask about a thing, they might end up tying up a lot of team time asking other team members one by one. If people aren’t sure if they can trust some project guidance, they might want second opinions.
Build up trust and comfort. Make sure the team knows who to talk to about which things. Watch for too little communication (people are stuck and afraid to speak up) or too much conversation (poor guidance, lacking shared vision).
Distribution of Knowledge
This is similar to core competencies, but there is one other angle you want to consider.
Ideally, you should have knowledge spread around the team.
You may have 1 superstar who knows about a LOT of areas of the project. However, suppose you have 1 superstar and 9 members who aren’t as knowledgeable about as many project dimensions. In that case, you will find that the superstar is spending all his time guiding and assisting the other team members. This is good for the team’s growth but very risky for the project. The superstar isn’t able to focus on delivering on their core role. They, explicitly or not, will take on the role of Team Mentor or Domain Expert.
You might run into another version of this problem if you have 6 team members who are fantastic programmers, and each one has a little knowledge in another domain area. Perhaps, of your 6 coders, 1 has dabbled with graphic design. Perhaps, 1 has some experience with deployment. The downside of this spread is that if your one coder with graphic design experience needs some graphic design feedback, nobody else on the team can offer good advice or guidance.
What you want is for at least 2 members to have some knowledge of every area of the project. If you have more knowledge spread, that’s even better since it will be easier for people to collaborate with whoever is available.
The more distributed the team’s knowledge is, the healthier the project will be. The more concentrated the team’s knowledge is, the more risk the project is facing.
The other crucial thing is that you want everyone on your team to be highly motivated.
They need to be motivated not only to work on this project, but also to work on this project with this team.
Without that motivation, you may find members disappearing from the project or just burning through time without producing anything.
This one is so important and so hard to get right that I have written a whole chapter about it. You’ll be reading that one next.
Team Formation Guidelines
As the project manager, you need to be good at putting together teams and providing guidance so that the team works well together. These are skills that aren’t taught in school, and most of these aren’t even taught in Project Management literature.
Your ability to understand and influence team dynamics is your third most important skill in being a fantastic project manager.
When you are assembling a team, you want to have a team that:
- Covers the core competencies
- Has clearly assigned roles
- Communicates crisply
- Has distribution of knowledge
- Is highly motivated
Every member on the team should be fully integrated within the team in all 5 of those dimensions. If you have a team member who would jeopardize any of these, the project will be better off without them.
Chapter Review Questions:
- What are the two biggest factors that impact a project’s success?
- What five considerations should you keep in mind while assembling a team?
- Which are the most important of those dimensions?