Ask EIG: 3 Ways to Successfully Onboard New Team Members
Ask EIG is your chance to seek answers to public sector management challenges and conundrums. No question is too big or small, complex or simple. Submit your questions at AskEIG@govexec.com.
Knowing that there are often new people involved in teams and or decisions, how do you ensure “bee-in” for them rather than just “buy-in”
Last February on "Ask EIG", I introduced a leadership concept called "bee-in", which represents a specific set of leadership processes that not only helps with diversity and inclusion but also helps teams build trust and create understanding. Teams that develop these characteristics have deep commitment to each other and to their projects and, as a result, are more likely to successfully discover and implement valuable solutions.
In contrast, asking individuals to “buy-in” implies that they weren’t important enough to be included in the conversation in the first place. Leaders who seek "buy-in" often don’t develop much trust and understanding within their teams and rarely generate commitment to either the project or each other. Worse, some team members may refuse to "buy-in" and work to slow or kill the project. The end result is that projects relying on buy-in rarely succeed in achieving their desired performance goals and may fail entirely.
(HAVE A QUESTION? Send your most pressing management questions to AskEIG@govexec.com)
There is no doubt that changing team membership can cause your team—and project—to unravel and fail. Adding or changing team members can quickly diminish commitment. Without being with the team from the beginning, why would a new team member be committed to any decision others previously made? Questioning prior decisions and injecting different views and preferences can create team conflict that undermines trust, impedes understanding, and reverses prior commitments. Moreover, if a new team member controls a critical resource but is not collaborative or has a domineering personality then team commitment quickly can collapse leaving few options but to fail or to shift to autocratic decision-making. In other words, bringing new people on the team and doing so late-in-the-game can erode "bee-in," making it necessary to switch to "buy-in" and all that comes with it.
You may want to lead your team using a "bee-in" approach but how can you succeed if your team members change over time? How can you develop and sustain trust and understanding as well as commitment if people are rotating on and off your project? Is there anything you can do to lead in such circumstances or is "bee-in" a naive ideal that simply can’t be reached for some projects?
To develop useful strategies for maintaining "bee-in" it is useful to identify a few common reasons why team members change. All too often:
- teams are formed without thinking about what information and knowledge sets are needed and who will be critical to implementation efforts. In other words, not enough thought went into thinking about who should be on the team and hence the initial team composition is chosen poorly requiring future additions.
- new team members do not have much knowledge of the project and its history and do not have appropriate expectations about their role moving forward on the team.
- project complexity and duration necessitate the coming and going of team members. For instance, complex information technology projects and weapons systems using a waterfall approach to project management can last many years and may necessitate changing team members as various specializations are needed at various times or because of employee turnover.
In response to these common reasons for new people joining teams, three strategies may help you sustain bee-in.
- First: The most important strategy is to be far-sighted and initially form your team with everyone you will need for the life of the project. For instance, I recommend that you should invite individuals to join the team who (a) possess the relevant information and knowledge that are likely to be needed to formulate and solve the challenge and (b) will be critical to implementation efforts. At first it may seem like constructing such a team is inefficient because those involved in implementing are not needed until much later in the process. You may be concerned that these people will waste their time and slow down team progress thereby harming productivity. Yet, without "bee-in" participation early on, those who you rely on for implementation may become blockers. Indeed, without participation from the beginning these people may never support implementation efforts, which is the worse inefficiency of all.
- Second: Even if individuals are not formally on a team, it is important to involve everyone in your community by frequently apprising them of the project’s progress and soliciting their feedback. As you proceed with each stage of your project, document each step and solicit feedback from your broader community before proceeding so they have an opportunity to participate. Doing so demonstrates that you respect their feedback, gives them an opportunity to contribute, and keeps them from rehashing past decisions. In essence, involving your entire community in "bee-in" makes it easier to add new people to the team without disrupting it.
- Third: Projects that last months if not years pose a specific challenge. Wherever possible, I recommend changing the project so that it is short in duration or can be separated into a series of projects each of which can be completed. For instance, waterfall project management approaches that would take up to a decade to design and build complicated information technology systems are giving way to “agile” development approaches that reduce develop time up to 90% by focusing on only the critical product features needed. These new approaches convert one complex project into a series of smaller projects.
In sum, my recommendation is to choose teams wisely so you won’t need new team members, invite broad awareness of and participation from your community so that new team members already are in the process, and restructure projects so that are short enough to maintain team membership. Can you always execute these strategies? No. Nonetheless, I suspect that these strategies can used more than they are to maintain "bee-in" and increase project success.
Duce a mente (may you lead by thinking),