Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Working remotely with 150+ people

medium.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Working remotely with 150+ people

#41

Post by dhd415 »

tcrews wrote: post #18

I've been working remotely for 2 years now and my team has people from all over the world. People mostly talk on IRC but not a lot (about important stuff) and there is a HUGE number of periodic meetings. I can't stand them. What's worse, every time things start to appear to be going off track, the initial reaction is to always set up a new periodic meeting about topic X... this is supposed to bring people together bu…

My team has a daily 15-minute scrum meeting that I haven't found overly burdensome. We're spread over a 4-hour time difference, so the time of day isn't really an imposition on anyone. It's also no big deal if someone misses from time to time but I've found it generally helpful for keeping up with what the team is doing.

Re: Working remotely with 150+ people

#42

Post by k__ »

weatherstorme wrote: post #37
k__ wrote: post #29

Earlier quoted context omitted.

Hm, okay. Maybe I'm special, in a bad way? I don't know. I never really got along with people that I was "forced" to be together with. School, University, Work. I mean, people liked to work with me and I'm mostly really polite and inclusive and all. But I didn't find many people I considered interesting at these places. I got all my friends from meetups, online communities, parties, etc.

That's perfectly fine. Some people prefer to keep work at work. It is good to do though if you want to climb up and understand the politics at your office (which sucks). I'm also just a super social person, and kind of an outlier.

haha, yes.

Every time I noticed such things going on at a company, I jumped ship.

Re: Working remotely with 150+ people

#43

Post by pcsanwald »

brilliantcode wrote: post #34
nradov wrote: post #30

Earlier quoted context omitted.

Yes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams . In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.

This is very interesting . Can you elaborate more on such organizational structure or know of anyone implementing in real life? To me it totally makes sense. Instead of the inevitable interdependency that arises through the component model, I can see that if teams were building features on their own than it could be completed at their leisure (in the budget & time affordable) without the multi-directional multi-disci…

The more general term for these two structures are Functional vs Divisional structures. In the case of software engineering, a feature based team is a functional structure, and a "database team" (or "API team", or any other specific technical concern) is a divisional structure.

Re: Working remotely with 150+ people

#44

Post by gedrap »

brilliantcode wrote: post #33

I keep hearing the word async come in these remote working threads, what does that mean exactly in this context? What does this single source of truth look like? A google docs spec?

Async means reducing likelihood that your work will be blocked by someone else (e.g. waiting for response from someone) as it might cause big issues when someone is 10 hours away. If you can't get any work done because you are waiting for someone who is sleeping, that's really bad.

Single source of truth can be google doc, wiki, github issues/wiki, whatever. As long as it's single. The problem is when critical information is scattered in slack history, github issues and PRs, wiki and some odd google doc. It makes it hard to find information and you will end up finding contradictory information. Lack of single source of truth or not updating one will reduce the async property of the whole operation, among other things.

Re: Working remotely with 150+ people

#45

Post by dsr_ »

brilliantcode wrote: post #33

I keep hearing the word async come in these remote working threads, what does that mean exactly in this context? What does this single source of truth look like? A google docs spec?

Synchronous methods of communication are phone calls, conference calls, in-person meetings, and anything else that requires that two or more people attend the same "event" at the same time.

Async is everything else: email, IM, leaving voicemail, blog posts, git comments, tickets, bug reports...

Re: Working remotely with 150+ people

#46

Post by sytse »

nradov wrote: post #30
huherto wrote: post #24

Earlier quoted context omitted.

Generalizing this idea. Interdependences are big source of problems and delays in projects. Many people don't realize it, but you have to actively work on eliminating them. You see it in the form people waiting for other people. Every team should be organized in a way that they can we do their work without waiting for other teams.

Yes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams . In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.

Feature teams make a lot of sense, but one of the problems is that you tend to end up with two bosses, one team boss and one functional boss.

At GitLab we're trying to see if we can do component teams with handoffs (UX => front end => back end). This is hard and we might have to reconsider. I've detailed the reasons in https://about.gitlab.com/handbook/leadership/#no-matrix-orga...

Re: Working remotely with 150+ people

#47

Post by nradov »

sytse wrote: post #46
nradov wrote: post #30

Earlier quoted context omitted.

Yes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams . In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.

