Trust is the lifeblood of a team. It’s the foundation of Lencioni’s The Five Dysfunctions of a Team. Its absence, more than anything, is why teams struggle or fail.

The absence of trust puts people into a particular state — they tend to agree to decisions but not support them. To name a few examples:

• Engineers who attend architectural meetings, don’t speak up, then complain about everything afterward
• Managers who agree to a decision in front of other people then undermine it privately with their team
• Product managers who acknowledge and agree with technical constraints but push for unreasonable deadlines anyway

Defend trust. No matter how big or small the decision, strive to identify when someone is in this space — and call them on it. If you’re able to do this early and often, you can hopefully avoid other dysfunctions they will inevitably cause.

Two by Two

When it comes to negotiations, people tend to fall into one of four categories:

Agree and Support

This is the easiest thing to do — but be careful when everyone just agrees and supports everything. It’s possible to be too good at this. Huge decisions without proper discussion and friction make me a little antsy.  If everyone agrees with zero resistance you could lack diversity or worse — nobody gives a crap.  Most decisions worth making cause fun and sometimes challenging discussion.

Disagree and Support

This is an example of a professional who has said their peace, weighed the pros and cons and have agreed to support a decision even if they may not personally be super excited about it. People who do this understand what is best for the group — they are able to put their own reservations on hold to give things a try and trust in their teammates.

If you have team members who are able to do this, you’re lucky. Make sure to keep them included and be willing to change if what you’ve decided to try doesn’t work out. Working together with them will make the end result a lot better.

Disagree and Don’t Support

When people disagree and don’t support they are at least transparent about not being able to support something. I respect this. If someone feels that something is fundamentally wrong and will not support it, they can and should say so.

This presents some interesting problems, though: it usually means they need to switch teams or projects — and possibly companies. For their own happiness and growth it is tough to ask someone to stick around and work on something they don’t believe in.

As a leader I try to identify other projects or challenges for these folks — if you can, work out a situation where they can work on something they can support.  If you can’t, then you better make sure the decision is right because you risk losing them over it.

Agree and Don’t Support

This is bad news. When someone agrees then undermines something you have a number of problems:

• They don’t feel like saying anything will make a difference: for some reason, they didn’t speak up and confront the group with why they felt it was the wrong decision.  Figure out why.
• The rest of the team will hear why they are wrong on a regular basis: over time, the grapevine will fill up with underhanded comments, “I told you so”, and all sorts of papercuts that undermine what the team is doing.  Aside from the morale impact, this gets in the way of iterative progress and productive failure.
• Say goodbye to personal growth: if it goes on long enough, this person will eventually be ignored or marginalized by the rest of their team.  As a manager, if this happens, it’s your fault.
• It could ruin your team: the ultimate consequence is the erosion of trust within the team — for each other, for you, for the person.

Get ahead of it. When you see someone in this place, talk to them about why and ask them why they are not able to support the decision or at least talk about it with the team. That may get you on the right track. If too much time has passed, though, you will probably have to move them.

Have Backbone

Whatever challenging decisions you face, have backbone. It’s my favorite of Amazon’s leadership principles:

Have Backbone; Disagree and Commit

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

When you are open, honest, challenging — even when it hurts or might be inconvenient — it means you have the courage to fight for what’s right.

And when the time to talk is over, you have to prove yourself again by committing to the decision you have made as a team. When you can do this, you have the trust and respect you need to succeed together.

I’m starting my fourth week at Etsy and riding the train North to SF. I wanted to take a minute to talk about my first few weeks and what lies ahead.

Plug: If you’re interested in joining me, ping mmorgan at etsy or visit etsy.com/careers

Etsy is a tribe

In the Seth Godin sense of the word, Etsy is a tribe:

A tribe is a group of people connected to one another, connected to a leader, and connected to an idea. For millions of years, human beings have been part of one tribe or another. A group needs only two things to be a tribe: a shared interest and a way to communicate.

You might think this applies to just employees, but I’ve learned that Etsy is a large, interconnected network of awesome people — including crafters and leaders in the community — who care about a common mission. I think this is awesome.

What is that mission? It’s any number of things:

