Management

A GAME OF EXPECTATIONS

A remote team is much different than an office because of one sole reason: your value to the company and trust with your team are based entirely on your output. It does not matter where you work from or how you get it done, all that matters is that work gets done and at the level of quality that is expected of you.

For that reason, remote team management is, in theory, quite simple compared to an office environment: set expectations around output, attitude, and respect, keep them motivated and growing, and make sure they are delivering.

A lot of the politics that come with an office environment — from who sits where to who goes to lunch with whom — is irrelevant. It is entirely a game of setting expectations and delivering motivation.

Below we dive into setting the right expectations for remote teams and then in Chapter 4: Culture, we will dive into delivering motivation remotely.

SET THE RIGHT EXPECTATIONS

If you want to successfully manage a remote development team, this is the #1 key to it all: setting the right expectations.

Despite how easy it sounds, it is often overlooked. We have worked with many companies over the years that had not taken the time to set expectations with their own teams, making it challenging to understand upfront what success would look like for them once our developers joined their team. We often help companies to learn what their expectations are and to set them in place with all of their vendors and teams.

As long as you set the right expectations around availability, output, attitude, communication, etc., your remote team will thrive for many years (we have passed the decade mark now using this strategy).

However, keep in mind: this is a two-way street.

As much as you need them to meet your expectations to be successful, they also need you to meet their expectations to be successful.

That means they also have expectations around how you communicate with them, what your availability is, how you respect their flexibility, the opportunities for learning and growth they expect, etc.

IT STARTS WITH ONBOARDING

Setting expectations begins with your onboarding process. From day one (not day 60), your developers should be starting to learn and understand what you expect of them.

They might not perfectly execute those expectations in the first week, but over the course of a month, you will quickly come to learn whether your newly hired developer understands those expectations and can deliver on them.

Tip: Try to break up your onboarding across a two-week period.

We use those two weeks to introduce new developers to our core values, train them on critical remote communication techniques, and clearly express our expectations.

Each day, they learn just one piece of our “expectations puzzle” (so to speak), easing them into it to make sure they retain the information.

Tip: Use this opportunity to start meeting their expectations.

Remember: we need to know their expectations, too, and this is a great opportunity to revisit those expectations and to start building some trust by meeting them.

For example, if one of their expectations is around learning and growth opportunities, now is a great opportunity to start showing them how you will be delivering on that expectation and start them on that path.

Alternatively, if one of their expectations is that the team gives you ownership of your work, within the first two weeks, you should give them a task with full ownership.

Give them momentum by meeting their expectations, the same way you want them to gain momentum on your projects and meet your expectations.

Next, we will cover all of the different expectations you should set in your onboarding process.

AVAILABILITY EXPECTATIONS

More important than anything with remote teams, remember this: anyone who joins a remote team prioritizes flexibility first.

So before you go and ask them to do 3 a.m. calls for you 3-5 times/week, or to always be online checking Slack, you first need to understand their expectations around flexibility.

Some people are fine with 3 a.m. calls 5 times/week — for them, that might mean flexibility because it allows them to be with family the rest of the day.

This is why you need to understand their expectations first before you set your own expectations for them. All of these expectations are meant to set them up for success on your team, but they also make it clear what is going to help them stay on your team.

Tip: Set timezone overlap expectations

Sometimes it is tough to move things forward fast enough without some level of timezone overlap between you and your team.

If you find that without that overlap your momentum is being held back, consider setting an expectation for a couple of hours per day where you can overlap with your team and better explain requirements, answer questions, and unblock blockers.

It is worth noting, however, that the only justifiable need for this is either during a tight deadline or because the team is not writing/presenting detailed enough messages and documentation to one another. This is another great reason to prioritize solid documentation and requirements writing in your team.

Tip: Collect your team’s cell phone numbers.

We have learned from enough tight deadline projects that it is critical to have the cell phone numbers of all of your remote developers.

Sometimes Slack notifications do not come through (or are turned off), or a developer might go completely MIA only for you to discover they are in the hospital — regardless of the use case, having their cell phone number can make/break a project.

EQUIPMENT EXPECTATIONS

It does not matter how available you make yourself if you do not have a working laptop to work from.

Set clear expectations around equipment (and whether you will be providing it or not) so that it is clear that you warned them about the importance of having a stable laptop during a crunch period.

