
Ask HN: As managers, how do you make sure your distributed team is aligned? - type12
We use Slack for internal comms, but it&#x27;s used mostly for chit-chat conversations and real-time issues. Is there a product for slow-thinking updates where I can share teams news and align my +40 people team? How can you be sure people don&#x27;t actually miss things in the noise of Slack&#x2F;Email?
======
gwbas1c
When I worked for Intel, we all went through training on how to run effective
meetings.

Why? In a distributed team, meetings can become a severe time sink. A lot of
people hold meetings to feel busy and important, and even less people put in
effort to keep the conversation focused so that the meeting ends on time.

Some basic things are:

\- Determine an agenda in advance. The agenda must be part of the meeting
invite. An agenda is more than "Talk about XXX." You should have a list of 3-6
topics that will be discussed in the meeting.

\- Make sure that everyone on the invite list needs to be there. Explain why
you're inviting people in the meeting invite.

\- During the meeting, make sure that, as time progresses, the topics on the
agenda are discussed. If one topic is discussed too long, there's different
techniques for moving to another topic. (Binning it, declaring it a rathole,
ect.)

\- Decline poorly planned meetings.

And, I shouldn't need to say this, but meetings begin on time and end on time.
Don't make everyone wait 45 minutes to start what's supposed to be a 30 minute
meeting, but then it really drags out to 90 minutes.

Furthermore, have a 0-tolerance policy for latecomers and people who always
need 15 minutes to figure out the teleconference software. Hold your
interviews in the teleconference software you use with your team as a way to
filter out the idiots.

~~~
mandeepj
> 15 minutes to figure out the teleconference software

We just Skype for Business and Zoom at work. Both are just one click. Webex is
also good. It's little confusing though (too many options). My partners use it
so I have to also use it.

Maybe, you need to evaluate your teleconf s\w.

~~~
gwbas1c
I don't know why people are downvoting you.

There are idiots who constantly take 15 minutes to figure out those
teleconference software. Each and every time. I can understand taking 3-5
minutes extra the first time using something like that, and I can understand
occasional technical difficulties.

What's not acceptable is after 2 calls still having technical difficulties.

For example, A year ago I started working with a driver developer who would
constantly drop out of the teleconference after 7 minutes, without a polite
"technical difficulties" IM or email. Turns out he was always calling in from
within some kind of VM and always needed to reboot in the middle of the
meeting. We had to get the manager to tell him to stop it.

Another example is that, a few days ago, I interviewed someone through WebEx.
She took 10 minutes to figure out how to get her microphone to work. After 5
minutes I made up my mind that, unless she was spectacular, I wasn't going to
hire her. (She interviewed very poorly.) What's extremely frustrating is that
she didn't have the decency to just have WebEx call her phone, and instead
kept me waiting for 10 minutes. That's just plain rude.

~~~
jnurmine
Maybe it is a tool issue?

For example, if developers using Linux are asked to teleconference using tools
built solely with Windows in mind, sometimes it will work with a VM, but often
it randomly doesn't.

If I remember right, Intel used Skype for Business which as a teleconferencing
tool was just rubbish. (Maybe it still is?)

------
jrhusney
> Is there a product for slow-thinking updates?

I've been working on a distributed team for 4 years now. I product manage an
open-source online retrospective and meeting app and went _way_ deep on
researching other distributed teams last year. What I learned about sharing
updates is it's as much dictated by culture and ritual as much as it is by a
tool.

Zapier is almost 1,000 people now. Here's what I learned they do:

\- Every Friday non-managers write a short update of what's changed that week

\- Managers read them, extract a few highlights, and roll them up to leaders

\- Leaders do the same and roll it up to the CEO

\- The CEO writes a blog post and sends it to the entire company

\- That post is commented on and questions are asked by everybody

Some folks within Spotify write a daily update answering the same prompts:

\- This is what I did today I think you should know about

\- This is what I learned and I think you'd find useful

\- This is what I need from you

\- This is what I am doing next

For our company, we prefer weekly updates to daily updates (we value time
autonomy vs. having an always-on culture). Our fully-remote team foes
something similar to Zapier and end up posting our company updates publicly at
[https://focus.parabol.co](https://focus.parabol.co) (if you want to see an
example)

I don't think a separate tool is really necessary. Pick your poison between a
stand-up bot or something more flexible like missions.ai (at time X create
doc, share doc, prompt people to get started...)

