E-Mail Transparency and Other Culture Hack Tips from Patrick Collison
Patrick is the founder of Stripe, the payments company. When Stripe was a two person company, he and his co-founder decided that to maximize communication, they should receive each other’s email — in other words, they’d share an inbox. Although this is not sustainable now that Stripe has more than two employees, the company still uses e-mail as a primary communication medium by employing mailing lists — over a hundred of them — for all sorts of topics. Collison said that one of the first things that new employees are taught to do is to set up Gmail filters.
Patrick spoke without slides at all, which made it difficult for me to write down the salient points of his talk. I think eventually it ended up being a list of “culture hacks” that he helpfully posted on a HackPad that anyone can edit. I invite you to visit it and see what ideas he and others have had for “hacking a culture”.
Hiten Shah of KISSMetrics on Avoiding the Founder Bomb
The “Founder Bomb” is when a founder hears about, or thinks up, a really good idea (or what they think of as a really good idea) and then starts calling random people in the organization to ask them when that idea will be ready, often talking a mile-a-minute. Since a founder’s ideas are often seen as 50x more powerful than others’ ideas, this kind of disruptive behavior causes panic and anxiety in companies. Hiten says he’s had to dial that back to avoid cheesing people off.
Knowing what team members are up to is important, though, so Hiten boils it down to two questions that he might ask any given person: what are you working on, and why are you working on it? The answer to the last question should be tied to some business objective and not just “because my boss asked me to do it”. “There are a lot of reasons why people work on things in a company”, Hiten said, “but their explanation of that is even more insightful.” Also, shipping often is not enough. Your company has to ship the right things.
On that note, Hiten jumped into an amalgam of advice about product management and building good teams.
- No matter what your product is, whether it’s Foursquare or even Chef, ultimately it’s created by people for people, to quote Sam Schillace of Box.
- Keep team sizes small. Hiten’s teams are like Amazon’s in that they abide by the two-pizza team rule: if more than two large pizzas are required to feed your team, it’s too big.
- Use a “cauldron” to bubble up the best ideas. Put all your ideas in there and ultimately they will surface.
- Companies talk too frequently about features and don’t do enough analysis of the problems that people actually have. Put another way (this is stealing from Josh Elman): The ultimate goal of building a company is to have the right product thesis at the right time. (An excellent resource about building the right things is The Entrepreneur’s Guide to Customer Development.)
- Finally, work backwards. Hiten says they’ve stolen Amazon’s idea of literally “writing the press release first” when conceptualizing products. Imagine six months or a year from now when you’re about to launch the feature. What will the press release say? Write it, then build to that.
Scott Chacon on Running a Distributed, Open-Source Business at GitHub
GitHub is a company that has more remote employees than ones at its San Francisco headquarters. Chacon put up a map of where all the GitHubbers live and it covered something like 40 countries. Obviously, their company culture has to reflect this in some way.
Chacon says he tries to have GitHub emulate some of the best features of open-source projects. In an open source project:
- there are no meetings
- there are no offices
- there are no work hours
- everything is done asynchronously
- workers self-assign tasks (e.g. Linus doesn’t tell you what to work on)
- there are maintainers, not managers
- everyone contributes ideas
As they’ve built GitHub from the original core group, they’ve tried to hew as closely to these features as possible. To clear up a popular misconception about “GitHub having no managers”, Chacon says, it’s not that GitHub banned managers or fired the ones they had. If hiring a manager was the best way to solve a problem, they would do so, but so far have seen no need to hire any because they have been able to achieve their goals without any.
Chacon then moved to the topic of offices. An office serves as:
- A place to work
- A place for creative collaboration
- A place for serendipitous interactions
- A place to meet the suits (VCs, lawyers, etc.)
- A place to nterview & onboard people
- A place to physically ship things to and from
- An event space
He then asked, do you really need a permanent place for all of this? The answer is… maybe. It helps to have an office, Chacon says, but people have to choose to come to the office because they feel it’s more productive than to not do so. Other than that, coming to an office should really be optional.
Chacon closed on a couple of points having to do with schedule, autonomy, and meetings.
- Schedule: Why have work hours? Many enterprises enforce work hours, arguing that it’s needed for collaboration. But how much is needed? How often do you really need to meet in person? (Later, during Velocity, Mark Imbriaco from GitHub gave a talk on ChatOps that demonstrates that, at least as far as web ops is concerned, GitHub is doing a fine job running the entire operation via a Campfire chat room.)
- Autonomy: Chacon argues for more autonomy — letting people do what they’re going to do, saying that the ore of this you do, the more diversity you’ll get. I’m not sure I buy his argument; while autonomy is good, at some point there has to be guidance to make sure that people are just off working on science projects without direction.
- Meetings: Chacon argued against meetings because only certain types of people “win” meetings: those who are the most aggressive, or co-founders, or extroverts. It’s a pretty harsh argument, and I don’t think even Michael Lopp of Palantir (who spoke later in the day on this topic) would agree wholeheartedly with this, but it is true that meetings tend to favor outspoken individuals.
Patty McCord on Being Honest
Patty McCord is a legend in Silicon Valley, having worked in management positions for Netflix, Sun Microsystems, Borland, etc and being the author of the infamous Netflix Culture document. She’s quite blunt about the failings of human resources organizations and how to manage people. Honestly, I’m not a huge fan of the take-no-prisoners throw-anyone-under-the-bus-for-the-product way of doing things in Silicon Valley; I’ll give you some examples of things that she said:
- Product and company come first. People do not. All the talk about culture is bullshit unless you have money.
- Sound judgment trumps all written rules.
- The word “empowerment” is garbage. Everyone is already empowered, in that everyone already has “power” — you just have to use it judiciously. (I’d beg to differ in a large, slow-moving, bureaucratic enterprise organization.)
- Fairness is not the same thing as consistency. McCord says that the latter is unimportant.
- Tell the truth to your employees about how you’re doing and how they’re doing. The former encompasses sharing the company’s financial state with staff. The latter means being blunt to employees about their performance; “performance improvement plans” are HR bullshit and simply ways to shield the company against being sued, but people only sue if they’ve been lied to (telling them that they can improve their performance via a PIP if they are patently incompetent).
Of all the talks, I found this one the most objectionable. The way a Silicon Valley startup runs is clearly much different than the way a Pacific Northwest startup runs, or even a New York City startup. But whatever works, I guess…
There was one more presentation from Michael Lopp, author of Being Geek, but I missed part of it and didn’t take notes.
Overall, I found Cultivate to be an excellent conference, and the speaker lineup was stellar. Not every speaker agreed with the next, which was quite refreshing, because who likes a monoculture? Ultimately, technology leaders have to develop their own ideas for how to run their teams and shouldn’t just copy others.