On top of that, set expectations around connectivity. If you expect them to be able to join Google Hangouts with clear quality, they need to know that expectation so that they come prepared to each call with a solid connection and a decent microphone.

COMPLETED WORK EXPECTATIONS

Another often overlooked expectation with remote development teams is a solid, clear definition of what “done” means.

In an office environment, you can oftentimes get away without this definition when everyone comes together in a conference room and hashes out the completeness of any given requirement.

In a remote team, all that matters is the requirements and whether they have been properly met. No one can hear you at the conference room table mentioning that you are “still working on this piece and that piece” — all they know is whether what they wanted is in front of them and done properly or not.

Without setting the right expectation of what “done” means from the start, a developer is going to join your team using whatever definition they are used to — which is almost never the same definition that you and your product team have.

In just those three different perspectives, there are massive differences, and without those expectations being understood upfront between all parties, everyone is headed toward disappointment and damaging their trust.

You are much more likely to have some empathy for incompleteness when the person is directly in front of you. Remotely, all that you care about is whether your definition of done has been met.

Come up with a definition of done (ideally something similar to the first example), set the expectation with your team (and product team), and continuously give feedback and correct anyone who does not meet that expectation until the behavior sticks.

SET CORE VALUES

With any team, you are bound to have some overachievers who go above and beyond your base expectations, but for everyone else, you need a set of core values and baseline expectations that must be met for you to be satisfied, for the team to work well together and for the company to succeed.

These core values set an expectation with all of our developers to take ownership of their work, to be proactive and keep projects moving forward, to keep their skills sharp by always learning, to actively communicate and to be respectful and compassionate by embracing a spirit of generosity.

These baseline expectations have led us to a decade of successful projects with our remote development teams.

QUARTERLY GOALS EXPECTATIONS

Although not applicable to all teams, in some cases you will want to set quarterly or at least high-level, project-based goals with each of your developers in order to keep an ongoing conversation around expectations.

It also allows you to revisit the topic of expectations after major milestones in case there is a need for adjustments based on their performance.

Once again, this applies both ways — these quarterly goals should meet both your expectations around output and delivery, as well as their own expectations around growth, ownership, etc.

Once both you and your developer have agreed upon the expectations for each quarter or project, make sure you have monthly check-ins to look at progress and make adjustments.

DELEGATE AUTHORITY

Another key to a successful remote team is delegating authority as much as possible.

Once you have hired strong, independent remote developers, you need them to be able to keep moving forward once you are offline, and the only way to achieve that is by giving them the authority to do so.

The more bottlenecks you create, the slower the momentum of your remote team. Keep in mind, a bottleneck in an asynchronous remote team spread across multiple timezones is exponentially more damaging to momentum than it is in a real-time office.

Monitor Loneliness

You need to be aware of the fact that loneliness is a real challenge with remote workers and one that should be taken seriously.

A developer's performance can be greatly impacted by loneliness and if you're not creating opportunities for your team to connect online and in-person, the mental health impact can take its toll on productivity, attitude, satisfaction and more.

The best way to monitor loneliness is to talk with your team individually to check in often on their mental health and offer support and solutions (sponsored coworking membership, etc.)

DELIVER CONSTANT FEEDBACK

Rather than get upset when a developer fails to meet expectations, use it as a learning opportunity for them.

Rather than use an upset tone, such as: “This wasn’t done properly. QA should have been done.”

Consider instead saying, “Just wanted to point out some feedback — for the future, can you do a front-end QA pass-through before sending it over? Appreciate it :)”

Tip: Give praise when they meet expectations.

The best way to train your team to consistently meet expectations is to praise them when they do the right behaviors.

If you see them achieve one of your expectations, send a quick message praising them for it. Keep it simple and do it a few times to make sure they know you appreciate it.

Continue to give this constant, consistent feedback, and your team will very quickly start to understand and feel good about your expectations.

This also comes in handy for the next section.

SAYING GOODBYE

Sometimes, you will hire a developer who simply cannot seem to grasp the expectations you have set. Sometimes it is cultural, other times it is simply laziness.

...it should never be a difficult decision when letting someone go from your team who is consistently not meeting expectations.

Managing a remote team is not meant to be difficult — it is quite clear-cut once you define your expectations and enforce them.

Just remember: Set expectations, understand their expectations, and do what needs to be done to keep everyone aligned.