In most cases, not enough attention is paid to onboarding team members.Now I'm not talking about solution rollout or customer adoption of the project. No, I am referring to onboarding the actual members of the project team, the people responsible to develop and implement the solution.
In fact, the biggest, most spectacular failures I've been on were the ones when there was no onboarding strategy for project team members at all. That is, people rolled on and off the project at various intervals depending on the phase of work (conception, design, procurement, configuration, implementation, rollout, operations) and no one made sure that they understood the project when they arrived.
I have a tendency to work on projects that have aggressive timelines and strict budgets. Almost every time new people join, the project is already racing toward some deadline or deliverable. New hires get desks, assignments, meet too many people on day one to remember any names, and then are given work. "Read these, work on that" is the most common onboarding approach I've seen to date. New team members are left fending for themselves, expected to start running from day one, and try to keep up.
No one takes them aside and says:
- You're here to purchase a solution for the this specific set of clients trying to do this particular work. Here is the research that led to this decision, why we chose this type of solution to meet the client needs and what the procurement outcome should be.
- You're here to configure the system, so here's why we designed it this way and procured this particular solution. Read the RFP. Let's walk through the timeline of how we got here.
- Your job is to maintain a system that's already been developed. Here's everything it can do and why it was configured to work this way. Here are the common functional questions we get and why we made these design decisions.
Moreover, on large-scale enterprise projects, team members are often hired by different project groups and therefore onboarded inconsistently, and the original mission for the project gets completely lost in translation. Over time, because they don't know the history or big picture on the project, they make decisions that conflict directly with the project principles and its original intent. They question previous decisions made, dispute work that has already been completed, and sometimes even have the power to entirely halt projects to re-evaluate decisions that were made in earlier phases. If there are disputes, sub-teams can become territorial over their particular areas of responsibility and start to circle wagons against one another, rather than work together toward the common project vision.
On one project, I had an exec ask me why my sub-team had such strong culture, and why the overall project team didn't have any culture at all. The short answer: we onboarded our people; the other subgroups didn't. You can't force culture; it emerges organically. But the teams I've been on with the strongest culture were those where a concerted effort was made not only to bring new members up to speed with the work, but with the ideas that underlie the work. Without saying so much, we infused them with the mission and vision of the project by spending the time to help them understand why we were doing what we were doing. Making sure that we weren't just explaining what they would be doing, but why and for whom.
I have set a personal goal on my projects to onboard new team members by giving them the project history, including the timeline and key decisions of how we got here. The project context walk-through doesn't have to be lengthy — even setting aside an hour weekly for the newbies' first month to walk-through the project timeline to date, explain key historical milestones and decisions, and to answer questions can provide new team members with enough information to understand how the project got to where it is today. It helps them understand where their role and their work fits within the entire project. They are encouraged to ask questions and propose ideas, to actively contribute all while respecting the thought, the design, the research and the decisions that pre-date them.
While it might not solve all of the issues surrounding a project, I've definitely seen deliberate and mindful onboarding of new team members help build a stronger team culture and reinforce collaboration on projects.