I had a chance to chat with the dashing and determined Mr. Steve Smith recently. His company, Ordered List, was acquired by GitHub in 2011 and since then, he and his fellow coworkers have been focused on creating new products such as the latest release of GitHub for Mac, support tools, internal analytics, improving Speaker Deck, and more.
We’ve been talking a lot about flat teams at nGen over the last year and a bit. So chatting with Steve was fascinating because Ordered List was a flat company that employed five people, and of course, GitHub is flat and employs 148 (as of this writing). Quite a spread.
Naturally, I wanted to know about the mechanism behind that flatness. How do things work? Does it matter how big or small your teams are? What’s important where you work? What happens when things get tough? Steve gave me so much to work with I probably could have written a short novel, but then we’d have to work out royalties and I’d have to put up fake pictures of him in sparkly drag to test his loyalty—he does have great hair.
Instead, I decided to lay out the teeth and bones of being flat at GitHub so you could see how large companies are doing flat these days.
Some Things You Should Know About Steve
- He’s got a wicked sense of humor.
- He’s from South Bend, Indiana, which should never be confused with Silicon Valley.
- In 2007 he formed Ordered List with his pal John Nunemaker and later added Jonathan Hoyt, Branden Keepers, and Matt Graham to the mix.
- Together they created cool stuff like Speaker Deck and Gauges which caught GitHub’s attention.
- “When a company like GitHub comes around and shows interest in what you do, well—you get pretty excited.”
Some Things You Should Know About GitHub
- It’s the most popular open source code repository site for developers.
- In five years, it’s already hit its 3 million user mark and is valued at over $750 M.
- It’s a people company, which means that the people that use the products and the people that make them come first.
- It has no hierarchy: there are owners, but no managers. There are business operations and shareholders, but no profits before people.
- It has been growing steadily and hires folks from all over the world to work at the office in San Francisco or remotely.
Here’s where I pick Steve’s brain. He didn’t complain once…
Rachel: Can you help me understand the integration of Ordered List into GitHub? How do you work and how does that fit in with the greater GitHub environment?
Steve: GitHub was very interested in us as a team who built software. They were really interested in both Speaker Deck and Gauges and how they could apply that to what GitHub’s overall mission was. There was never pressure to take things and shut them down. They were interested in anything we wanted to do to make our products, or GitHub in general, a better place. They didn’t come at us with a specific list of things we would be doing. It was more like, “You’re a member of the family now so continue doing whatever you want to do…” The five of us (at Ordered List) still work together on some things, and on other things we’re very autonomous, but we always talk with each other all the time. It’s been a good family experience. It’s the only way I can put it. It’s semi-organized chaos, which takes a little time to figure out, but once you do, it produces some pretty awesome stuff.
Rachel: How do you decide who works on what?
Steve: People always wonder, ‘How do you know what to do?’ and the answer is that we just decide and then do it… We’re building software for us—stuff that we enjoy, and that we think is going to be great for the people using it. Rather than doing work to satisfy a boss, we find ourselves doing the coolest, best, most ridiculous work we can to impress our friends who work with us. Of course there are all sorts of discussions, and the larger the team grows—I’ll even just say it—the more difficult it is to decide a given direction. When you have any number of people who can do any number of things they want, trying to keep that cohesive, I think, has been the biggest challenge.
Rachel: Are you a distributed team, or do you colocate in the same place?
Steve: So we have an office and we’re partially colocated in San Francisco. About half of the team works there now. I would say that GitHub encourages anyone who doesn’t live in San Francisco to come and work at the office, but it is not a requirement by any means. I believe there is value in being in the office. I love going myself, but it is obviously a better situation for people (as you can see from our [remote] team) and whatever’s going on in their lives—be it family or the desire not to live in the city—that they don’t move. They still add value to the company and are still a great asset to have. Talented people come from all over the world.
If you can set yourself up so that being distributed is not only possible, but ultimately functional, it’s only going to be a better situation for you.
When answering an important question, always lean in.
Rachel: Would being required to move to San Francisco have been a determining factor for you to join GitHub?
Steve: There’s no way it would have happened—at least three of the five of us would not have gone. I can’t move to San Francisco. It’s amazing to work remotely and work where you’re comfortable. What’s great is that even the people who live in San Francisco, a majority of them work from home a couple days a week. On a typical day with a company of around 150 employees (my math might not be right on this, by the way), 70 of which live in the area, there might be only ten or fifteen people in the office at a time. You have some people who come in the morning. You have some that come in at night. There is no set schedule … We can’t have this concept of face-to-face meetings or phone calls. You can’t hire someone from Australia and expect him to work on a U.S. time schedule because that’s not good for him.
Rachel: Are there certain qualities that people on flat teams have to have—or be on board with—that fit the model?
Steve: Absolutely. I think the biggest, most important aspect of having a flat team like we do is fitting into the culture. You have to be a certain type of person. You don’t have to be an introvert or extrovert. It’s about a willingness to communicate, a desire or passion for what you do; a passion to constantly get better at what you do; being able to take criticism well.
The funny thing is when we hire people, their work is probably already on GitHub, so it’s easy to tell someone’s technical ability. And when I was looking to hire people at Ordered List, I always said: people can learn new schools in a technical environment, but no one’s going to become less of an asshole. It’s all about personality; if you’ll jump in and contribute right away. But more important is that you get along with people. It’s very much a culture fit.
We spend most of our hiring time just talking to people. When we interview, a lot of the time it’s just random people who are in the office or whoever wants to have a Skype conversation with the potential hire. It’s not about programming. It’s just talking about your life and what you’re interested in and seeing if this person is someone I could get along with because that’s what you’re going to have to do on a daily basis. You can’t have a distributed team without communication—although I would say you can’t have a colocated team without communication either. Being able to handle that level of freedom and that level of trust and getting along with your teammates is the most important thing to us. Ultimately, you end up becoming friends because you hire all these awesome people who are passionate and can talk. You hang out a lot!
Rachel: When you have a flat team, you don’t have anyone standing in and saying, “These are the expectations; these are the things you need to do within a given timeframe.” So, how would you say GitHub emphasizes accountability on a team?
Steve: We definitely take the approach at a more proactive level. I don’t think it’s anyone’s job to look around at people to see if they’re doing well enough. I see people who have struggled in the past with the unwieldy freedom. You tend to see those people and have questions like, “What has that guy been doing for a while? Has anyone heard from him?” We love to ask people what they’re working on, and if someone is having a difficult time you ask if they want to help you on your project.
There are times when you are going to have a project and you are going to be gung-ho and working crazy hours. There are times when you’ll have a hard time knowing what to work on, so if you continue in that communication cycle, you’ll always find a place to hook back in.
We also encourage you to take vacations and get away from the computer. Just go. Away! Take a week or two and free your brain a little. We recognize there are all sorts of working styles. There are probably people at GitHub that are sitting down at their computer less than twenty hours a week, and that’s fine as long as your producing, contributing; as long as you’re doing something. Whether or not it gets used, you have to finish something. The worst thing you can do is start a bunch of things, get halfway through, quit and start something else. You’re not going to be happy. Ship stuff.
A designer’s tools are his hands. Every effort must be taken to protect them, especially while traveling.
I’d like to think if you get into the area where someone needs to sit you down and talk to you about contributing, it’s been a long time coming. We constantly are working with each other to communicate on a daily basis. And we’ve had to let some people go. The disappointing part is realizing that we made a mistake hiring them in the first place. It’s not like they were great once and then suddenly got worse. We just didn’t do a good enough job figuring out that this wasn’t the best place for them to thrive. We feel bad and we feel disappointed in ourselves.
Rachel: GitHub started out flat from the get go. Do you think that in a more traditional structure, people can transition to and ‘go flat’?
Steve: I think it would be difficult to do unless you have a buy-in from everyone on the team. If we had twelve managers and wanted to go flat, we’d have to be like, “So you guys, I don’t know what you’re going to do now. We don’t really need you anymore—.” I don’t know how you’d handle that as a company [laughing].
In a top-down structure in a company, a lot of times you have this concept of senior level and junior level programmers, so you hire people who are entry level and they work up through the company by getting better and then they work up into management. In a flat company like GitHub, there’s no concept of moving up, because no one is going to take responsibility for you, no one is telling you what to do or holding your hand while you do stuff. Everyone has to be great at what they do. I think that’s really hard to transition into that. I’m not saying it’s impossible, but it would be a very difficult thing to do without the whole company buying in. I think if you had the CEO of a company suddenly decide to go flat, it would be chaos. And maybe that level of chaos is fine for a little while…
Rachel: If you had the CEO of a multi-trillion-dollar company approach you and say, “Steve, you’ve got the chutzpah. I really like what you’ve got going on. I would love for you to manage a team of 250 people. There’s going to be a pyramid structure in there, but you’re going to have ultimate control and influence. All you’ll have to do is report back to me. I’m going to pay you net 2.7 million every year.” Would you do it?
Steve: Wow. [pauses] If I did it, I would hate it. It sounds miserable to me because what I love to do is build stuff and managing people is not that much of a strength of mine. If you really want to learn more about that you can talk to Hoyt and Brandon and Matt. I love to design and build software. Right now I’m working with the GitHub for Mac team, so I’m designing actual Mac software for the first time in my life.
Many parts of the GitHub for Mac UI are getting a new coat of paint.
We have this concept for ‘team’ at GitHub. We like to say: “Never work on a project alone because there is this flat structure and an absence of someone checking in on you. For your own sake, don’t work alone on stuff.” It gets really boring and difficult. It’s hard to finish things. It’s hard to do it well when you’re on an island. I just joined the Mac team in 2012. There’s no manager; you just sort of jump in, and the tools for doing that at GitHub are huge. Your company has to be set up to have that type of communication.
It takes a huge amount of trust and respect and the ability to recognize that [the founders’] concept of what GitHub is and can be on its own is smaller and weaker than what it could be collectively.
Rachel: Do you have any tips for clarity on text based communication?
Steve: The only thing so far that has affected improving text based communication is to meet someone in real life. When you’ve met them and hung out and gotten to know them, it’s so much easer to understand their voice when they’re typing. Twice a year, GitHub flies everyone into San Francisco. Everyone comes and hangs out for a week; we do things like lightning talks. We just do fun activities together and get to know people on a personal level, so when you’re in a chat room I don’t interpret you saying, “I don’t know if that’s good enough,” as you being an ass.
One of our guys in Spain, he was very blunt in chat and email. Until I met him in person, I just thought he was an ass. But then I went to a summit and met him and went, “Oh! You’re not an ass, you’re actually hilarious and one of the nicest people I know. This is just how you talk. I get it now.” And so now I understand where he’s coming from. I think it’s really important to have face to face conversations but notin the context of work.
A new season of GitHub dodgeball has Steve and his buddy Matt Graham excited. Oh, short shorts.
Rachel: I was just thinking how traditional industries do their power lunches and their stand up meetings and one day, if they were like: “We need better communication guys; how are we going to do this?” Then you were to walk in and say, “Well, let’s talk—but not about work and let’s not be at work when we do that.” Can you imagine how that would flip their world upside down?
Steve: Even in that context, with that hierarchical setup, whatever you’re doing, you’re still going to the bar with your boss. Traditional hierarchy doesn’t set itself up well for socializing like that which is why most of the time it doesn’t happen and is frowned upon. I’m not going to go to a bar and get buzzed with my boss. That’s just weird. But all we do when we hang out together [at GitHub] is we have fun, we drink, and we play games. Last year everyone rode roller coasters during one summit. It totally depends on the people. You have to have people that are social and communicative.
At GitHub, lots of people like to DJ techno. Lots and lots of techno.
Rachel: Do you think then that there are certain types of industries where this flat team structure wouldn’t work?
Steve: The only ones I can think of are ones with legal checks and balances, like maybe the medical industry would kind of suck in a flat structure. There’s always that threat that someone is off on their own doing something that is completely out of line and kills someone.
But I think for most things, happiness in what you do is always going to produce better stuff. Happier salespeople would sell better. Happier factory workers would do more effective work. We found that at GitHub our CEO would always say, “We optimize for happiness” in every way. For our customers and for us. Anywhere we can make someone happy, we do our damnedest to make it happen.
Rachel: Do you do any peer reviews or is it more ongoing evaluation?
Steve: It’s just day-to-day. There’s this feeling because we all know each other and we’re all friends, and communicate with each other, we do look out for each other. Maybe someone is just going through some bad stuff in their life right now and that’s fine. As friends of theirs, how can we help? Whatever we can do to help you move along and help you get better, we will do. It comes back to that family aspect. The culture that we have is very familial. It’s very friendship based; it’s very respect based. I feel like that’s the most important thing for having the kind of team that we do, because everyone has to be on board together.
Rachel: So, how do you compensate hard work in a flat team or flat company?
Steve: To me, you just have to make sure people are happy making what they make. You have to pay people well; you just have to take care of everything people can worry about. You’re not going to pay more than they’re worth, technically, but you can’t scrimp.
You have to make feel people feel valued and one of the ways to do that is through salary. Some of it’s through benefits, some of it’s through technology or toys—giving them computers and access to the devices that they want. Whatever you can do to help take care of that stuff for people is only going to be better. If you pay people correctly (I should say, what they’re worth) to the point where they’re not looking at other jobs…I don’t need to look around—I’m doing fine. I’m happy and I’m doing my work.
I’m never worried about my family getting sick, or anything that could possibly happen because my insurance is taken care of and it’s not coming out of my pay check. That’s an additional benefit. It’s amazing how freeing mentally that is. It’s another thing I don’t have to think about and it frees up my mind to do other things. I think it’s an intangible; you can’t really measure it, but it follows that it produces better things.
I’d like to think that it sort of rolls around on its own. People are more productive, the company is more profitable, and it sort of just snowballs at that level. At this point in GitHub’s timeline, we’re providing more benefits. They added 401K this year. We don’t have to come up with a bunch of cash to make shareholders happy … Our investors are on board with what we do.
Rachel: It sounds like this is about feeling connected and passionate about the things you do, and then out of that comes amazing work. So instead of, “Go to your job and do your job and then meet people you may or may not get along with,” it’s, “Put everything else first, and create things you love to do as a result.”
Steve: Absolutely. Again, it’s about optimizing for happiness. Do everything you can to make people happy. Exude that sort of attitude in the work that you do. For our customers we use terms like ‘surprise and delight.’ What can we do to make them happier, so they can go, “Ha! Woah, that’s awesome”? We love what we do and we love who we do it with.
I’m pretty sure Steve just found out he doesn’t get to order sushi for lunch.
Rachel: So Steve, on this final note, if you had to sit down with somebody who did have a more traditional perspective—maybe he was trying to shift the way that he worked or joining a company that was flat—what would you tell him to get him to see the big picture?
Steve: I think the encouraging words would be, “it’s okay to let go…”
I have the hugest respect for the founders of GitHub who built this amazing thing and hired 150 people and have said, “Do whatever you want with it.” It takes a huge amount of trust and respect and ability to recognize that their concept of what GitHub is and can be on its own is smaller and weaker than what it could be collectively. And I think that’s really hard to do. As a person who started and ran a company and designed and built products on my own, I can vouch that it’s incredibly hard to do. But it’s going to be okay.
Hire the right people, keep them happy, and great stuff will happen.
Rachel: That’s some pretty powerful stuff, Steve.
Tools At Work
A short list of tools the folks at GitHub use to make their days a spot easier.
We use Campfire by 37signals. We utilize many, many different rooms to keep conversations focused and searchable. We have desktop and mobile clients, so we can communicate on the go.
An internal twitter-style application, with web and mobile versions. We can push chat mentions, team statuses, and any other relevant information directly to people’s phones, as needed.
We can also post new ‘Ideas’ that can receive feedback from any employee to facilitate broad company-wide discussion.
We obviously use GitHub.com to develop our software. We make heavy use of Issues, Pull Requests, and code comments to have a record of any conversation around building applications.