• To redefine commerce and make it human again
• To connect makers with their customers in a direct way
• To give people with skills a fair marketplace so they can prosper

There are many ways to state it, but for me, the important part is this: we are trying to make the world a better place through technology. That’s what I love doing, it’s what makes me happy.

After a few weeks, I’m certain: This is my tribe.

For more on Etsy, I highly recommend the annual report, which is a good example of transparency in practice.

The world needs companies like Etsy to succeed

My time at Mozilla taught me that the sum of small conscious choices like what browser we use can create enough momentum to change an entire ecosystem. Likewise, how we choose to engage the economy around us is a small but pivotal decision we all make on a daily basis.

Missions like these seem daunting and ambitious at first. They require faith, passion and a stubborn optimism. It’s not a lighthearted we’ll get there someday — it feels more like a we must do this because someone has to. Over my first couple of weeks, I could sense it in Brooklyn.

On a personal note: As a father, I’d love to see Ella grow up knowing where — and who — things come from; to be able to learn about how things are made and maybe even meet the people who built them. I’d like for her to care about the people, quality and values behind what she buys and how it affects the world.

I’d like to make those things more possible. I feel like someone needs to.

This is only the beginning

The beautiful thing about tribes, missions and making the world better is there really is no limit to how far you can go when you have a group of highly motivated, talented people. Etsy is a great company that is already making a difference — but it’s really just the beginning for both of us.

The world, it turns out, still needs improving. Together, we have a lot of work left to do.

tl;dr: know which principles matter to your team, and pursue them ruthlessly in engineering candidates.

You’ve probably heard this before: Hire good people and get out of their way.  Problem is: hiring is hard because “good“ is so subjective.

If you put principles at the center of your hiring process, “good” becomes less subjective.  It breaks down like this:

• People provide value in many ways
• The value someone provides is based on a number of principles
• The goal of interviewing is to determine if a person represents the right principles for your team

Focusing more on principles has helped me change habits.  Over the last ten years, I stopped:

• Weighing too much of my evaluation on one question
• Asking gotcha or weed-out questions
• Using the same exact questions for every candidate
• Avoiding time spent on intangibles

And, as a result, I:

• Had more fluidity in my questions, tailoring them to the candidate
• Asked more open ended questions with a goal in mind
• Spent more time on intangibles that mattered to my team and company

This post is meant to be a conversation starter about how to approach principles in hiring.  I’d like you to consider how they apply to your hiring process — to your team — so you can make hiring enjoyable and successful.

Data is not enough

To understand how people provide value, we often start with data. When we evaluate resumes and candidates, there are the usual suspects:

• What school someone is from, what degree or GPA
• How well they answer a pre-formed set of questions
• What companies they worked for
• How many years of experience they have

These are all important, but it is possible for someone to look and sound great and still not be a great fit.  When this happens, it’s possible to see:

• Role confusion: you learn over the first six weeks that a candidate is not as experienced as you thought. Maybe they are struggling with projects someone in their role should be able to handle, or maybe they take too long. Worst case, they just can’t get the work done when you needed someone who could. Now you have a problem.
• Poor mutual fit: this is reflected by motivation and morale. When a candidate’s motivations and principles don’t line up with the team they joined, you can have unnecessary conflict or a lack of motivation in the team as well as in your new hire. This is hard to fix.
• Turnover: when you have a mixture of bad mutual fit and improper skills for the role, you will end up with turnover — either for your team or for the company.  The best case is you find another team that fits the hire while the worst case is you have to let someone go.  Either one is very expensive to yourself, your team and the individual.
• Declined offers: the thing about being shallow in your hiring is that intelligent candidates know it’s happening. Your company is judged based on the kind of interviews you do and what questions you ask. If you seem mechanical in delivery or process, it’s easy to spot, and it’s easy to pass on it.

Why does this happen? Because raw data does not tell you enough about someone’s principles. For example, you can’t tell if someone has a life-long passion for building things based on what school they went to or how they answer your FizzBuzz interview question.

Aside from being soft on principles, question-based or score-based regimens can actually promote “maybes”.  For example — if you had a 4-point scale, what do you do with a 3 out of 4?  What about a 2.5 out of 4?  Or do you only hire 4′s?  How do scores map to solid decisions?

