Teams that speak to each other: A good habit in every nook

One of the more nuanced parts of management is the integration of new team members into an existing team. Beyond the standard processes in the first couple of weeks and months, getting your new report actually feeling like they’re part of a team can be challenging.

Specifically, it can be challenging to have new members feel confident with giving & receiving feedback, especially if they’re newer into their careers, or part of an underrepresented community.

In this post, I explore how we as managers can take typical, routine processes and use them as a space to foster healthy conversation, collaboration, and a sense of place.

Encourage and lead with good habits from the get-go

In your first conversations with your report, you’re likely to ask the following question: “What do you want to accomplish this week? This month?”

And with a gleeful smile, the engineer will state: “Deploy. Do my first deploy by the end of this week”. To kick off my point, let’s walk through an example which demonstrates an opportunity to immediately enable a good habit.

The task: Adjust log level of application from warning to error in production

At a glance, this is a straight forward task. We can assume there’s a change in a settings file within our application, perhaps an environment configuration. There may be a specific file for production settings. Deploying to production is a likely necessary final step.

If you have it, you should point your engineer to your team’s Getting Started guide, which outlines your branching strategy, code review process, and operations of deployment. Don’t have them? Now’s a good time to take note and advocate for time to create these — take note and remind yourself to do that later.

As they go through the task and review your documentation, they may find areas lacking in clarity. Was it clear to them how settings for each environment are structured? How about deploying to production?

As a manager who wants to do best for their team, your reaction may be to unblock your report by amending documentation as they go. A manager who can get their hands dirty is respected by the team, after all.

But hold on. I’m not going to say this is wrong — and please, use your best judgement. If you have no documentation, it’s up to you to be that champion — but there’s a better way.

Please enable your new team member to contribute to your documentation. Have them amend the Getting Started guide with clarification in the areas they got stuck. Work with them towards the appropriate amendments. Point them to the repository containing your docs, show them how to build them locally, and how to contribute to them.

Again, if you’re feeling behind on documentation, begin advocating for that time now!

By approaching it this way, you’ve:

  • Highlighted to your report how important documentation is. It’s not something left behind for “when we have time”

  • Shown them those initial signs of trust. Psychological safety is something you’ll build today and continue building throughout your time together.

  • Improved their sense of belonging within this new-to-them team.

They’ll wrap up that initial task, submit a pull request for that documentation (likely with some back and forth with you, that’s great!), and continue into their next set of tasks.

Consider how much I’ve promoted a conversation between two humans here. In this example, it was between report and manager. As time passes, that collaboration must extend to the entire team, and as a manager, you can enable this in a safe way for your report.

Enabling collaboration can reduce anxiety, build trust, and improve one’s sense of belonging

How do engineers collaborate?

  • Pair programming

  • Pull Requests

  • Estimating task points during replenishment / backlog grooming

  • Discussion ideas, issues, architectural improvements, retrospective thoughts.

  • Outside of any particular routine or process (hanging out in a common area)

Consider the documentation scenario laid out above. This was a request outside of the groomed backlog and this created a conversation between myself and the engineer. “Do you want me to create that task in Jira?”, “Sure, here’s how … “

Providing your new report a collection of small (1-3 point) tasks is a great way to kick things off, but look for how you can enable a healthy level of friction in those first few weeks as well.

I use the word healthy here, just as I pointedly used the phrase “[…] collaboration can reduce anxiety, …”. Setting your report up to fail by giving them a task with a high level of uncertainty or incorrect functional requirements is how we can harm the psychological safety we’re trying to build in the first place!

Consider a task which requires the creation of a new Autocomplete component. This task will require them to identify the idiomatic approach (for your framework/language) to solving this problem, while ensuring it adopts the styles already within our code base.

The engineer may choose an open source Autocomplete component that differs from the one another engineer would have used. The team may not have a particular style for where these types of components live.

This is healthy friction. It enables collaboration. The pull request will be submitted and after review, they may rewrite the pull request with a different Autocomplete component. The engineer may have asked about Autocomplete component opinions well ahead of making the pull request. Your team may now have a defined approach to storing these components, and it’s O.K if they don’t settle on that in that pull request (out of scope!)

Imagine the amount of conversations which can occur from this one scenario. Growth of your engineering team is not a bunch of disconnected nodes growing independently from each other! The more they bounce between each other, the more effective they’ll be together, and the stronger their sense of belonging.

You may have to lead discussion often, especially in teams which aren’t mature in their communication. But know when to step back and give space and time. You’ll learn how to provide that space, and it doesn’t have to be an explicit action (“Can y’all figure it out?”) With enough effort put up front, your team will see the environment you’re fostering. One rich with discussion, receiving & giving feedback. You’re building a safe place to collaborate.

Discussions can become tense at times. This will happen. Use your 1:1’s as a time to actively listen with an intent to be better — together — going forward. Provide direct, individual feedback. Remember, a team learns through adversity as well. If there’s no friction and everyone is always agreeing, you are missing an immense opportunity to improve that team dynamic.

Consider the landscape of a given task as a place to start, and allow the psychological safety you’ve built here to branch out into other areas of function — retrospectives, architectural discussions, task estimates, all the areas I listed off above and more.

When your team is speaking to each other, their collective sense of belonging grows

I hope by this point you have a sense of how many opportunities you have as a manager to promote conversation between the team. How you interact will come in many forms — video, in-person, written — and they all provide their own avenues in promoting healthy discourse.

As a manager, you have the opportunity to build good team habits early. Find opportunities to do this often, and know when to step back and let the team figure it out, adjusting course as you need. Your team will go through its challenges, but having broken down communication barriers, your team will be that much more resilient in beating that adversity and getting back to solving your team’s common, unified goal.