Depending on your definition, GitHub is arguably an enterprise app company. Think about it: millions of users, thousands of companies whose businesses depend on the software and an expanding complex problem space. Oh, and they have a product called GitHub Enterprise.
Most people would agree, though, that GitHub’s enterprise app is far removed from the traditional view of enterprise software. So, what sets them apart from the companies who build the enterprise software that everybody hates?
Drink Your Own Champagne
Mark Tareshawty is a core engineer at GitHub and he puts it down to culture.
At the heart of that culture is a simple idea. The engineers who make GitHub are also users of GitHub: “We build things that we want to use. So, sometimes it’s a little bit of a selfish need or a want.” As a result, the developers responsible for making GitHub would be the first to complain if their peers added a feature that worked poorly or introduced a regression in the user interface.
“We also gather a lot of customer feedback from people,” Mark told me. “I think the one really big place that we get a lot of our feedback, though, is our super-fans. We have fans that just adore GitHub and love GitHub, and so they give us feedback all the time. And those same super-fans who use GitHub at home or in their open-source, also want to use GitHub in their enterprise jobs. And so that really drives us to build really great enterprise software.”
Create a Unified Experience
GitHub’s journey has been one of expanding horizons. What started as a way to host and share git repos has turned into a suite of tools for managing the creation of software projects. One common complaint about enterprise software is that new features are often cobbled together. The result is an inconsistent, patched enterprise app.
Mark explained how GitHub had avoided that, “It really helps that we have a unified design team. We have a core design team and they split off into different parts of engineering. But, what really helps is that our design team all talk to each other constantly and get feedback from each other.
“So, they make sure that it’s a consistent pattern and UI throughout the app. We also have an internal pattern. Actually, it’s open-source if you’ve ever seen Primer. It’s an open-source set of CSS classes and style guides and patterns.”
Primer acts as the guideline for all design work at GitHub. So, even if a brand-new designer or engineer were to tackle a feature, they could create something consistent with the rest of the product.
Metrics-Driven Product Development
Just about everything in GitHub is instrumented. Therefore, the product team can see how, when and why different parts of the system get used.
A willingness to change course in the face of new data is a key differentiator between an enterprise app people love and an enterprise app people hate. “If new information comes in, we definitely re-evaluate it. GitHub is very data-driven, and we usually make all of our decisions based on data. So, if there is hard data that we are doing something wrong, or it’s not going to work out, we will pivot and move on. We always want what’s best for the customer and for us.
“We do a lot of metrics inside of GitHub.com, and so we can actually see what APIs are being used, how they’re being used. We also do customer interviews.
“I actually have a couple next week, where we sit down with integrators, and we ask them how they’re doing. Do they still like the platform? Are there things that we can do to make their lives easier? As somebody who’s working on something in pre-release, I interview different integrators to see how the pre-release is going. Are they feeling like they’re missing things? So, it’s both soft and data-driven, which I really like.”
Iterate Then Iterate Some More
For a new feature, GitHub engineers start by thinking about the end-to-end implementation. However, there’s no one sitting at a desk churning out UML diagrams for years on end.
“When I’m working on a new feature I will build it pseudo end-to-end. So, I will spike it out in a pull request, and I’ll say, ‘Hey, these are the data changes we’re gonna need to make, these are the model changes we need to make, this is how I think it should look.’ You don’t spend more than maybe a day or two on it, depending on how complex it is, and then we talk about the spike. And then once the spike is over, we close the pull request, and based on all the feedback from that pull request, then we can start working on the actual piece.”
You’re Free to Move About the … Team Structure
How teams are organized can have a big impact on the end result. For large software projects, siloization can lead to engineers who become too specialized in a niche of the product. At GitHub, individual engineers can move with relative ease between teams. The focus of each team varies somewhat, though.
“I’m in the platform group: data backend, APIs, all that stuff. And groups within the platform team have their own primary responsibilities. I’m in Identity Management. So that will consist of like SAML, and integrations, and authentication. Then there is Platform Interface, who do the API, and they work on our GraphQL. We also have Platform Data. So there are areas of interest that make teams come together.
“In application engineering, they come up with these really fun names for their teams. So, it’s not quite as descriptive, but they have, Team Panda Rocket. But, they work on the profile, and there’s one that works on pull requests and issues, and another that works on projects. And so you can change those teams. There are areas of expertise and those teams own parts of the app but there’s definitely room to move around.“
Room to Learn
As the old adage goes, with freedom comes responsibility; a lesson Mark learned early on at GitHub.
“I was at GitHub, probably three months in. I was feeling pretty confident about my deploy. At GitHub, we branch deploy to production first, verify that everything is good, and then merge things into master because we consider master to be stable.
“We wanted to use JSON schema to verify that the incoming data was what we expected it to be, to save some clock cycles. I had created this JSON schema, and I had done it based on our tests. I deployed it, and nothing really bad was happening, so I deployed it all the way to production. I sat there and I’m like, ‘Oh, yeah. Things are pretty good.’ And then I merged the pull request, and it was all hunky-dory.
“Then we got an internal ping from Heroku, that goes, ‘Hey, our GitHub integration stopped working.’ As it turns out, I had updated the JSON schema in a way that broke our contract with API users because I followed the tests and not the documentation. I expected data to come in one way, and everyone else expected it to come in another way. So, for a hot 20 minutes, I broke GitHub integrations for Heroku. And I got my own status tweet added from Heroku: ‘Hey, we’re having issues with GitHub integrations.’”
Mark went back, reverted it and pushed it to production. He admits he was terrified. “Because imposter syndrome is so real, and I work with so many smart people that it’s hard not to have it.” He thought he was finding his footing. “And, then, you know, I broke the Heroku GitHub integration.”
Science and Progress
Not only do engineers learn from their mistakes at GitHub, but they’re often the basis for new processes to keep the same problem from happening again. And, in Mark’s case, he worked on one such project after his integration snafu.
“We have this tool called Scientist, and it’s actually open-source. If you have a new code path, but you want to make sure that the data is going to be what people expect it to be, you have the old code path, and you have the new code path. And, all you do in the new code path is just take the results and store them, and you take the old results and store them. And Scientist will compare to see if they’re correct or not correct, and it will give you a graph.
We have internal tools that let us look at a graph to say, ‘Hey, for 80 times that this happened, 75 times it wasn’t the same.” So, they built the Scientist process around the API and JSON schema. Now you can test out your schema without breaking the API for people.
“Building that Scientist process and that data gathering process around it was super helpful for me, as someone who was pretty new. And, now it’s a process that’s used every time we do JSON schemas for existing APIs, but that was a heck of a learning experience. I learned a lot out of that. It was really great.”
Growth from making mistakes, fixing them, and using them “for good,” is another key differentiator between an enterprise app the world hates and one the world loves.
An Enterprise App With Super Fans
So, GitHub is big enterprise software but built by people who are entirely invested in the success of what they make because they are also its end users. With small teams, agile processes, and data-driven decision-making they’ve built a large-scale enterprise app that attracts super-fans.
A Podcast Everybody Will Love
You can hear more of Mark’s story and more reasons why nobody hates GitHub enterprise in this podcast.