One more tip: if you find yourself writing an answer to the prompt "this is
what I need from you..." you probably have an item to add to the team's
meeting agenda. Full disclosure, we started our company to make capturing
items for meetings easy, so, I have a dog in the hunt.

EDIT: formatting

------
james_at_plaid
At Plaid, I'm in a unique situation where I manage a division of the
engineering team which is dedicated to being distributed; the rest of
engineering team is not. My goal is to ensure not only that my team is
aligned, but also that important information is flowing between my team and
the rest of the company.

For this, I use a weekly update that's sent to the team and also the
"periphery" of the team -- all those who care about and influence the team's
success. Each weekly update is prepended to a Google doc, and I send an email
out (just with a link to the doc) when I update it.

The update has three sections: "Last Week" (everything I experienced last week
that I think is relevant) "This Week" (a list of my priorities for the
upcoming week with a cut line) and "Biggest Mistakes and Missed Opportunities"
(just what it sounds like). It's intended to be comprehensive and often runs
more than one page.

To make sure "people don't actually miss things," there are two parts: 1) I
make sure the update contains all the things I don't want people to miss 2) I
make sure the weekly update is valuable enough to everyone so that they read
it.

On occasions where I've been late in updating it, I've found that I'm
repeating the same information to multiple people more often and also having
to say, "Sorry, you'd have known that already if I'd gotten my update out on
time."

------
sz4kerto
First of all, make sure that the management itself is aligned. Patterns
reproduce themselves across the organization and that process is mostly
top->down.

Have your most important values written down. Technical and non-technical. Ask
new joiners read them and refer to them when discussing short and long term
plans.

Don't believe that a fully flat hierarchy is the solution for all problems. A
distributed team makes communication harder, so you might need more process
than usual -- for 40 people you almost certainly need other managers to help
you.

Have a strategy for the corporation that everyone understands. Team leads will
then understand what their team has to contribute, and individuals will
understand how to contribute to the team. If the company strategy is not well-
known, your remote team is doomed.

Focus on alignment to values and vision, not to what you tell people directly.
You're doing your job well if people and teams become autonomous.

Find and remove anything that blocks lateral communication (i.e. that goes
outside of the hierarchy chain).

Be skilled in people management. Recognize isolation, burnout, depression,
tension early enough and be able to solve them. If you are not skilled, learn
from professionals, not from blog posts.

If needed, break rules. An important rule in a distributed team is that people
don't meet often. If necessary, break this rule.

------
d0m
Usually, one manager/lead take care of 3-7 people. So rather than making
everyone on the same page, I'd spend more time with these leads and making
sure that you guys are on the same page, and it will percolate down to the
rest of the team. On top of that, well written document with clear goals and
high-level strategies help to re-inforce it amongst everyone, but imho it
should still be the mid-level manager's job to communicate in 1:1 and in other
ways to their team.

------
jedberg
> Is there a product for slow-thinking updates where I can share teams news
> and align my +40 people team?

Email. Email is perfect for this. If you use GSuite, groups with the email
gateway is ideal for this. You can have threaded discussions with a long
history.

Stripe was(maybe still is?) really good at this. They made a policy very early
on that every email had to CC a mailing list (unless it was truly a personal
one on one communication). The lists has a structure were some were designated
as archival only. Even if no one read the list, at least the archive was there
for the new employees. Or for an employee who was on vacation to read and
catch up when they came back.

> How can you be sure people don't actually miss things in the noise of
> Slack/Email?

For Slack, make sure it's truly just for real time discussion. If something
looks like it's going to be a long discussion, move it to email.

For email, if you're using groups/lists for everything, then there shouldn't
be a lot of noise. You should be able to just go to the groups interface or
filter on the group the message was sent to.

~~~
codemac
Email is great, along with keeping a google doc of all previous updates sent
in reverse order.

Then author the email in the google doc, paste it into gmail and send - along
with a link at the bottom to previous notes.

~~~
james_at_plaid
Because I want to encourage comments/questions, I do almost what you describe,
except that the email ONLY contains a link to the doc. So in effect, the email
is just a notification that the doc has been updated.

~~~
codemac
I don't do that because then you're just giving the reader more work to do.

Is there an unseen advantage to not including the actual text in the email?

------
fhbdukfrh
I think some touch on this but you cannot possibly align 40+ people directly.
If these are all devs, at this scale you need 3-4 engineering managers or 5+
leads. That's were you should be focusing and empower them to carry your
message outward.

Looking for a tool to do this is wishful thinking

