Asynchronous workflows at Github - for non-Engineering too?

[ohookins]

Another workflow-at-Github question :smile:

It has been well publicised that Github works asynchronously, electronically, avoiding meetings and meatware interactions etc etc. This seems like a good fit for a geographically dispersed engineering organisation. Do you use the same workflow mechanisms and methodologies for non-engineering parts of your organisation e.g. sales, finance, HR etc?

Do they all work remotely? In different timezones?

As a result, or perhaps despite this, do you feel like you have a homogeneous company culture across both engineering and administrative parts of the organisation? If you do, what measures do you use to judge this?

Many thanks if you get a chance to answer my questions!

[holman]

Do you use the same workflow mechanisms and methodologies for non-engineering parts of your organisation e.g. sales, finance, HR etc?

Yup; we're one of the few (only?) organizations that can say their entire legal team knows and uses Git. HR, sales, finance... pretty much everyone does planning in a repo or the issues on a repo. It makes it easy to collaborate cross-team, since there's almost always a papertrail that you can jump in on and immediately get context for.

Do they all work remotely? In different timezones?

It varies. People who run our office are almost all in SF; that's kind of a necessity, obviously. Most of the non-engineering teams tend to be in SF too, although we have remote people in HR, recruiting, and so on as well. It really depends on your team, what you do, and who the people are external to your team that you work with.

As a result, or perhaps despite this, do you feel like you have a homogeneous company culture across both engineering and administrative parts of the organisation? If you do, what measures do you use to judge this?

Yeah, I think we do. I mean, certainly teams vary a dramatic amount, but I think the idea of transparency, of having a URL for people to read documents and discussion, and sharing information throughout the company is true no matter what team you're on.

[ohookins]

Awesome answers, thanks very much!

[djch]

Yup; we're one of the few (only?) organizations that can say their entire legal team knows and uses Git.

@holman How liberally do the legal team use emoji? :black_nib: :page_with_curl:

[holman]

Hah, enough. :) The real question is if emoji has made it into any legal documents (that I'm guessing is a "no").

[kyleschmolze]

When non-engineers are using the same workflow, what repositories are they contributing to? I would imagine that legal isn't creating issues on github/github, right?

We really love Github's style of communication, and my company is looking into using it for non-engineering communication, as well. Basically, we are thinking about setting up a repo which is a wiki about our company, covering everything that we do. We'd have the markdown files be in the repo itself, so then everyone in our company can constantly propose and discuss systematic changes through the Issue-Branch-PR workflow on our wiki! I feel this would be supremely awesome, if it worked. Do any of your teams run this way? I'd be super curious to learn more if so.

cc @holman in case you have time to get to this, thanks so much!

[holman]

I'm not a GitHubber anymore, but I love talking about this.

When non-engineers are using the same workflow, what repositories are they contributing to? I would imagine that legal isn't creating issues on github/github, right?

Tons! HR does management of HR policies and decision in different repositories, and it's pretty nice to be able to go back and see the thought behind a particular new decision that might come out. Legal might not be creating issues on github/github directly, but they'll be cc'd in from time to time if someone has a question about the legality of a new feature, or issues with data, etc. Support has a repo where they digest the firehose of all feature requests, general common problems, etc., so developers can jump in and see where the hot spots are that should be fixed.

Basically, we are thinking about setting up a repo which is a wiki about our company, covering everything that we do. We'd have the markdown files be in the repo itself, so then everyone in our company can constantly propose and discuss systematic changes through the Issue-Branch-PR workflow on our wiki!

Yup- and I'd suggest you try using Markdown documents in a repository instead of a wiki, potentially. As I alluded to earlier, there was a great HR story I like to tell:

Last year at some point, HR made some change to something. Insurance policy maybe, or something I'm not too terribly interested in dealing with (but was affected by it, as an employee). It wasn't a huge deal, but it felt like a strange change when it was initially announced. In the announcement, the author of the changes had a couple links at the end to the HR repository of pull requests where this change was discussed.

Once I clicked through the pull requests, I saw that over the last few months all of my uneasiness and questions had already been brought up and discussed. By the end of the thread, even though I didn't necessarily agree with the change at the onset, I came around based on the discussion and ended up completely agreeing with it — I would have made the same decision in their shoes.

I really like relaying this story for two reasons:

• It allows an employee who's not in charge of these decisions — but still affected by them — to initially ignore these debates. As a company grows, having too many cooks spoils the discussion, so to speak, and more importantly you don't want everyone to be distracted by things that aren't their primary job.
• It allows those employees to trust that the other team knows what it's doing, and when a decision is made (or immediately before it's going to be made, in a feedback phase), the employee can jump in and, within a minute or two, scan the discussion and thought process of entire weeks or months of debate beforehand. In other words, they can instantly jump to the current point in the debate without wasting their time prematurely. Additionally, the decision makers here benefit from the ability to discuss their changes with other players before bystanders jump in (with important feedback nonetheless, but perhaps once the discussion's more mature).

I think it's a pretty powerful behavior inside a company. Obviously there's a lot of balance to find with your organization between control and accessibility of information, but if you start getting that balance correct it can be really freeing.

[kyleschmolze]

Wow, Zach. Thanks so much for the insight. This sounds incredible! It seems obvious that a semi-public thread-based system is much better all around for communication than email or other popular tools, because it keeps a public (searchable) record of all conversations, and also allows you to rope in the appropriate people/teams as needed. And although you could get similar behavior with an internal forum or other tools, github is probably the most sophisticated one.

But the fact that you can provide the powerful Branch-PR workflow for documents that aren't code, and allow non-engineers to benefit from it's simplicity and intuitiveness (once you learn git, ha), just makes this seem like the holy-freaking-grail of company tools. I'm so pumped!

I will say though, that I was surprised to see that github doesn't provide any next-level product development planning/mapping tools. Seems like an easy add! (I'd even guess there's an unmerged branch of github/github somewhere out there with some features like this, but that you guys decided against it). I guess it makes sense for github, because you guys don't make many top-down product decisions (from what I can tell). So if everyone is just working on the features they're interested in, a tool like Pivotal Tracker just doesn't make sense.

But my startup doesn't have the luxury of being profitable (although I love it more than anything), and currently we only have one full-time engineer (me), with some help from a handful of volunteer contributors. With such constrained resources, we need to make sure that all dev time is very well spent, so a dev "priorities" document of some kind is really useful. I'm considering experimenting with a tool like ZenHub, which basically adds a couple pivotal-tracker-style screens into github via chrome extension. We shall see.

Anyways, thanks again for all the help, I hope this works! If I can remember I'll report back with findings.

[holman]

I was surprised to see that github doesn't provide any next-level product development planning/mapping tools

yeah me too

I guess it makes sense for github, because you guys don't make many top-down product decisions (from what I can tell).

That's no longer the case- it's pretty structured and top-down.