Product Delivery Team Anti-patterns – (Fend for Your)self Onboarding

Estimated Reading Time: 7 minutes

It isn’t uncommon for product delivery teams to have developed approaches that result in new team members being onboarded quickly via a self-paced, independent onboarding process. From asking engineers to create a developer setup in x hours by themselves to solving something on the backlog that requires no help from others, these teams are engaging in an anti-pattern called (fend-for-your)self-onboarding. Such asks reinforce a pattern of maximizing “solo” time and minimizing collaboration time when you actually need collaborative co-creators and problem solvers on product delivery teams. Paul Sobocinski, Practice Director, Engineering explains how to counteract this anti-pattern by pairing new hires and how to effectively evaluate new members for their technical skills!

This blog post was originally published on Paul’s blog, Coder Spikes.

Over the course of my career, I’ve been onboarded onto dozens of new product delivery teams as a junior, intermediate, and senior software engineer. Every time, regardless of my role, it’s been both an exciting and stressful experience. On the one hand, the existing team members are keen to see what I bring to the team. More cynically, they are eager to evaluate whether I’m up-to-snuff. In that vein, I’ve gotten past remarks such as:

• “That’s a pretty basic query, don’t you have three years of experience in SQL?”

• “As you’ve written production Rails apps before, surely you won’t have an issue creating a basic Ruby class to encapsulate this logic.”

Let’s set aside (for now) that such remarks do not instill the most welcoming environment for the new team member. The key point here is that teams evaluate new members to find and fill knowledge gaps quickly. Sometimes, these gaps are not easily-fillable — when this happens, the team must accept that there may not be a fit on the team for the new member. The sooner the team can find this out, the better for everyone involved.

In addition to the ramp-up of the new team member, verifying that a fit exists is an important goal of any onboarding process.

Many product delivery teams (across different companies) have developed approaches that are ostensibly meant to onboard new team members quickly via a self-paced, independent onboarding process. Here are some examples:

1. Dev environment setup: “How fast can you get your development environment set up? The current record is 6.5 hours, held by Susan. She didn’t need to ask for help once!”
2. Grab something off the backlog: “Pull a bug off the backlog and get it to dev-done. Pick something straightforward so you don’t need to bother the other devs, as they’re busy with the currently-scheduled sprint. That way, you get an idea of our process, and you can show us that you can work independently.”
3. Poke around the codebase: “Play around with the app on your own and walk yourself through the codebase. This should get you familiar enough so that you can work on some features next sprint. Again, try not to bother the team with questions, and instead figure it out on your own by using the app. You’ve used our app before, right?”

In reality, these types of challenges screen for people who prefer to work on their own, and screen out people who are inclined to problem-solve collaboratively. Furthermore, it sets the expectation for the new team member that this is how the team works and reinforces a pattern of maximizing “solo” time and minimizing collaboration time.

This is an anti-pattern because it screens out exactly the type of people you need on a product delivery team: collaborative co-creators and problem-solvers, as opposed to soloists who work best on their own and struggle with focused co-creation in a group setting.

When someone helps us navigate an unfamiliar space, they give us confidence and make our experience more enjoyable than if we tried doing it on our own.

Counteracting the Anti-pattern with Pairing

Let’s revisit how we can replay the earlier scenarios, but involve pairing so as to emphasize collaboration over independent work:

1. Dev environment setup: Instead of having the new team member do this on their own, pair them up with someone who has gone through the setup steps already. Use strong-style pairing with the new team member filling the role of Strong-Navigator — pairing up this way can expose comprehension gaps in the setup documentation. At the end of the session, reflect on and discuss how the dev environment setup process can be improved. Examples of questions to ask:
   1. Does the documentation need to be updated?
   2. Are there defunct libraries that can be removed?
   3. Can more of the process be scripted?

2. Grab something off the backlog: Instead of doing this, have the new team member pair up with other team members on actual items being worked on that week (or sprint). Strong-style pairing with the new team member filling the role of Typist can be effective here, as such an arrangement does not require for them to have any familiarity with the codebase beforehand. At the end of the pairing session, the pair can reflect on any gaps that the new team member may have, and how to address them (e.g. “I’ve never used Rails serializers, I’ll spend some time learning more about them”)

3. Poke around the codebase: Instead of setting vague expectations and telling the new team member to do this, plan for the whole team to work as an ensemble and include the new team member in the regular ensemble rotation. Ideally, the team is already spending some of its time working this way; if that is the case, the team can just ramp up on those sessions over the course of the new team member’s onboarding period.

What about Evaluation?

As mentioned, when a new person joins the team, there are typically two questions that the team finds itself asking about the new team member:

1. How do we ramp them up as quickly as possible?
2. How do we evaluate that they’re a fit for the team?

It’s not hard to see how a pairing-centric onboarding process will improve the first point. But what about the second? If we give them onboarding tasks to complete, we can evaluate their technical aptitude based on how well they complete those tasks. If they pair on everything, then completion of the task tells us next-to-nothing — for all we know, their pairing partner could’ve done all the work.

Technical evaluation is hard but often necessary.

Fortunately, there’s a straightforward solution to this. If you’re a lead who is tasked with evaluating whether the new team member is a good fit for the team, simply collect feedback from everyone with whom the newcomer has paired with since joining, and ensure that they have paired with every single team member. I find this to be a much more comprehensive and reliable way to evaluate the new team member than looking at how quickly they set up their development environment or looking at some initial “solo” work they completed for the team (that will likely need rework anyway).

Final Thoughts

Pair programming continues to be a grossly under-leveraged tool for product delivery teams. This tool can be effective at counteracting harmful anti-patterns that undermine a product delivery team’s collaborative capabilities. I’ve covered one such anti-pattern in this post; in subsequent posts I cover a few more. These include:

1. Heroism: how heroes can jeopardize a product delivery team’s long-term sustainability

2. Silo-ball: the tendency for silos across disciplines to emerge within product delivery teams, and how this creates unneeded bottlenecks that make the team more susceptible to spikes in cycle time

3. Async Fixation: when product delivery teams insist on only interacting asynchronously, leading to unnecessary increases in cycle time and shallow collaboration

I hope that the “(fend-for-your)self-onboarding” anti-pattern covered in this post has resonated with you; if not, perhaps one of the anti-patterns covered in future posts will resonate. Either way, I invite you to share your thoughts via LinkedIn.

Paul Sobocinski

Director of Engineering, Practice

As a Practice Director, Paul is responsible for elevating the technical excellence of the Software Engineering practices at Connected and beyond. He does so through coaching, writing, public speaking, and of course, coding.

Paul is currently interested in fostering professional growth through skills-based learning, with a particular focus on pair programming, test-driven development, and emergent design.

More Posts