------
ManuelHeL
One key aspect is a single source of truth. A place/tool were all processes,
requirements and relevant Q&A are open for the whole team, with no gray areas.
Use any kind of methodology, but try to keep your team informed about how the
general rules of communication and collaboration work.

Split communication in small teams/groups and design just one person per group
to deliver periodic status. Meeting with the whole team are absolutely
inefficient and costly for the company.

Create a policy where any change must be documented and informed to all
stakeholders.

Tools vary depending on your business, but sites like Trello can be really
usefull.

------
imroot
I've managed a team of 30+ -- both on-shore and off-shore resources -- and I
can tell you some of the things that I've liked, and some things that I hated.

I have been in consulting for a while -- and while I don't mind it, that
brings in its own set of rules (with regards to non-billable time) and
challenges (Fixed price contracts usually mean low salaried workers to
maximize profits).

\- Short team-based standups. There's no reason for your US team to meet with
Offshore unless there's a blocking reason to do so.

\- Bi-weekly team meetings with both groups. I tried to alternate between the
On-Shore and the Off Shore's lunch period, but, regardless, one team is
staying up late. Don't be a dick and make that team come in at their same time
the next day if you're holding a 2AM meeting that lasts an hour.

\- If you are sending important, team-wide, communications, let them know in
stand up.

\- I have no problem waking up early (or staying up late) to have 1:1's with
my team, even if they _are_ offshore. Keep them simple (What have been your
big challenges this week? Are you blocked or do you forsee any roadblocks down
the horizon? Do you have anything for me?)

Sadly, most companies that we've been in have frowned upon Slack, but, I don't
have any issues in using it on a daily basis.

