Mike Curtis may not have the typical background of someone dedicated to vanquishing bureaucracy. AltaVista, AOL, Yahoo, Facebook — he’s a veteran of some legendary Silicon Valley behemoths. Now VP of Engineering for Airbnb, he’s at the helm of a small but rapidly growing team. With nearly two decades of innovation at tech giants under his belt, he’s become an expert at chopping through red tape.

As it turns out, one simple lesson guides Curtis’ approach to building effective teams: the antidote to unproductive bureaucracy is good old-fashioned judgment — having it, hiring for it, and creating conditions that allow people to exercise it. Armed with this truth, he’s tackled the challenges of scaling a world-class engineering team at Airbnb, from taming the beast of expense reports to dramatically improving site stability. And he’s done it by eliminating rules, not making them.

At First Round’s recent CTO Summit, Curtis shared actionable tactics for what he calls “replacing policy with principles” that can guide fast, flexible growth and progress. Every startup looking to dodge a fate dictated by increasing structure and processes that inevitably slow you down can benefit from these tips.

To start, Curtis’s definition of bureaucracy (when it comes to startups) isn’t one you’ll find in the dictionary:

bu•reauc•ra•cy n. 1. The sh*t that gets in your way 2. the sh*t that gets in your engineers’ way

The curious thing about organizations is that having more people somehow doesn’t equal more output. “As size and complexity of an organization increases, productivity of individuals working in that organization tends to decrease,” he says. As headcount grows, so too does the policy-and-paperwork stuff that gets in the way of rapid iteration and scale.

Why is this the case? “I think it comes down to human nature and the way we react to problems,” Curtis says. Our natural response to any problem — from a downed server to a social gaffe — is to try to ensure that it doesn’t happen again. In companies, more often that not, those solutions take the form of new policies. “What happens when you create a new policy, of course, is that you have to fit it into all of your existing rules.” And so begins a web of ever-increasing complexity that’s all about prevention. Soon, you start to hit safeguards no matter what it is you’re trying to do.

To avoid this type of bureaucracy from the very beginning of your company, you should adopt two particular tactics: “First, you have to build teams with good judgment, because you need to be able to put your trust in people,” Curtis says. “Then you shape that good judgment with strong principles.”

Build a Trustworthy Team By Hiring Trustworthy People

Minimizing rules that become roadblocks in your organization will only work if you’ve built a team that will make good decisions in the absence of rigid structure. Your hiring process is where you can take the biggest strides toward preventing bureaucracy.

The most important question that you have to answer when you’re hiring somebody is ‘Is this person going to be energized by unknowns?’

No company will ever achieve perfection, ever. So when things break, you want people who will be motivated by solving problems — those are the people who won’t pause to place blame, and blame is wasteful. Even if you have a honed process for screening and interviewing candidates, it’s worth revisiting how you test for culture fit to make sure this is part of it.

Too many companies and engineering leaders are willing to compromise to maximize technical savvy. Do not do this. Curtis recommends allocating at least 45 minutes to an interview that is entirely about culture and character. Diversity of backgrounds and opinions is championed at Airbnb, so ‘Culture fit’ is about finding people who share the high-performance work ethic and belief in the company’s mission. If people don’t share your conviction in the company’s success, they aren’t a fit.

At Airbnb, Curtis found that these four moves truly extract the most value out of this type of interview:

• Let them shine first. For the first 15 minutes of your culture interview, let a candidate describe a project they’re particularly proud of. The idea here is to get a sense of what excites them — is it technical challenges, for example, or perhaps personal interactions? “Try to suss out what gives this person energy,” Curtis says.

• Then make them uncomfortable. The other side of that coin is that you want to learn how candidates react when they’re not excited, too. Ask them about difficult experiences, or moments when they were somehow not in control. Some of Curtis’s go-to questions are:“Describe a time you really disagreed with management on something. What happened?” and “Think of a time you had to cut corners on a project in a way you weren’t proud of to make a deadline. How did you handle it?” This exercise is all about reactions. “Does the candidate start pointing fingers and say, ‘This is why I couldn’t get my job done, this is why this company is so screwed up’? Or do they start talking about how they understood another person’s point of view and collaborated on a solution?”

• Calibrate your results. It’s easy to see if someone nailed a coding challenge. It’s a lot harder to get comparable reads on candidates when you’re working with a group of different interviewers. It takes time to get on the same page, but you can help the process along. “We get all our interviewers together in a room and have them review several packets at the same time to help expedite the process of getting to some kind of calibration on what’s important to us,” Curtis says. Essentially, try to make the subjective as objective as you can.

• Watch out for signs of coaching. If a candidate seems to have uncanny command of your internal language, take note. The public domain is exploding with tips and tricks from past interviewees and journalists. “Especially as your company starts getting more popular or well-known, there’s going to be a lot of stuff about you out on the Internet. If people start quoting things to you that they obviously read in an article or something that is your own internal language, they were probably coached. They either read something or they talked to somebody who works at the company,” Curtis says. That’s not to say you should reject them immediately, just don’t let yourself be swayed.

