Category Archives: Culture

2 Takeaways From GitHub Running a #NoManager Company At Scale

Zach Holman has been giving presentations on how GitHub works for the last couple years. If you’re not familiar with GitHub’s organizational structure, they don’t have any managers and they are mostly remote. It’s been pretty fascinating to watch them grow up with this structure and I’m grateful to Zack for sharing their journey along the way.

The last time Zach presented an update, GitHub had about ~75 employees. They’re now up to 217.

Here are my takeaways from Zach’s latest presentation:

1. Retention Rates Are Ridiculously High

As far as I’m concerned, this is the only slide that matters.

How_GitHub__no_longer__Works

199. That’s the number of people GitHub hired before a single person quit. 

There are two mission-critical reasons you need to care about cultivating a developer-friendly culture. First, culture is a form of advertising that can attract the best people you can afford. Second, living the culture that was advertised should retain those people for as long as possible.

GitHub literally had 0% voluntary turnover for years. This is mind-blowingly awesome and the #1 reason tech-focused founders should take a really close look at whether or not they should build a company without managers.

2. Managers May be Be Optional, But Leaders Are Not

Zach revealed that they now have teams:

How_GitHub__no_longer__Works

The slides don’t explicitly tell us how the teams are organized, but from what I can infer it seems like people can join or leave a team based on their interest in what the team is working on.

Some teams have a “Primarily Responsible Person” whose main job is to provide a vision:

How_GitHub__no_longer__Works

Vision is a function of leadership. In early-stage no manager companies, the visionary should be the founder(s). Even though leaders won’t tell employees how to do their work, they should tell them when something doesn’t fit in with the company’s mission or vision. 

When the product functionality and headcount swells, it makes sense to bring in product/team-level leaders. They can inspire others to see the big picture and offer the doers a way to know whether or not that new thing they want to work on next will push the company closer to achieving their stated mission.

For example, Treehouse recently went to a no manager structure. Here’s how they handle the mission and vision (source):

Who decides company-wide priorities? Who sets the general direction for the company?

Alan and Ryan (the Co-Founders) are actively steering the ship and setting company-wide goals, our Mission Statement and areas of focus.

What are the Co-Founder’s roles in this new system?

Ryan and Alan are still very much leaders of the company. They will decide on company-wide goals, make sure our Mission remains relevant driving force, and keep our current areas of focus updated.

This makes sense for Treehouse, but every company and every founding team is going to be different.

Watch the Presentation

The whole presentation + slides is available here. It’s definitely worth the hour-long investment.

Google People Operations

This is an awesome description of the ideal role of HR in a technology-centric startup:

Made up of equal parts HR professionals, former consultants and analysts, we’re the champions of Google’s colorful culture. In People Operations (you probably know us better as “Human Resources”), we “find them, grow them, and keep them” – bringing the world’s most innovative people to Google and building programs that help them thrive. Whether recruiting the next great Googler, refining our core programs, developing talent or simply looking for ways to inject more fun into the lives of our Googlers, we bring a data-driven approach that is reinventing the human resources field.

Yesterday Ryan Carson shared this article on how Google does managers, which is all sorts of awesome as well.

Everything that Google has learned on their own is consistent with the best practices that we have available to us in the research literature. My company already has a data/evidence-oriented culture and we have developed similar tools that Google uses to assess and develop their managers.

This makes me wonder if we could position ourselves as “PeopleOps as a Service” to bring many of the benefits that Googlers are enjoying to everyday startups.

(via People Operations – Google Jobs.)

My Mission and Committment to Transparency

My team and I are on a mission to change the way companies are managed. I feel a bit absurd saying it out loud, but it needs to happen and we’re in a great position to do it.

We’ll be consulting, coaching, writing a book and building a suite of SaaS products that will enable startup founders build “no manager” or “minimally invasive manager” companies. We believe these management structures will soon be the only options available to startup founders that want to attract and keep the very best people.

Traditional advice and management books won’t help you navigate through all the challenges you’ll face while baking these innovative management styles in to your culture, but we can. My cofounder and I have been working with established companies for a combined 42 years. We have extensive expertise and understand the science behind hiring, firing, coaching, feedback, compensation and measuring performance.

Instead of traditional customer development, I’ll be blogging about what we’re doing with as much transparency as possible. I plan to explain what we’re doing as we’re doing it so I can help you understand the “why?” behind the decisions we bake into our products and services.

I gave this “transparent development” thing a trial run a couple weeks ago. I built a premium newsletter service in a week and live blogged the entire process. I wrote 26 posts outlining every single decision with complete transparency. The blog has been a great way to bring customers closer to the product and help them understand why I made the decision I did. The response is overwhelmingly positive.