If your team members are burned out, isolated, depressed -- work on them. Give
them time away from the project or lighter work (to a point). If they are
consistently burned out and depressed, try to figure out if this is a
company/project/management issue (hey -- I'm far from perfect, maybe they
don't like my management style!), or, if this is something that can be
resolved by a placement to a different project/team.

Encourage them to use the 'free' resources available to them -- be it cloud
services, books, education, mental health, physical health, etc. The company
provides those for a reason.

It took me a long time to realize that my initial management style doesn't
work with everyone...so, I changed. Don't be afraid to look in the mirror and
change your operating style when you think it's not working.

(edited for formatting)

------
cowpig
We're not quite that size yet, but I've found that carefully curating our
organizational culture has really paid off, starting with a document of
principles[1] that we all agree with, and then on putting a lot of mental
effort into training new hires to understand what the culture means and why
it's important.

[1]
[https://gist.github.com/cowpig/8d8194ac55e3789d9a3c4136d1e1a...](https://gist.github.com/cowpig/8d8194ac55e3789d9a3c4136d1e1abad)

~~~
gtirloni
Oh, this is really nice! Did you use a process to have everybody agree on it?
I usually struggle with top-down where some people disagree and work against
it vs. bottom-up where consensus is really hard and nothing is done/decided.

------
koudos
From a tools/infrastructure support perspective, standardizing on tools and
clearly declaring and assigning a single tool for each function. Clearly ask
people to pitch in to adhere to this. Set clear standards for yourselves.

From a people perspective, clearly defining goals and constantly asking
clarity questions to gauge if there is alignment is the only real way. Also if
you notice people are not aligned but they think they are, declare that you're
not sure they're aligned. They'll hash it out themselves.

It also helps for people to declare when they're unavailable in something like
a slack channel. Finding out someone is not there when you expect the to be is
very jarring/frustrating.

------
jfasi
Are you personally managing 40+ people, or are you a director with a layer of
managers beneath you? I can't imagine how stressful it must be personally to
manage 20 people, never mind 40...

------
speedplane
> We use Slack for internal comms, but it's used mostly for chit-chat
> conversations and real-time issues. Is there a product for slow-thinking
> updates where I can share teams news and align my +40 people team?

With distributed teams, I don't think communicating big vision ideas are all
that difficult. They can usually be solved with a monthly all-hands.

The problem with distributed teams is the lack of informal interactions. When
you come up with a seed of an idea, that may well be a bad idea or isn't
thoroughly formulated, it's an immense help to walk over to someone's desk and
run it by them.

Slack and email are poor tools for this type of early innovation because they
require you to write your idea down. At the very early stages of innovation,
you may not even have a clear enough vision of the solution (or the problem
it's trying to solve), to commit it to writing.

Most of these early ideas are originally flawed or down-right incorrect, but
low-risk informal chats with co-workers can help crystalize or disprove the
idea far more efficiently than any written medium.

~~~
mac01021
I'm not convinced that an idea (or a seed thereof) that is not formed well
enough to be written down is ready for discussion with another person.

An idea that has navigated through the internal dialogue I have to engage in
to put it to paper is much less a waste of your time.

And, if you want me to provide well thought-out feedback on your idea, don't
ask me to respond to it in real time or in the timeframe of a meeting.

The ideal process for ideation may be informal and low-risk, but it is also
asynchronous and via the written word (possibly with pictures).

Write down whatever you can about your problem or your idea and then send it
to me, saying "what do you think?". I will read it at the time when I am most
able to give it my full attention, cogitate for as long as I think necessary,
and then reply with the best possible feedback.

Maybe some cases benefit from the rapid iteration that can happen in an oral
conversation. But in my experience, most or all of those work just about as
well with a rubber duck.

~~~
speedplane
> I'm not convinced that an idea (or a seed thereof) that is not formed well
> enough to be written down is ready for discussion with another person. ...
> Write down whatever you can about your problem ... then send it to me,
> saying "what do you think?". I will read it at the time when I am most able
> to give it my full attention ...

Unfortunately, that delay imposes pretty serious transaction costs on
innovation. Because most ideas are not worthwhile, it's often more productive
to discard them quickly and move on to the next idea than to dwell on them for
longer periods of time.

Put analytically, assume there are 2 developers at a company each with plenty
of ideas, but 9 out of 10 of them are garbage. Further assume that determining
a bad idea is actually a bad idea with another person takes 0.5 hours, but
doing it on your own takes 1.5 hours. The two devs will generate far more good
ideas (those 1 out of 10), if they talk to each other than if they dwell on
them without speaking to each other.

------
up_and_up
You might need to prune and/or curate your slack channels better. For major
projects/initiatives we use a new ephemeral slack channel for the duration of
the project. All chat comms about the project are stored there. The project
roadmap is kept in google docs with tickets in jira.

We have 12 teams and 150 people and prob 50+ channels.

------
cimmanom
One thing we do is keep a slack channel for announcements only. We require
everyone to acknowledge they’ve read and understood said announcements by
adding an emoji response. Then you can follow up with anyone who fails to
respond. (And discuss in 1-1s with anyone who makes a habit of failing to
respond.)

~~~
decebalus1
> We require everyone to acknowledge they’ve read and understood said
> announcements by adding an emoji response. Then you can follow up with
> anyone who fails to respond.

Office space - millennial edition

~~~
massivecali
Agreed. That sounds demoralizing and petty.

------
nilkn
Surely you're not trying to manage 40+ people yourself. Your "team" is
actually a division or sub-organization that should have a number of managers
or leads within it. You are not a manager but a director/VP. Your actual team
consists of the managers who should be reporting to you.

Each of your leads should probably be sending out a weekly email detailing the
work that their team has been doing. You should be working closely with your
leads so that they are distributing the right information downwards. You need
to empower the managers below you rather than trying to take this all on
yourself.

------
ensignavenger
A lot of good advice on the human side of things. I want to mention that Zulip
is an open source team chat solution that is designed to facilitate the "slow-
thinking" type of communication you mention.

------
planetburgess
We have 30 people across 9 countries and several teams who have very limited
real time cross over. We don't send internal emails. We use: Slack for
asynchronous discussion. If someone posts something in Slack they should
expect a response within 1-2 days. Salesforce chatter for operational
discussion. Comments on here should get answered within 1 work day. Skype chat
for real time chat. This should get answered asap (let's say 15 minutes). Zoom
for all meetings.

------
phereford
Tools that have worked in the past for me: \- Confluence for long lived
documents \- JIRA for time boxed groupings of work. \- Slack for real time
comm if anything arises. \- "Culture" and Process Living Document

I ran a team of about 25 in the past and followed the following agile
principles to help with alignment: \- retrospectives \- "sprints" (preference
on the 3-4 week range) \- Sprint Review

Alignment, while tricky, isn't all that hard so long as processes are evolving
from retrospectives and you have a single source of truth for long form
documentation.

------
wjossey
I don’t have an answer that is better than anyone else here, but I have a
related ask.

If anyone here feels passionately about this area and is a remote manager, I’d
love to talk to you 1:1. My email is in my profile.

I’m part of a team launching a manager training program this fall, and our
emphasis is on managers that have to deal with distributed teams. We’re
looking for guest speakers across a wide range of topics, including alignment,
and I’m pre-screening potential guest speakers right now.

I’d love to connect and learn more about your practical experiences!

------
reilly3000
We’re on slack and looking at Discourse for that purpose. It’s really high
quality software, and definitely geared in the direction of slow-thinking and
keeping topic history in the same place.

------
dpods
At Out Of Office we use slack for day to day communication and always require
video chat for team meetings unless you're on the go or not able to use video.

For longer term alignment we always post "decisions" that are made during
these meetings in a slack channel so that others can keep up to date if they
weren't in the meeting. We can also go back in time to see the context of why
a decision was made.

------
pkalinowski
We use [V2MOMs][1] for every team, created by said teams.

Then, daily and weekly calls. Whatever we do is more or less connected to
goals in V2MOM. It helps from being distracted.

[1]: [https://www.businessinsider.com/salesforce-v2mom-
process-201...](https://www.businessinsider.com/salesforce-v2mom-
process-2015-2?IR=T)

~~~
codemac
I find that MBO/OKRs drucker-style is lighter weight than V2MOM as the method
is left to the person doing the work.

Is there an advantage to documenting and setting methods in stone ahead of
time? Curious about your experiences with it.

~~~
pkalinowski
Well, they are not written in stone. We have quarterly V2MOMS and we change
their content during given quarter if that's better for the team.

~~~
codemac
Sure - nothing is written in stone?

Have you found it effective to discuss the actual method of how you'll
accomplish something months before you're working on it?

It seems like it would almost always change for development - maybe in other
areas it's more useful.

~~~
pkalinowski
We do V2MOMs not earlier than 2 weeks in advance. Usually we just write down
things we already decided to do.

------
carusooneliner
Try video for leadership updates - it's more personal than written
communication so helps build trust and you can explain things clearly with
emphasis.

Couple ways you could do it: 1. a webcam recording of yourself, using
quicktime (only on mac) or similar webcam recording tool 2. a screen recording
where you talk through a slide deck of news, roadmap, etc. Again, using
quicktime or chrome extensions such as the one I built:
[https://outklip.com](https://outklip.com). Outklip's advantage is you can
record webcam along with screen, annotate during recording, do post-editing
and upload to YouTube with a click.

I interiewed Sid Sijbrandij, the GitLab CEO (GitLab has 500+ members and is
all remote) on running a distributed company. He said this about alignment: "I
think it’s really important to write things down. People are very efficient at
reading things. So, if you wrote it down you can refer to it, so you don’t
have to say everything again, you can just drop a link. So, we write down a
lot, in our handbook, on our OKRs page, you’ll find all our goals and
strategy, etc. And at some point you keep repeating that, keep dropping those
links and you keep answering questions. So, repetition is still needed,
repetition is easier if you have one writeup and most people have already
found it even during onboarding.". Interview video and notes here:
[https://outklip.com/blog/gitlab-building-a-distributed-
compa...](https://outklip.com/blog/gitlab-building-a-distributed-company/)

Another interview with Sid about how GitLab uses video for remote work:
[https://outklip.com/blog/using-video-for-remote-
work/](https://outklip.com/blog/using-video-for-remote-work/).

------
epynonymous
i manage a lot of teams in a remote site, here are my thoughts, it starts with
leadership at the remote site, make sure this person and you are aligned, to
build alignment, trust goes a long way, but in the absence of trust, since
that takes time to build, make sure your goals (short and long term) are
clearly stated and known to him/her and that they can convey that message to
the team. at that number, also make sure that the next level managers are
getting the right message.

face to face is always best, zoom is great, wiki pages, etc.

------
aymeric
The guys behind Todoist have a tool to solve this. I haven't tried it myself:
[https://twist.com/?lang=en](https://twist.com/?lang=en)

------
hayksaakian
A few good books I can recommend

The Effective Executive

Making of a Manager

ReWork

Start with your own mindset around this topic first, then roll out a system
and/or tool to make it happen.

------
ryanthedev
Functions As A Service! It has worked great from the few implementations I
have seen.

~~~
ryanthedev
Well this is more from an architect manager. Trying to manage offshore and
internal tech stacks is always difficult. Out source work via FAAS user
stories.

------
gwbas1c
I've been working on a distributed team for over 8 years, and gradually moved
to architect of the product I work on.

There's a lot of good advice in this thread, but one more thing that I need to
add:

Your tickets need to be well-written, and actively groomed. This means things
like:

\- Clear ticket title

\- Clear steps to reproduce

\- Process followed (Varies based on product, in our case this means attaching
logs and documenting filenames.)

\- When someone clarifies things, they must update the actual ticket title /
description instead of clarifying in an email / comment

\- Management must not expect engineers to handhold ticket writers through
things like this, and must expect that testers and support own clearly
communicating what the issue is

\- Do not combine multiple bugs into the same ticket

\- Do not "fail verification" when finding a new bug

\- Relate similar tickets, don't identify new bugs / issues in a comment

Some examples of "bad" tickets:

\- Giving a title that's basically "It's not working." Every product has an
analogy of "It's not working." In our case, novices who don't take the time to
explain a problem will just create a lot of tickets titled "It's not syncing."

\- I had a ticket today where the steps to reproduce said, "Take a
screenshot." There's MANY ways to take a screenshot. The steps to reproduce
must say which tool / button combination were used.

\- Constantly needing to ask for things that are expected in the process. All
products have different needs. In our case, all tickets need logs and a sample
filename to look for in the log. When I need to constantly ask testers for
this information, it's a problem that management must address quickly

\- "Oh you fixed it but now it does this." What this creates is a situation
where many bugs are part of the same ticket, and someone needs to spend hours
reading through all comments to understand what the bug is. If the bug is
fixed and a new bug is found, verify the first bug, file a new ticket, and
relate them.

Edit: Actively grooming means:

\- The bugs assigned to someone must be realistic. Don't leave 100 bugs
assigned to someone for a release when there's no chance that they can do them
all.

\- Don't let your ticket submitters triage their tickets. QE shouldn't assign
a ticket to anyone. That just results in the 100 bugs assigned to someone
situation.

\- Dumb feature requests should be closed immediately. Someone using your
ticketing system to make dumb feature requests (and assign them to people)
should be stopped immediately. (An example is a tester requesting lots of
automation or helper tools from developers via the ticketing system.)

\- Out-of-scope bugs should not be assigned to a release

\- Major projects are not bugs, don't leave "bugs" that require major
refactoring assigned to someone when you aren't going to dedicate the time to
do it

\- Establish a feedback loop so that QE can better steer tickets on submitting
them. (IE, if there is a clear server error in a log, it's not a client bug.)
QE should be smart enough to do enough diagnostics to direct the bug before it
hits triage.

\- Don't constantly assign tickets to the wrong team. If someone keeps saying,
"this kind of ticket goes to this team," listen, otherwise they will go to
your upper management, CTO, architect, ect or and make you look like a fool
for not knowing the difference.

------
lamby
Do those corporate/private Twitter apps still exist?

------
jerednel
Can you just create a new slack channel for team news?

------
warp
basecamp?

~~~
blakesterz
I'll second checking out Basecamp. We use both Slack and Basecamp. ZenDesk for
customer issues. Everything tied together, both Slack and Basecamp have decent
tools to integrate so you get alerts where you need them. Basecamp has a nice
set of tools for projects and planning. I can't say I _LOVE_ it (and I don't
hate it), but I do love their support people. You could probably get away with
just using Basecamp as well. We did for quite a long time.

------
secondbreakfast
Basecamp

------
manishsharan
I think a distributed team,where individual members of the team are
geographically distributed, is designed to fail. Sure you could accomplish
some goals but the inertia is working against you. Such teams will be always
outperformed by co-located teams.

A better approach would be to have distributed teams where the teams are
cohesive unit with co-located members. Each team has local autonomy and a
central mandate. The teams could be located anywhere but the team members
would be in the same office.

Aliging distributed teams is easier as they can agree on coarse details , have
few or limited dependencies and they execute on their own. Otherwise you are
just shepherding cats.

~~~
toomuchtodo
There are several fully remote companies collectively generating hundreds of
millions of dollars in annual revenue. To require physical colocation is a
failure to properly manage, as well as delegate authority and responsibility.

> Such teams will be always outperformed by co-located teams.

Could you share data to back this assertion up?

~~~
jmspring
I agree with you.

For me, I've been fully remote for many years and was primarily remote for a
few years prior to that.

Companies I've been at where there is no flexibility whatsoever typically
suffer from poor management or are the type of work place where there are
pieces of hardware or other resources one can not really work on remotely.

One of the primary benefits for me when initially working remotely was the
time saving that resulted not having to spend 1.5-2.5 hours a day in the car.

