How to set the right expectations with your remote team that lead to successful projects and long-term stability.



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.


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.


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.


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.


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.


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.

For some development managers, “done” means:

  • Code review complete
  • Deployed
  • QA performed
  • Demo to product owner and get approval

For the product team, “done” might mean:

  • On production and perfectly working

In comparison, for some developers, “done” simply means:

  • Committed and pushed code

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.


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.

To give you some examples of core values that work well in remote teams, here are the core values we have adopted at X-Team:

  • Take ownership

    Take end-to-end ownership of every project you take on and show that you truly care about the outcome every time. Do not cut corners; instead, focus on long-term quality through test coverage, documentation, etc.

  • Be proactive

    Be someone who does not need their hand held, someone who always keeps moving forward, someone who does not wait for that next ticket to get assigned to you; when you see a potential for improvement in the project you are working on or a new feature comes to your mind, you are the first to reach out, propose it, fix it, and do it. You are in control.

    Do not just ask a question and leave it — propose a solution in the meantime, code something alternative that could solve the issue, show that you are proactive beyond the obstacles of being remote.

  • Be open to learning

    We all love technology, but that does not mean we have to be that “I only do PHP/JS/Java” developer. We appreciate being open and adaptable to solve any given task, no matter the technologies and obstacles that we are given. Every opportunity we are given is an opportunity to learn and unleash our potential in new ways.

    Be hungry for more knowledge and expertise. Improve your skills and craft through courses, lectures, going to meetups and conferences. Keep the saw sharp. This industry is constantly changing, and only those who change alongside it will have the most rewarding careers.

  • Actively communicate

    Make yourself visible and present every day by keeping your team up to date with your progress throughout your day. Use techniques like journaling to share knowledge, ideas and progress.

    Trust is not built by going silent for a week while you are deep in progress on your work — you build trust that you are meeting expectations by showing your output, however you can, every day.

  • Be compassionate

    Always consider the perspectives of your teammates. You work alongside people from various cultures, backgrounds, genders, countries, etc., and it is important to be mindful and respectful at all times. Use this unique opportunity to embrace a spirit of generosity by sharing your perspective and being open and welcoming to the perspectives of your peers.

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.


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.


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.)


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.


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.


  • because you set expectations from day 1,
  • because you agreed with them on quarterly goals,
  • because you gave them constant feedback when expectations were not met,
  • because you understood their expectations and did your best to meet them,
  • and because you gave them an opportunity to improve and rise to the occasion... 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.


Scale your
development team

We help you execute projects by providing trusted trusted developers who can join your team and immediately start delivering high-quality code.

Hire Developers