Building Trust and Rapport as a New Manager in a Remote Async Team
I recently joined the Float team as the Director of Engineering. It’s been a whirlwind few weeks as I get to know the team, learn how things are done, and familiarize myself with what everyone is working on.
I previously spent over eight years at Buffer, another remote-first distributed team that emphasizes asynchronous communication, so thankfully, there's been no culture shock there. That said, there have been some significant differences and new processes that have made things interesting.
Read on to hear some of my thoughts on building rapport with a new team, balancing synchronous coordination while respecting individuals' time, navigating a new layer of management, and creating an environment of trust.
One of the most important aspects of being a manager is building a relationship with each teammate individually. Change can be scary, even more so when dealing with a whole new level of management and all the quirks and biases associated with that.
To start building those relationships early, I made sure to do a few things in particular:
A personal self-introduction
First, I followed the Float onboarding instructions closely, particularly the steps relating to introducing myself to the team and putting together a little get to know you page in Notion, where we maintain our evergreen documentation.
I could share some tiny part of my personality with these small actions and introduce the human behind the title. This is reinforced with our daily asynchronous standup reports, where we can share snippets of what we’ve been up to and are planning to do. I was immensely grateful to have such a solid framework at hand to ensure I didn't forget anything!
One-on-one first meets with each team member
Second, I made sure to meet with each member of the team for 30 minutes over Zoom. In this call, I introduced myself, shared more about my background and journey, and used the time to get to know each person a little better. Even though this only required 6 hours of my time in total, it was a busy couple of days, with an incredibly valuable (and somewhat overwhelming) amount of information to take in. I made copious notes during these calls and still find myself referring back to them weeks later.
During these calls, I also discovered that it’s definitely a small world! One of our engineers is from the same city in the UK as my wife and now lives on a farm only a few miles from where I used to live.
Another interesting observation was the extent to which the team really leans into the flexibility afforded by our asynchronous remote work. Several team members are early risers, a number are night owls, and a handful even split their day in two, taking a good chunk of time out during the day to do other things. I was delighted to hear this since it truly shows how the team lives by Float’s philosophy to work when you want.
I personally appreciate the flexibility to interrupt my day at odd times (usually due to some cat-related issue 😼), which is another point of commonality I found during these early conversations.
Setting up regular recurring check-ins
Following the initial 30-minute introductory call, I began arranging regular check-in calls with each member of the team. In my previous role, I had met with individuals every week for an hour each time. While that cadence worked well for a team of four whom I worked with closely each day, it’s not really feasible for a team of eleven who I won’t be working with as closely. I gave each person the choice of a bi-weekly meeting for 30 minutes or a monthly meeting for 60 minutes and ended up with a nice mix of the two.
You might be wondering if it’s really necessary to take the time to have these check-in calls at all? Especially on an asynchronous team, couldn't they happen via Slack or another tool to allow async communication to continue?
- My regular day-to-day interactions with engineers tend to be relatively fleeting, so there isn’t the opportunity for them (or me) to have the complete focus of the other for any length of time. Having that chunk of time allows us to build a relationship much faster than we would otherwise be able to strictly asynchronously.
- Having a regular check-in scheduled means I’m not beholden to the randomness of fate and can ensure I don’t neglect someone on the team. As time goes on, we absolutely will re-evaluate this, and if some engineers would prefer a more asynchronous check-in, that’s what we’ll do. I also want to hear people’s honest, unfiltered opinions on things. I see it as a crucial part of my role to get a pulse of the team and these interactions are my best opportunity to hear what’s going on and how people are being affected by decisions.
It’s still early days, but so far, this strategy has been working well, and I have thoroughly enjoyed getting to know each member of the engineering team a bit better.
Time is a precious commodity. We can never have too much, and once it’s gone, it’s gone forever. At Float, time is sacrosanct—we value providing our team the ability to focus and have the uninterrupted time they need to do their best work.
Nonetheless, as a manager new to the team, I know the importance of getting to know everyone and creating an environment of trust. It’s not something that happens overnight, but it can be developed faster with actual face time.
Booking meetings at the beginning or end of someone’s day
When I set out to arrange calls with the team, I made sure to respect their time. This often meant scheduling meetings near the beginning or end of their days, regardless of when it was for me. Keeping meetings towards the boundaries of the work day minimizes the number of context switches down to zero (ideally) since there is no move from one focus period to another.
Time zones are something of a blessing and a curse in this regard. They are a blessing in that it means there are multiple “first thing on a Monday” or “last thing on a Friday” slots available due to the geographical distribution of the team. On the other hand, when you have people that are literally on the other side of the world, there has to be a bit of compromise to ensure that the time is acceptable to them. As the manager, I feel this is one of my duties, so I have the occasional early morning meeting as a result!
Providing meeting time options so the team can choose when they work best
As I mentioned, I come from an environment where hourly weekly calls between a manager and their individual team members were the norm. That worked well with a smaller team but is less than ideal for a group of our size. Giving the option of more frequent (and shorter) or less frequent (and longer) meetings allows the engineers to self-select their interactions with me. These calls are intended to be driven by each team member and mainly for their benefit, so I’m in favor of it. I prefer this management style of servant leadership, where my goal is to enable my team to do their best work.
One definite risk of these regular check-ins is that after the initial burst of enthusiasm and sharing all the great ideas in the first few weeks, the meetings start to gravitate towards regular project updates. That has happened to me in the past and signals that the calls are either too frequent, too long, or that I am working too closely with an individual. If that starts to happen, I try to make sure we recognize it and then steer the conversation to the bigger picture items—like a project's goals and objectives rather than the daily nitty-gritty.
If nothing needs to be discussed, then it's ok to skip the call or re-evaluate their frequency/length. Likewise, we can increase the frequency if we discover that things are moving fast and a monthly call feels too infrequent. This ebb and flow of meetings feel natural to me, as each individual has periods of rapid change and periods of calm, and it makes sense to reflect that change in energy in the cadence of the calls.
Ultimately, I want to provide a safe and welcoming environment for team members to share their thoughts while negligibly impacting their regular day-to-day work.
Individual contributions are naturally visible to all in an organization with a flat hierarchy and a relatively small team size. In particular, the executive team is aware of who’s doing what and who’s doing well.
As soon as a new layer of hierarchy is introduced (i.e., my role), there is a real risk of that visibility disappearing and people’s work not appearing to be recognized at the higher levels of the company as a result. I see a big part of my job as the cheerleader and general loudspeaker for the excellent work that people do—particularly when that work is behind the scenes and may not be visible.
Regular acknowledgment of the small and consistent wins
This is relatively challenging since it takes a bit of time to understand what everyone does and give people time to achieve something noteworthy. So I keep notes of little things I notice, and even if they’re not broadcast-worthy, I do my best to recognize them in private with a quick Slack message or mention them in our regular check-in calls.
Acknowledging good work (however small) is never a waste of time. It shows that a person’s work is valued and recognized by myself and others.
Ensuring transparency within the hierarchy
Within the engineering team, we have several larger projects on the go right now, and I’m looking forward to recognizing the value that each team member brings to seeing them through to completion. The Float team is still relatively small, and engineers work directly with our co-founder & CTO, Lars, in particular, so I don't feel there is too much danger of talent and effort going unnoticed in the short term.
As we continue to grow, this could become more of an issue, but by then, I feel I'll be more in tune and able to help highlight all the incredible work that gets done with each passing week.
Trust is everything in a well-functioning organization. With trust, we can be open and honest about the successes and failures we encounter. We trust each other to do our best and to make the best decisions possible given the circumstances. We trust that we will be treated fairly, and in turn, others trust that we will treat them fairly.
When we have trust, we are more comfortable having tougher conversations. Conversations about how we could have done better. Conversations about what isn’t working. Healthy discussions where we can disagree.
Given the importance of trust, how can a newcomer to a team, particularly one in a leadership role, start building trust?
Earning trust starts with listening
My approach is to start small and not come in with guns blazing, looking to make sweeping changes. Listen first, observe, and then listen some more.
Firstly, this helps to get to know the lay of the land—how things work, how work gets done, and who does what. Secondly, it gives the team a chance to get familiar with me and hopefully start to get a feel for my personality, sense of humor, things that I am generally in favor of, and what I try and avoid.
A shared quick win builds confidence
The dream is to have a quick win, and I was lucky enough to find one in a weekly check-in call. One of the first things I noticed when I came on board was an 11 p.m. (UK time) recurring weekly call across the product and engineering teams.
Given the geographical distribution of the Float team, this was early morning for our Australia & New Zealand-based team members and late afternoon for those in the US and Canada. However, it was quite literally the middle of the night for our Europe, Africa, and Asia-based team members!
It is all too easy to blur the lines between work and life when we work remotely. Some flexibility is important, but to me, an 11 p.m. call was a bit much, and I wanted to see what we could do to make things more amenable to everyone on the call.
The first thing I did was test the waters in my introductory calls with the engineers to see how they felt about changing the call time. One engineer even mentioned in passing that they would likely shift their day by a few hours if they didn’t need to attend such a call! That was all the impetus I needed, and I was determined to find some way to make the change work.
Fortunately, the Float team was very receptive. The weekly meeting had already been reduced from twice-weekly to once-a-week due to its untimely nature. Plus, the engineering team, in particular, has had several new hires over the last year or so and has gained a much more significant foothold in the UTC to UTC+5 time zones. The time was ripe to make a change, so we removed the recurring meeting with a resolution and agreement to ensure our asynchronous tools were up to date and to have the discussions there.
It is a small change, and honestly, it would probably have happened on its own eventually. However, by focusing on it and seeing it through, I hope it showed that I am on my team’s side—both to be their champion and to let them know that they can trust me to do what is right and necessary.
It’s only one change and early days, but it should set the standard, both for the team and myself. I want to hear about more of these kinds of things, and I am willing and able to get things done about them!
Trust goes both ways
In a remote asynchronous working environment, trust is key. Team members need to be trusted to work independently and to make good decisions. A team also needs to be able to trust that their manager has their best interests at heart. To build that relationship and create that bond of trust as a new manager, you need to make an effort and be deliberate in your actions.
Talking candidly to team members and being honest requires knowing how individuals think, what motivates them, and what inspires them. Taking the time to build a relationship where both people can be real with each other reduces the possibility of misunderstanding and allows the individual, the manager, and the team to all thrive.
It takes time and effort, and it isn’t necessarily easy, but I believe the benefits are clear. By putting in the work, you can create an environment where everyone can flourish and truly live their best work life.
Get exclusive monthly updates on the best tools and productivity tips for asynchronous remote work
Join 100,000+ readers globally