Mapping data onto principles

Data is important, just not enough. You can give data more purpose and value by mapping it to principles.

Consider the SAT. When someone takes the SAT, their score matters, but by itself it is not the best indicator of potential or success.  When schools evaluate potential students, they aren’t just looking at SAT scores — extra-curricular activities and demonstrated leadership matter as well.  Why?  Because universities don’t just want smart people — they want successful people.

The SAT maps to fundamentals.  Using the college example, consider these mappings:

• SAT score: is this person smart enough to learn (the SAT)?
• Extra-curricular activities: does this person have the ability to manage their time?
• Leadership in the community: does this person have good emotional intelligence?
• Course selection and diversity: does this person have a passion for learning?

The SAT is just one piece of the puzzle for a college to determine if someone is smart enough to learn.  Likewise, for engineers, there are many data points.  Here is how they might map to principles:

• Past experience, personal projects, open source contributions, portfolio, hobbies, github activity: Does this engineer have a passion for building things?
• Blogs, conference talks, books written, references: Does this engineer understand things well enough to teach them?
• Specific projects, real-life examples, mistakes made, attack vector exercises: Does this engineer think about security day-to-day, or do they just read about it?
• Syntax, code questions, sample code: Is this engineer as good at [language/framework/area] as they claim they are?  Do they have what we need?

Mapping data onto principles clarifies why data is important.  This leads to clearer, more confident hiring decisions — people adhere to principles or they don’t.  If they don’t support the principles you value, you don’t hire them.

Subsequently, discussions in round-ups or debriefs should be focused on whether or not an engineer meets the right principles, not how well they answered a particular question.

Customizing for the role

Once you’ve covered some of the engineering basics it makes sense to focus on a particular area.  Depending on your team, this could mean distributed computing, front-end optimization or application security — or something else.

One of my favorite questions is around front-end optimization.  I’d ask, “What are your best practices for front-end engineering?”

• Simple enough, but what do I really want to know?
• What they can build, but also how they build things.
• Does this engineer build things the right way?
• Has this engineer actively improved the way they build things?
• Does this engineer follow standards?
• Does this engineer suffer from not-in-house (NIH) syndrome?

Those types of answers are hard to measure and not found with your typical algorithm or FizzBuzz questions.  If you don’t get to answering these, you’ll never quite be sure about someone — or as sure as you’d like to be.

For me, the best thing about this question is that it’s simple and flexible.  I can always remember this question, there’s no right answer, and it’s open ended enough to let me take it wherever I need to.  I can dig deeper on technical details or dig deeper on direct experience — whatever I need to do in order to get at the engineer’s principles.

What kinds of domain-specific questions would matter to your team?  How would you like an engineer to build things?  How would you get that out of your short time with them?

Final word

If all else fails, try to understand:

• What kind of person are they?  Would you want to work with them? How do they handle feedback?  Are they a good person?  How do they work with a team?
• What can they build?  Do they build teams, products, libraries, utilities or cultures? What do they _love_ to build? Do they do it in their free time?  Could they build your product?
• How do they build? What are their engineering philosophies?  What are their best practices?  Did they help define them?  Do they actively improve these over time?
• How do they approach metrics?

If you understand these about your team, you can intentionally look for candidates whose principles line up with yours.  When that happens, you have a situation where your candidate is more likely to be successful. I’ve seen this work time and again, and it leads to stronger performance, better culture and higher retention.

You’ll notice some trends here:

• These aren’t simple questions to answer.  You need all sorts of data and directed questions in order to form an answer.  There is no silver bullet question.
• They are very hard to quantify.  Intangibles and other things that matter usually are hard to define or measure.
• It’s not something you apply a point scale to.  People practice a principle or they don’t — there is no ‘try’ or ‘sort of’.

And that’s why interviewing is an art.  Your data and questions are all signals, but in the end, what allows you to really make sense out of it is what your principles are and how well the person you’re talking to practices them.

Remember: It’s hard to hire good people and get out of their way if your definition of good is flawed.  Know which principles matter to your team, and pursue them ruthlessly.