How GitHub Works: Be Asynchronous
zachholman.com
How GitHub Works: Be Asynchronous
1–10 of 62 posts
Re: How GitHub Works: Be Asynchronous
#2I really wish the author didn't use such an inciteful title for his section on meetings. The title offers another catch phrase to avoid meetings. I'd much rather have seen Zach focus more on his actual point: holding short, focused, and tiny meetings. I fear that his title, and other catch phrases like it, encourage siloing. Siloing is far more "fucking toxic".
Re: How GitHub Works: Be Asynchronous
#3Useful terminology (working asynchronously). There was a discussion recently about working remotely and I struggled to convey the difference between a remote-employee and a remote-team (http://news.ycombinator.com/item?id=2847012)... This is really the core of it. Teams that operate like this have a much better ability to adopt remote workers, for one thing.. and I suspect a much higher index of developer happiness, for another.
Re: How GitHub Works: Be Asynchronous
#4This seems a little far from the truth. What if someone needs to fix an urgent live issue? You can't always work async. Sometimes things need to get done, now. E.g. issues on a production system that are breaking the site for everyone.
Sadly, people often think that everything needs to be done now and I think forcing less meetings on people helps that happen.
Re: How GitHub Works: Be Asynchronous
#5This seems a little far from the truth. What if someone needs to fix an urgent live issue? You can't always work async. Sometimes things need to get done, now. E.g. issues on a production system that are breaking the site for everyone. Sadly, people often think that everything needs to be done now and I think forcing less meetings on people helps that happen.
We'll still work in Campfire though. We have an infrastructure room where we get all of our notices and systems-level logging piped to, and all of our on-call sysops can get together and deal with stuff immediately when it's necessary.
But it's still async... from the perspective of others. I'm not typically deep into the systems-level maintainability on GitHub, but I can check the transcript during or after the downtime happened and can figure out what happened, how the discussion around it went, and how it was dealt with.
Re: How GitHub Works: Be Asynchronous
#6I really wish the author didn't use such an inciteful title for his section on meetings. The title offers another catch phrase to avoid meetings. I'd much rather have seen Zach focus more on his actual point: holding short, focused, and tiny meetings. I fear that his title, and other catch phrases like it, encourage siloing. Siloing is far more "fucking toxic".
Where did you pick up the fact that his actual point was to hold tiny focused meetings? Working asynchronously is pretty anti-meeting, and frankly it's totally independent of a culture that supports silos. I work in a very asynchronous culture right now. Very few meetings.. but that's not to say we don't communicate. We communicate very thoroughly.
However short and focused they are, my definition of a meeting is a schedule block of (any size of) time where a number of people are expected to party on something and decide on some action.
To extend Zach's metaphor, meetings are a communication mutex. They force a topic to be wrestled by a group of people at the lowest-common-denominator of pace. I think they're rarely the best or most efficient way to collaborate.
Re: How GitHub Works: Be Asynchronous
#7I really wish the author didn't use such an inciteful title for his section on meetings. The title offers another catch phrase to avoid meetings. I'd much rather have seen Zach focus more on his actual point: holding short, focused, and tiny meetings. I fear that his title, and other catch phrases like it, encourage siloing. Siloing is far more "fucking toxic".
Most engineers focus in meetings about "what I got". The reality is meetings should be about "what the organization gets". Sometimes an engineer may come away with nothing but the organization profited significantly.
That said, too many meetings are intensely toxic for any company, and nothing is worse than working at a company that thinks meetings are "getting things done".
Re: How GitHub Works: Be Asynchronous
#8I really wish the author didn't use such an inciteful title for his section on meetings. The title offers another catch phrase to avoid meetings. I'd much rather have seen Zach focus more on his actual point: holding short, focused, and tiny meetings. I fear that his title, and other catch phrases like it, encourage siloing. Siloing is far more "fucking toxic".
Well, then you object to more than just the section head, right? Because he didn't suggest anywhere that he approved of short, focused, tiny meetings. As far as I can tell, he meant precisely what he said in the title.
Re: How GitHub Works: Be Asynchronous
#9I really wish the author didn't use such an inciteful title for his section on meetings. The title offers another catch phrase to avoid meetings. I'd much rather have seen Zach focus more on his actual point: holding short, focused, and tiny meetings. I fear that his title, and other catch phrases like it, encourage siloing. Siloing is far more "fucking toxic".
> I'd much rather have seen Zach focus more on his actual point: holding short, focused, and tiny meetings.
That is nowhere in sight in the post. In fact, the content of the section is even more damning than the title:
> I tend to loathe meetings even more than 37signals. I despise them.
> meetings pull you from doing actual work in order to talk about doing work.
> meetings are utterly forgettable. Even if you take meeting notes, you can’t capture them all.
Zach does not say he likes "short, focused and tiny meetings", Zach says he hates meetings as much as a human being can hate a concept.
Re: How GitHub Works: Be Asynchronous
#10I really wish the author didn't use such an inciteful title for his section on meetings. The title offers another catch phrase to avoid meetings. I'd much rather have seen Zach focus more on his actual point: holding short, focused, and tiny meetings. I fear that his title, and other catch phrases like it, encourage siloing. Siloing is far more "fucking toxic".
Where did you pick up the fact that his actual point was to hold tiny focused meetings? Working asynchronously is pretty anti-meeting, and frankly it's totally independent of a culture that supports silos. I work in a very asynchronous culture right now. Very few meetings.. but that's not to say we don't communicate. We communicate very thoroughly. However short and focused they are, my definition of a meeting is a s…
I'm reading a bit into his words, yes. Here's the part of interest:
"""You don’t have this problem with chat transcripts. Forcing people to reduce their otherwise rambling thoughts into concrete sentences helps focus discussion, too.
We’ll have meetings at GitHub, but I can count the number of full “meetings” we’ve had in the last year and a half on one hand."""
The former bit implying that the focus of sentences helps, the latter bit implying to keep the membership of the meeting to only those required.
Again: siloing is far more toxic than meetings in my experience. It's far too easy for a dev to wander down a path that has no value when operating in a silo. Agile tells us that we need to exist in a state of constant communication and feedback. This necessitates meeting with people in some fashion.