I’m looking forward to taking a similar approach here at Great Companies as we build tools and products that help startups build great companies with happy and highly productive employees.

Sign up using that form below to follow our journey and get some discounts when our book and other products are ready for launch.

When Product Development is Better Than Customer Development

The Lean Startup movement and its reliance on customer development and validated learning is great, but it doesn’t make sense for every situation.

If I have cancer, I don’t want my doctor to ask me if I’d pay for a particular solution to cure my cancer. I want my doctor to tell me how to get rid of it in the most effective way possible given their experience and knowledge based on their access to the latest research, techniques and medicines.

Serious Pain Sometimes Requires a Prescription

If you’re an entrepreneur with deep expertise in a particular domain, sometimes you already know that a particular pain point exists. You don’t need interviews to confirm the pain.

And sometimes your domain expertise allows you to understand whether or not you have a solution to the pain that is better than anything being offered. You know everyone hates the solutions that exist, but customers are stuck because there isn’t anything better to choose from.

And sometimes you know your potential customers are willing to pay for existing solutions designed to fix their pain (even though it doesn’t) at a price-point that you’d be happy selling your superior solution at. You don’t really need to bother with the “would you pay $10 if I could take this pain away?” type questions.

If this is the case then whole-hog customer development feels like a round peg/square hole kind of situation. A prescribed solution may be in order.

Customer Development Isn’t Always The Answer

37 Signals built Basecamp and launched it as a fully functional product to solve project communication problems. They didn’t ask what we’d pay and they didn’t ask if we wanted it. They understood the pain that some project managers felt every day and they built something to take away that pain.

Amy Hoy built Freckle and launched it as a fully functional product to solve agencies’ time tracking problems. She didn’t ask what we’d pay and she didn’t ask if we wanted it. She understood the pain that some agency owners felt every day and built something to take away that pain.

Apple built the iPhone and launched it as a fully functional product to offer the greatest technological advancement of the century. They did it again with the iPad. They didn’t ask us what we’d pay or if we wanted it. They understand the pain that we felt with our phones and built something to take away that pain.

There are countless other examples, but you get the point. What all these examples have in common is that the creators used their domain expertise to identify a real pain point, they had strong opinions around the best way to alleviate the pain and they had the ability to create great products to solve those problems.

I’m Leaving Customer Development Behind (at least for a while)

My team and I are creating products designed to help founders build great companies and ease the transition from founder to CEO. I’ve been trying to follow the lean startup methodologies and ask what founders need to solve the pain, but today I realized it doesn’t make a lot of sense for what I’m working on.

The pain that founders experience around leadership and management as they build their companies is very complicated. It’s very real and I don’t need interviews to confirm it. The solutions are even more complicated than the pain. A decision you might make today around compensation policies or culture because it seems neat or trendy can have adverse effects that don’t show up for maybe 10 or 50 hires down the road.

Asking a founder what they need to solve their leadership and management pains is sort of like a doctor asking cancer patients how they want to cure their cancer. Asking them if they’d rather pay for chemo, radiation or both is just as ridiculous.

There is no panacea for building a product (or business). My approach to what I’m doing and this blog are about to change. Stay tuned.

Remote Working Works

HP recently pulled “a Yahoo!” by ending their remote working arrangements with employees. Justin Jackson had this to say about the Yahoo move:

The only time a manager should fear a flexible workplace is if they’ve hired the wrong people. If you’ve broken Rule #1, all bets are off. It doesn’t matter what kind of office you have; mediocre people create mediocre results.

A few years ago our lead developer  had an opportunity to move to Australia for a 3 years, all expenses paid. His partner received an incredible job offer in Sydney for a three year contract and her employer was willing to pay for him to go with her (we’re in California).

It was an uncomfortable decision, but I gave my blessing. And then he did everything he could to make sure it worked out perfectly. That meant he had to work mornings and evenings with a break in the middle of the day every day to keep his internal customers happy and the team on track. He made it happen.

He’s back in the US now and everything worked out fine. I agree with Justin. Our team is currently scattered all over the world and it doesn’t bother me one bit. If you have great people, and you’re able give them the support they need, remote working works.

Why Your Startup Needs to Obsess Over Culture

Alex Turnbull, CEO/founder of Groove, gets It:

But we also have unique opportunities that our larger cousins don’t have: we’re agile, company-wide changes don’t take nearly as long to test and implement, we’re working from the ground floor, which puts us in a position to build the entire foundation of a great culture from scratch, setting ourselves up for success as we scale. It’s a lot harder to build a culture at a big company where employees are more set in their ways.

I couldn’t have put it any better myself. This is why I started this blog and developing some tools to help startups establish and build great companies with great cultures.