Feature teams make a lot of sense, but one of the problems is that you tend to end up with two bosses, one team boss and one functional boss. At GitLab we're trying to see if we can do component teams with handoffs (UX => front end => back end). This is hard and we might have to reconsider. I've detailed the reasons in https://about.gitlab.com/handbook/leadership/#no-matrix-orga...

In any large engineering organization with a bunch of products each of which are large enough to need multiple teams, multiple bosses are inevitable. The issues and technology are just too complex for any single boss to manage everything. A typical agile team member might be accountable to a resource manager for HR type stuff, a Scrum Master for team tasks, a Product Owner for team priorities and requirements, and multiple component stewards for component technical integrity. The key is to align everyone to a common set of program goals and clearly delineate responsibilities between those various "bosses" to prevent conflicts and avoid excessive communication overhead.

A "no-matrix" structure might work in a small organization which has basically only a single product. In that case it's actually possible for a single competent boss to understand the customer, product, employees, and technology well enough to make good decisions.

Re: Working remotely with 150+ people

#48

Post by cpeterso »

exDM69 wrote: post #14
codingvelocity wrote: post #8

While i'm not 100% remote (i'm part of a small regional office that has a massive head office in another part of the country, but I can work from home). Something i've found incredibly important is jumping on video chat. There's something about seeing someone in a video while you talk to them that reminds you "hey i'm working with other humans, i should respond with a level of empathy i'd expect in return"

Are these individual or group chats? What kind of solution do you have? I work in a small office of a big company and have a 10 hour timezone difference to my most important co-workers. We chat on the phone but I don't really enjoy it. I'm not sure video chat would help, but I might be willing to try. But it would be slightly inconvenient because of the timezones. We might have 10-20 people from 5-10 locations around…

Even for quick conversations, video chat is much better than a phone call because it has higher quality audio and you can see the visual cues of when it's your turn to talk.

There are plenty of easy browser-based video chat applications using WebRTC like https://appear.in/. You can send people URLs to your video room and there's no software to install.

Re: Working remotely with 150+ people

#49

Post by dozzie »

brilliantcode wrote: post #33

I keep hearing the word async come in these remote working threads, what does that mean exactly in this context? What does this single source of truth look like? A google docs spec?

Synchronous communication happens when one participant says/sends something and then waits for the other participant to reply doing nothing else. Exactly the same as with synchronous function call: you order some operation and wait patiently for it to return the result.

Asynchronous communication is when one participant sends something and leaves things as that. For a reply, either another (asynchronous) message is sent, this time in the opposite order, or the sender checks if the reply arrived.

Real-time communication, like phone calls, video conferences, and various chats and communicators are synchronous by the very nature of the activity of conversation. Everything that you may postpone checking is asynchronous; e-mail, tickets/issues, and source code commits are like that.

Re: Working remotely with 150+ people

#50

Post by YZF »

nradov wrote: post #30
huherto wrote: post #24

Earlier quoted context omitted.

Generalizing this idea. Interdependences are big source of problems and delays in projects. Many people don't realize it, but you have to actively work on eliminating them. You see it in the form people waiting for other people. Every team should be organized in a way that they can we do their work without waiting for other teams.

Yes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams . In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.

That's not a silver bullet though.

In a large software system you can't expect any individual to be as effective working in any area of the system. So you're winning on the blocking front but you're losing on the productivity front as people ramp in on different pieces and you're also potentially losing a sense of ownership from the developers and instead giving them a sense they're cogs in a machine...

To me a better compromise is to ensure you have enough of a backlog that you can always pick something that is the right combination of expertise/interest/lock-free at any given time. If you plan properly and you have sized your teams properly things should move along better than trying to get everyone to work everywhere on some random feature. That's not to say you can't occasionally do that if something important comes along but to me feature teams in large scale software is to be avoided. [EDIT: realizing this is maybe too strong of a statement, a team can definitely work across multiple pieces and will ideally implement complete features, but those features need to be a match to the capabilities of the team as opposed to just looking a "feature team" as some sort of unit of production for any random feature]

There's another part to this which is that it can be difficult to see the inter-dependencies between features. So modelling your software development as a bunch of teams that can just pull the next feature from the queue and work on it may actually not solve the locking problem at all but create more subtle dependencies and less efficiency.

Post reply on HN