7 ms·

Would anyone else find this tiring though? I feel like I am omitting the use of basic communication skills in favor of something less than ideal. I guess I am

by dvcc 11y ago

Would anyone else find this tiring though? I feel like I am omitting the use of basic communication skills in favor of something less than ideal. I guess I am just not a huge fan of remote work in general though, so I have a hard time coming around to the idea that quick questions must go through a chat at all times.

Touche 11y ago
I guess the person who is always interrupting others in favor of their own issues would find it tiring. But the person who is constantly being interrupted would find it refreshing that they can prioritize themselves.
- matwood 11y ago
  We need to get off of this 'I am a special snowflake' that cannot be bothered to work with a team. If you want to solo develop than go be a solo app developer. If you want to deliver software as part of a team, then working with the team is part of the gig. I know it is hard to believe, but the act of coding is only one part of many required to deliver working software that meets the requirements. Great function you wrote there that does the wrong thing because you were too busy to be bothered.
  - Touche 11y ago
    Working with a team doesn't mean synchronous communication. We need to get off of this "I am a special snowflake" and my current issue trumps whatever anyone else is working on. Hire good people and trust that they will respond to issues appropriately. If your services are down and the company is bleeding cash every second, they will stop what their doing and help fix the issue. Having communication be synchronous-by-default more easily leads to scenarios where you decide to ask a colleague a question real quick that breaks their flow. I'm guilty of this myself.
dhd415 11y ago
The problem with that approach is that it inevitably favors the input of people who are physically present even if they are not the ones with the best answer to the question. As a remote development lead in a company without a remote-first culture, I find this happens a lot. The end result is that I end up having to fix a lot of problems that were caused by technical discussions that did not include the people such as me who had the most product context and technical expertise to correctly answer the question.
- dvcc 11y ago
  Do you not hold that more on your team though and less on the communication style? To me, if I know that someone else might have some information that would contribute to the discussion I'll include them. That feels like it would be more on the individual team members not knowing when to reach out, more so than the in-person meetings causing a remote/local gap.
  - dhd415 11y ago
    Some teams may be more prone to that problem than others, but it always takes more effort to include the remote folks in the conversations. It's usually true that the really momentous decisions are handled in meetings that include the appropriate workers, whether on-site or remote. The biggest problem is often the "not quite really important" questions for which the on-site folks figure that a answer from another on-site person that is "good enough" will suffice. The end result of that is growing technical debt from a series of decisions that weren't as good as they could have been with the input of the workers with the most knowledge of the problem area.
dsp1234 11y ago
It's a matter of culture. It may be tiring for some people, but having what I call 'dark meetings' all the time encourages a policy where remote workers are shut out of the process. This is pretty much the same as a default policy of "Don't IM me one-on-one, IM us all in the group chat", with exceptions for personal issues. I feel it's a good policy in general for two main reasons, first it increases the possibility that an issue is seen by the exact person who can respond to it, and second it discourages the formation of cliques of people who are doing their own thing which no one else knows about. Business requirements can get lost all the time with reasons like "Oh, I PM'd Jim about it, and I though he would mention Helen". So relating that back to remote workers, most meetings (and at least in my office, most meetings means basically every single one) are not formal meetings where everyone is involved. It's one-on-one's in someone's office, or talking offhand at the break room, or passing in the hall, and almost never officially recorded. That's perfectly fine (and it works with us as we have no remotes), but it hurts when you bring in remote workers because, by definition, they are attending less 'meetings'. Previously working remote, and having supervised remotes, this is one of the greatest issues that they face. So if the original question is 'How do you integrate remote developers?', then whatever solution that is presented will need to deal with these 'dark meetings'. My personal suggestion, and the one I've seen work the best, is just to try to encourage a culture where people recognize that they are talking about work, and to table that discussion until everyone is present (which in remote workers case is IM). It may sound dumb, but if everyone just said something like, 'Hey, this sounds like an issue Bob or Jane could help with, why don't we discuss that in dev chat', and that was considered Ok, then it flows smoothly.
- matwood 11y ago
  Your solution is good. I also will take 'dark meetings' and summarize the meeting in the tickets/confluence. This gets the information out to everyone (even others who are locally present but not in the meeting), and saves it for when I forget the meeting later :)
- chris11 11y ago
  Does this scale well? I don't think group chat would work well for larger chats. I personally ignore a lot of email that I isn't personally relevant. And one-on-one conversations are usually more personally relevant than group conversations.
