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

51–60 of 63 posts

Re: Working remotely with 150+ people

#51

Post by wapz »

fsavard wrote: post #28
91bananas wrote: post #16

Earlier quoted context omitted.

If you're ok with the Google machine and spending way too much money on a computer that does basically nothing, there are these from Google[0] which have been great for me and my team. We have a Hangout open all day in the office, displayed on a 60" TV. Anyone that's working remote can jump in whenever and it's somewhat like they're in the office. Audio is my only complaint. Sometimes it is difficult to be heard [0]:…

That's interesting. Are you aware of other teams using video chat like this, ie. all day long? Do you know what the Google monthly fees are? Is the bandwidth consumed a concern?

If they're using Hangouts I presume it's free. I've used Hangouts while partially-remote (very small scale) and we just used regular google accounts.

Re: Working remotely with 150+ people

#52

Post by nradov »

YZF wrote: post #50
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.

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 bette…

If you're optimizing for productivity then you're focusing on the wrong metric. In order to deliver more customer value faster focus instead on driving down the cost of delay. For a detailed quantitative economic analysis of why this works please read "The Principles of Product Development Flow" by Donald G. Reinertsen. (Trust me it's one of the 10 best books on practical software management and will recalibrate your thinking in multiple areas.)

For large complex software systems every team member can't be an expert on everything. That's why within the overall program you set up separate small agile feature teams composed of team members who each bring some specialized skills and experience. Plus you should also layer on a matrix of component stewards who help maintain technical integrity for individual components. For a detailed explanation of how that works please see Ken Rubin's presentation "Scaling with Feature vs. Component Teams". http://www.innolution.com/resources/presentations/svaln-2015...

No one ever claimed that a feature team organization is a silver bullet. But if implemented right it will usually deliver at least a minor boost.

Re: Working remotely with 150+ people

#53

Post by 91bananas »

fsavard wrote: post #28
91bananas wrote: post #16

Earlier quoted context omitted.

If you're ok with the Google machine and spending way too much money on a computer that does basically nothing, there are these from Google[0] which have been great for me and my team. We have a Hangout open all day in the office, displayed on a 60" TV. Anyone that's working remote can jump in whenever and it's somewhat like they're in the office. Audio is my only complaint. Sometimes it is difficult to be heard [0]:…

That's interesting. Are you aware of other teams using video chat like this, ie. all day long? Do you know what the Google monthly fees are? Is the bandwidth consumed a concern?

Yeah, hangouts itself is a completely free service. I am not familiar with too many others doing this.

I've heard a couple other stories like ours. One I remember specifically was a company with a 50/50 mix, they did ALL meetings from their own desks on a hangout so that everyone had the same presence, the remote people didn't feel left out, because everyone has to fight for the same one audio track.

As for bandwidth, it hasn't been anything that we've been troubled by. Been using it for nearly 2 years now. The client on the remote machines has some hiccups from time to time and is somewhat of a resource hog. But if you keep it in the background it isn't too bad.

Re: Working remotely with 150+ people

#54

Post by YZF »

nradov wrote: post #52
YZF wrote: post #50

Earlier quoted context omitted.

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 bette…

If you're optimizing for productivity then you're focusing on the wrong metric. In order to deliver more customer value faster focus instead on driving down the cost of delay . For a detailed quantitative economic analysis of why this works please read "The Principles of Product Development Flow" by Donald G. Reinertsen. (Trust me it's one of the 10 best books on practical software management and will recalibrate you…

I'll check that book out, thanks. We'll see if it can re-calibrate me ;)

In my view optimizing productivity isn't necessarily mutually exclusive with other things you're trying to achieve. If productivity is very low then most other measures will tend to fall too though that may lag. The problem is that productivity tends to have poor visibility and is difficult to measure.

What I object to with all my heart is the "feature team" as the assembly line model of software "features". I.e. the software factory where features come in one end, get assigned to a random team, and product gets delivered on the other end. This model results in low quality, expensive, bloatware at best. It may or may not at any given time make some money. It's also not the model used, AFAIK, in most successful software companies.

Re: Working remotely with 150+ people

#55

Post by voycey »

cpeterso wrote: post #48
exDM69 wrote: post #14

Earlier quoted context omitted.

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.

I have pretty much moved over to appear.in 100% now, I find its latency is much better when working with remote teams (I am based in Australia and the stakeholders are in the USA (East and West coast) - Appear in is flawless, have had 8 people on a call and it just works, hangouts frequently craps out unless bandwidth is perfect!

Re: Working remotely with 150+ people

#56

Post by BurningFrog »

Inthenameofmine wrote: post #23
BurningFrog wrote: post #15

Earlier quoted context omitted.

Sounds expensive.

In my experience having any other type of people is generally more expensive because you are wasting higher level people on actively managing lower value tasks to get done.

Sure. But if you need higher quality people in a distributed team, that just means it is harder to get things done in such a team.

Re: Working remotely with 150+ people

#57

Post by TheCoelacanth »

nradov wrote: post #52
YZF wrote: post #50

Earlier quoted context omitted.

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 bette…

If you're optimizing for productivity then you're focusing on the wrong metric. In order to deliver more customer value faster focus instead on driving down the cost of delay . For a detailed quantitative economic analysis of why this works please read "The Principles of Product Development Flow" by Donald G. Reinertsen. (Trust me it's one of the 10 best books on practical software management and will recalibrate you…

I've worked on teams like that before, and my biggest gripe is that it is next to impossible to get a good code review. People on your team don't have the specialized knowledge necessary for effective reviews and the people on other teams who do aren't invested enough to do it thoroughly and in a timely manner and usually won't be familiar enough with the details of the feature you are working on to do it well.

Re: Working remotely with 150+ people

#58

Post by nradov »

TheCoelacanth wrote: post #57
nradov wrote: post #52

Earlier quoted context omitted.

If you're optimizing for productivity then you're focusing on the wrong metric. In order to deliver more customer value faster focus instead on driving down the cost of delay . For a detailed quantitative economic analysis of why this works please read "The Principles of Product Development Flow" by Donald G. Reinertsen. (Trust me it's one of the 10 best books on practical software management and will recalibrate you…

I've worked on teams like that before, and my biggest gripe is that it is next to impossible to get a good code review. People on your team don't have the specialized knowledge necessary for effective reviews and the people on other teams who do aren't invested enough to do it thoroughly and in a timely manner and usually won't be familiar enough with the details of the feature you are working on to do it well.

The impacted component stewards are supposed to be in the reviewers list (along with members of your own team) for any significant change.

Re: Working remotely with 150+ people

#59

Post by brilliantcode »

pcsanwald wrote: post #43
brilliantcode wrote: post #34

Earlier quoted context omitted.

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.

so why aren't more shops implementing a functional organization? It's still divided into front-end and back-end. What is the hindering factor and what tools would be a good fit for functional organization? AWS Lambda where people push their own backend along with the front-end thereby managing the full stack?

Re: Working remotely with 150+ people

#60

Post by pcsanwald »

brilliantcode wrote: post #59
pcsanwald wrote: post #43

Earlier quoted context omitted.

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.

so why aren't more shops implementing a functional organization? It's still divided into front-end and back-end. What is the hindering factor and what tools would be a good fit for functional organization? AWS Lambda where people push their own backend along with the front-end thereby managing the full stack?

I have no idea why many engineering organizations insist on maintaining the artificial distinctions of "front end" and "back end". I think we do ourselves a disservice by labelling ourselves with those distinctions, but the entire industry seems to disagree with me.
Post reply on HN