A company for hackers

Previous versions of our company struggled for a while. We spent all of our time trying to keep the company alive while marketing products that nobody wanted.

That changed recently. We now have concrete market pull and find ourselves in a strong financial position. We’re looking ahead seemingly for the first time, to new problems.

Among these new problems, we need to hire a bunch of people. We understand from prior experience that our early hires will define our company. If we make good hires, we’ll have a good company. If we fail to make good hires, we won’t have a very good company. We’re facing pretty high stakes.

But what makes a good hire? What kind of company are we trying to build? We’ve long known our preferences by instinct, but that vague intuition doesn’t easily translate into explicit language.

After more thought than is reasonable, I think I know what we’re after. We’re after a unique kind of person.

It starts with engineering

We consider our company engineering-led. The product comes first. Culture follows from the choices we make in service of the product.

Very few developers know how to build authentication software. And we must admit to ourselves that we’re not going to staff this company with experts. Instead, we need curious generalists that will eagerly throw themselves into the details and learn. That’s pretty common in mostly any business. But I have read the specs for SAML and SCIM a few times over, and they’re pretty damn dry. Almost no reasonable person would feel excited about the arcane details of enterprise software standards. We need the rare person who revels in mastering the details, the rare person who embraces the challenge.

Authentication software is really sensitive stuff. We have to meet a high standard of quality to protect our customers. Authentication software is also mostly invisible. Bugs just aren’t obvious like they are in other categories. We can’t always move fast, break things, and pick up the pieces later. We need craftsmen that take deep pride in the quality of their work, irrespective of whether anyone will notice.

Moreover, we’re a multi-product company by design. We’re building a portfolio of related products all at once. In a normal top-down company that relies on Jira tickets, this kind of breadth would require a sprawling bureaucracy and innumerable quick syncs and sign-offs. We just can’t operate that way. We need to ship product quickly. We can’t make decisions by committee. We need our developers to seize ownership and find comfort in making decisions.

Above all else, we neither want to nor can afford to manage people closely. Instead, we want people who detest management. We want people who simply love to build stuff.

Hackers

We want people who simply love to build stuff. I describe this kind of person as a “hacker.” I’m not talking about guys in hoodies gaining access to ‘the mainframe’ with four hands on the same keyboard. I mostly use the term as Paul Graham did more than twenty years ago. I’m simply talking about people who combine a particular bundle of personality traits.

Hackers – as I’ve known them – exhibit three essential qualities in the extreme: curiosity, independence, and pride.

Hackers paradoxically find the world dull and fascinating at the same time. Easily bored, hackers occupy their attention with novelty.

To these people, there’s always something new to try, something new to learn. They don’t feel intimidated as beginners; on the contrary, they feel excited. Merely for entertainment, a hacker will develop expertise in esoteric trivia. These are the kind of people who continually fall into Wikipedia rabbit holes. It’s compulsive.

By virtue of their curiosity, hackers become generalists over time. Their impulse to learn and discover really can’t be contained to a niche.

Hackers’ curiosity leads to unusual creativity. Curious minds like to discover new solutions. When familiar solutions fail, hackers just don’t get discouraged. They just … figure it out.

Hackers don’t like to cede control to other people. Self-motivated, they dislike receiving commands and resist hierarchy. They hate being ‘managed.’ To the extent they follow rules, they’ll do so because the rules (or consequences for non-compliance) make sense. It’s not because the rules are delivered with authority.

Hackers don’t typically care for status games. Their choices don’t depend very much on contemporary fashions. We can sometimes see this result in eccentric behavior.

Hackers learn over time to trust their abilities. Until faced with evidence to the contrary, hackers instinctively believe they can do anything, provided sufficient resources.

Hackers develop intense pride and high expectations. They become craftsmen. Doing slapdash work just doesn’t satisfy their intrinsic motivation. The same impulse that leads hackers to explore new ideas equally compels them to find flaws in and refine their work.

Beyond engineering

We can most easily imagine this kind of person in engineering roles. If you like to build stuff, there’s a good chance you gravitate toward engineering. But we can just as easily slot similar people into other roles across our business.

I expect that by staffing our company with talented generalists, we can defer organizational bloat and its resulting managerial overhead for a long time – not forever, of course, but for a long time.

Every business problem I’ve seen in my career could be solved by a talented generalist.

And look, SaaS businesses just aren’t that complicated. The abundance of playbooks, benchmarks, and frameworks that characterize the last decade of cloud software puzzles me, because SaaS is about as simple as it gets. If we have a sufficiently good product, the entire business apparatus basically exists to help people use it. That’s often quite difficult, but it’s not especially complicated.

Becoming a company for hackers

It’s not entirely obvious how we establish ourselves as a company for hackers in practice. We’ll likely learn things over time and improve. But we do have control over a few things.

We put product excellence first, above all else. In recent years, it’s become fashionable to favor distribution over product. With due respect to distribution’s proponents, that’s bullshit. There’s simply no substitute for an outstanding core product experience. If we build the right thing, assert fair prices, and work hard to make customers really happy, we can get away with an awful lot of mistakes.

We trust engineering to drive the roadmap. We build products for developers. Provided we hire developers with good taste and confidence, our engineering team will make the right choices. Management (i.e. me) shouldn’t insert itself between customer feedback and builders, as so often happens in bloated product organizations.

We don’t impose unreasonable process. I have never seen OKR-type planning or its variants result in greater output or superior decisions. (I have seen people invent work to tick OKR boxes). I have never heard someone speak favorably about agile methodologies. I’ve rarely ever gotten anything valuable from recurring stand-ups. Practically speaking, all of these cumbersome processes seem designed to resolve an absence of trust or ease the friction of collaboration. If we focus on product, trust people to make good choices, and minimize human dependencies, I’m confident we can slash an awful lot of procedural nonsense.

We just need to resist the gravity of acting like “a real company.”

It seems odd now, given it’s become profoundly corporate over the last 20 years, but Google’s early culture – as captured in the New York Times – feels exactly right for a company-for-hackers:

Mr. Brin and Mr. Page, who share a dry and impetuous sense of humor, have also cultivated an impudent culture, as if nerds had taken over a college dorm. Programmers work by the light of lava lamps into the wee hours of the morning, taking breaks to ride motorized scooters down the halls and eat spicy meals prepared by the house cook, Charlie Ayers, the former chef for the Grateful Dead.

This bitbucket bonhomie has resulted in a steady stream of nifty features, like a rather unusual approach to fixing users’ spelling errors. Instead of a predetermined dictionary, it looks for correct spelling in its index of the entire Web. That means it can propose correct spellings to proper names, and it works in 74 languages, most of which no one at Google has ever spoken. Or in some cases, no person anywhere has ever spoken: Google runs versions of its sites in a few languages that no one has spoken, like Bork Bork Bork, purported to be the tongue of the Swedish chef on ‘‘The Muppet Show.’’ The company is so infatuated with its technical prowess and sense of destiny that it has developed a reputation as being difficult to deal with.

Bear in mind that this company – as described – had reached nearly $100M in annual revenue. A company for hackers can be built, and it can become highly successful.

Google’s founders made some non-obvious cultural choices. They did an awful lot of silly stuff, much of which didn’t make any sense. And it was all fine. Actually, it was more than fine. They brought on exactly the right people they needed to build an extraordinary product. Around that product formed an extraordinary business.

I hope we can capture a small fraction of the same energy.