ollysb 11y ago
The equivalent for remote is to ask someone if they've got a sec to jump on a hangout, it definitely isn't to start having a chat on slack. Slack is extremely low bandwidth, especially if you're trying to reach consensus on something, where body language becomes more important.

by dvcc 11y ago

Touche 11y ago

I guess the person who is always interrupting others in favor of their own issues would find it tiring. But the person who is constantly being interrupted would find it refreshing that they can prioritize themselves.

matwood 11y ago
We need to get off of this 'I am a special snowflake' that cannot be bothered to work with a team. If you want to solo develop than go be a solo app developer. If you want to deliver software as part of a team, then working with the team is part of the gig. I know it is hard to believe, but the act of coding is only one part of many required to deliver working software that meets the requirements. Great function you wrote there that does the wrong thing because you were too busy to be bothered.
- Touche 11y ago
  Working with a team doesn't mean synchronous communication. We need to get off of this "I am a special snowflake" and my current issue trumps whatever anyone else is working on. Hire good people and trust that they will respond to issues appropriately. If your services are down and the company is bleeding cash every second, they will stop what their doing and help fix the issue. Having communication be synchronous-by-default more easily leads to scenarios where you decide to ask a colleague a question real quick that breaks their flow. I'm guilty of this myself.

dhd415 11y ago

The problem with that approach is that it inevitably favors the input of people who are physically present even if they are not the ones with the best answer to the question. As a remote development lead in a company without a remote-first culture, I find this happens a lot. The end result is that I end up having to fix a lot of problems that were caused by technical discussions that did not include the people such as me who had the most product context and technical expertise to correctly answer the question.

dvcc 11y ago
Do you not hold that more on your team though and less on the communication style? To me, if I know that someone else might have some information that would contribute to the discussion I'll include them. That feels like it would be more on the individual team members not knowing when to reach out, more so than the in-person meetings causing a remote/local gap.
- dhd415 11y ago
  Some teams may be more prone to that problem than others, but it always takes more effort to include the remote folks in the conversations. It's usually true that the really momentous decisions are handled in meetings that include the appropriate workers, whether on-site or remote. The biggest problem is often the "not quite really important" questions for which the on-site folks figure that a answer from another on-site person that is "good enough" will suffice. The end result of that is growing technical debt from a series of decisions that weren't as good as they could have been with the input of the workers with the most knowledge of the problem area.

dsp1234 11y ago

It's a matter of culture. It may be tiring for some people, but having what I call 'dark meetings' all the time encourages a policy where remote workers are shut out of the process. This is pretty much the same as a default policy of "Don't IM me one-on-one, IM us all in the group chat", with exceptions for personal issues. I feel it's a good policy in general for two main reasons, first it increases the possibility that an issue is seen by the exact person who can respond to it, and second it discourages the formation of cliques of people who are doing their own thing which no one else knows about. Business requirements can get lost all the time with reasons like "Oh, I PM'd Jim about it, and I though he would mention Helen". So relating that back to remote workers, most meetings (and at least in my office, most meetings means basically every single one) are not formal meetings where everyone is involved. It's one-on-one's in someone's office, or talking offhand at the break room, or passing in the hall, and almost never officially recorded. That's perfectly fine (and it works with us as we have no remotes), but it hurts when you bring in remote workers because, by definition, they are attending less 'meetings'. Previously working remote, and having supervised remotes, this is one of the greatest issues that they face. So if the original question is 'How do you integrate remote developers?', then whatever solution that is presented will need to deal with these 'dark meetings'. My personal suggestion, and the one I've seen work the best, is just to try to encourage a culture where people recognize that they are talking about work, and to table that discussion until everyone is present (which in remote workers case is IM). It may sound dumb, but if everyone just said something like, 'Hey, this sounds like an issue Bob or Jane could help with, why don't we discuss that in dev chat', and that was considered Ok, then it flows smoothly.

matwood 11y ago
Your solution is good. I also will take 'dark meetings' and summarize the meeting in the tickets/confluence. This gets the information out to everyone (even others who are locally present but not in the meeting), and saves it for when I forget the meeting later :)
chris11 11y ago
Does this scale well? I don't think group chat would work well for larger chats. I personally ignore a lot of email that I isn't personally relevant. And one-on-one conversations are usually more personally relevant than group conversations.

ollysb 11y ago

The equivalent for remote is to ask someone if they've got a sec to jump on a hangout, it definitely isn't to start having a chat on slack. Slack is extremely low bandwidth, especially if you're trying to reach consensus on something, where body language becomes more important.