Make the Most of First Impressions

Ideally, your culture interview ensures that you’re hiring a diverse set of people who share your beliefs and work ethic while introducing new ideas and perspectives. Once they’re in the door, you have your next key opportunity to establish shared priorities. “Your first week is the chance for you to set expectations with new engineers,” Curtis says. He’s found that adding a few key elements to the onboarding process pays off big down the road:

1. Remind new hires they’re working with the best. “I talk about how many people applied for their position so they understand how competitive it is to get into the company and that they’re working alongside great people,” Curtis says. Beyond its morale and excitement boosting value, this is an effective way to build a sense of urgency and ensure that new hires hit the ground with positive momentum.

2. Emphasize the value of moving fast. At Airbnb, Curtis’s direction to new engineers is to ship small things first. That can be an adjustment for people used to working on huge systems in their last gigs, but it’s proven to be a valuable way to build that all-important shared judgment. “Get a bunch of code out the door, learn how things work, then you’ll ship bigger stuff,” he says of new hires.

3. Make imperfection an asset, not a liability. Share what you were looking for all along: Someone who draws energy from unknowns. “I talk about the fact that the people who are going to be successful are the ones who see things that aren’t perfect and draw energy from them,” Curtis says. Make it clear, on the other hand, that cynicism and complaints will not be rewarded.

4. Review your engineering values. When you first start to build your engineering organization, it’s good to codify the values that will guide your actions. These can be worded any way that feels right to you. Examples may include, “be biased toward action” or “have strong opinions but hold them weakly.” Whatever you come up with, go through each one, clarifying what they mean to you and why they made the list. “Values can be open to interpretation, so it’s good to have a voice-over,” Curtis says.

5. Welcome new hires to the recruiting team. The people who just came through your interview process are going to be conducting them for new candidates before long, so make sure new members of your team understand that recruiting is a major and critical part of their job now. “You want them to treat it as seriously as they do writing a piece of code. They need to be really present for recruiting,” Curtis says.

6. Establish direct lines of communication. Open communication is a powerful remedy for unnecessary bureaucracy — and there’s no message more powerful than telling your team they can take concerns to upper management and meaning it. “Sometimes people feel they need to funnel all communication through their direct management. When you say that they can come to you, to the leadership several tiers up, they know that they can communicate openly across the whole organization,” Curtis says.

7. Conduct a series of initial check-ins. Good habits are established early, so don’t let up on your efforts once new engineers are at their desks. Curtis has found that one month and three months are the sweet spots for informal check-ins. “This is super lightweight. All we do is collect a couple sentences of peer feedback from the people around that new engineer,” he says.

Your questions to these team members can be very straightforward. Curtis suggests: “How are they ramping up in an unfamiliar code base?” and “What issues have they encountered and how have they reacted?”

Share the feedback you receive with the person in writing. It will be a valuable reference point for engineers as they ramp up. And if you hear any causes for concern, address them right away. Sit down with that person and clarify your expectations.

It’s much easier to shape how someone works early on when they first start at the company than when it’s solidified a year in.

Build the Managers You Need

When it comes to hiring and onboarding managers, though, there’s another layer to consider. These are people who are going to actively shape your company’s culture, personality and progress every day. At Airbnb, a commitment to helping managers make good decisions has manifested in an unusual policy:

“We have a philosophy that all managers start as individual contributors. We believe that if a manager doesn’t spend a significant enough time in the code base, they’re not going to have an intuitive sense of what makes engineers move faster and what gets in their way,” Curtis says.

Unsurprisingly, this can make it more difficult to hire managers. But he’s devised a four-step process engineering leaders can use to find managers who will be best for their companies long-term:

• Set the expectation. There’s no sense in surprising a candidate with the news that they won’t inherit a team halfway through the process. “The first time I talk to a manager who has plenty of management experience and wants to work with us, I’ll tell them straight out that they’re going to start as an individual contributor,” Curtis says.

• Conduct a coding interview. After years in management, it can come as a shock to jump back into algorithms on the fly. “Managers who aren’t comfortable anymore with the discipline of engineering are very likely to wash out at this stage,” he says. “But that means that the people that come through in the end are the people who are going to be able to meaningfully contribute to the code base and understand their engineers.”

• Try pairing. Maintain realistic expectations for coding interviews. “If somebody’s been out of the code base for the last five years, they’re probably pretty rusty, and they’re not going to nail it on your algorithmic whiteboard coding question the way a new grad will,” Curtis says. Pairing can be a helpful workaround. “If you didn’t get a great technical signal from them, but you’ve got a good feeling about them as a manager, do a pairing session,” Curtis says. Give the candidate a chance to shine in the context of working with an existing employee. This usually surfaces latent knowledge and gives you a sense of their dynamic with other engineers as they navigate code.

• Give it more time than you think. The goal is to give managers a chance to really engage with the code base, so don’t rush things — six months as an individual contributor at your company is usually about right. “The point here is to give them a chance to ship something real and establish some legacy in the code before they take on management,” Curtis says.

What It Means to Replace Policies with Principles

At this point, through careful hiring and training, you’ve built a team with good judgment. So how can you leverage that to streamline how you run your organization? “Now you can start taking a more principled approach to how you govern the organization,” Curtis says. To bring this point home, he provides several examples that succeeded at Airbnb:

OLD POLICY: All expenses require pre-approval.

NEW PRINCIPLE: If you would think twice about spending this much from your own account, gut-check it with your manager.

“I can’t tell you how much pain in my life has come from expense reports,” Curtis says. Airbnb’s old policy was a cumbersome one: Charges big and small required approval before they could be submitted. So Curtis tried replacing it with a principle, simple good judgment, using $500 as a rule of thumb for when to get a gut-check. The result? No increase in discretionary spending (but a whole lot of time saved).

OLD POLICY: Engineers can’t create new backend services without approval from managers.

NEW PRINCIPLE: While working within a set of newly articulated architectural tenets — conceived by a group of senior technical leaders — engineers are free to develop backend services.

Here’s another case where policy was creating a huge amount of overhead. “You’d have to go explain what you wanted to do to your manager, explain the rationale, get them to understand, and then get them to approve and move forward,” Curtis says. So he tried something new: A group of senior engineers set up sessions to determine the architectural processes that mattered most to the organization, then articulated them in a series of architectural tenets. Guided by that document, engineers are now free to create new backend services. “It might even be okay to go outside of those architectural tenets, as long as you gut-check it with the team,” Curtis says.

The process used here ends up being even more important than the result. “It wasn’t me sending an email saying, ‘Here’s the rules by which you must create new services.’ Instead, it was a group of peers coming together,” Curtis says. “That created great social pressure within our team, which has worked incredibly well to keep us within the boundaries of what we think we should be developing with to solve our technology problems.”

Getting Changes to Stick

I have a theory that the only way you can affect cultural change on an organization is through positive reinforcement and social pressure.

A few years ago at Airbnb, pretty much none of the code being pushed to production was peer reviewed. The team was moving fast, but site stability was suffering. Curtis knew it was time to make peer reviews a priority — but how? “This was a decision point for me. I could have written up a big email and sent it out to the team and said, ‘You must get your code reviewed before you push to production.’ But instead we took a different approach.”

Your team’s goals may be different, but the steps that Curtis used to effect this principled change can serve as a template for any paradigm shift:

Make it possible. Before you establish a new priority, make sure it’s feasible within your current systems. “It turned out that a lot of our tooling for code reviews was extremely cumbersome and painful, so it was taking too long for people to even get a code review if they wanted one,” Curtis says. So he made sure that tooling was improved before rolling out this initiative. People can’t do what you haven’t made possible. If you don’t take this into account, they’ll be confused and resentful.

Create positive examples. Enlist a group of well-respected engineers to lead by example. In Airbnb’s case, Curtis asked a handful of senior engineers to start requesting reviews. “It created a whole bunch of examples of great code reviews that we could draw from to set examples for the team.”

Apply social pressure. All-hands meetings can be invaluable tools for advancing a culture-shifting agenda. That time together is already booked, so why not make it work for you? “We started highlighting one or two of the best code reviews from the week before,” Curtis says. “We’d have the person who got the review talk about why it was helpful for them and why this was useful.” Your best spokesperson for a new principle a member of the team who’s already bought in.

Address stragglers. If you don’t get everyone on board on the first pass, don’t take it personally. In fact, Curtis considers converting this crowd an important final step in the process. In the case of Airbnb’s code reviews, he and his senior engineers talked to each holdout and learned what their concerns were. “Usually the end of that conversation was just ‘Give it a try for a couple of weeks, see how it goes, see if it works.’ Most of them had a very positive experience and then were brought along.”

In roughly two months, Curtis had made peer code reviews the overwhelming norm without establishing a single policy. “This is the power of positive reinforcement and social pressure to bring about cultural change in an organization. I didn’t hand down any edicts, I didn’t say ‘It has to be done this way from now on,’ I didn’t put any formal policy in place,” he says. In fact, code reviews still aren’t enforced in any way; an engineer could still go straight to production anytime — but no one does it.

At the end of the day, though, Curtis is not advocating for the unilateral elimination of all company policies. Sometimes you need rules. “A good example for us is when you’re traveling overseas, there are very specific policies about what kind of data you can have access to and what kind you can’t,” Curtis says. When the health of your organization depends on something that can’t be left open to interpretation, go ahead and make a rule — but do so sparingly.

The real trick is to recognize that a policy doesn’t exist in a vacuum — it interacts with every policy that went before it — and adds to a collective mental and documented overhead that adds up the bigger you get. You want to minimize this overhead however possible, and the easiest way to do that is to trust your team, and clearly articulate your values.

It really comes down to putting your faith in people with good judgment, making sure you hire good judgment, and then guiding them with principles.

If you want to hear more from Curtis, he’s speaking at the OpenAir 2015 Conference alongside Michael Lopp of Pinterest, Adora Cheung of HomeJoy, and many more on June 4.