We’ve all been there:

• “We’ll do better next time.”
• “We can refactor that later.”
• “Let’s just ship it now and clean up the tests later.”
• “We’re just using that database until we prove the concept, then we’ll switch to something solid.
• “We won’t make that mistake again.”

You won’t do better next time. You won’t refactor that code until it’s caused you far more pain than gain. You won’t clean up the tests. You’ll stick with the crappy database until your business is on the line. You will make that mistake again.

We all fall prey to this form of optimism bias, the baseless belief that things will work out better than all the evidence says it does. We are particularly vulnerable when it comes to beliefs about ourselves. We can barely admit we’ve made mistakes in the past, so contemplating the possibility of making mistakes in the future is nearly impossible.

When you make a mistake and suffer the consequences, there are three ways to react:

1. Do nothing
2. Half-assed improvements
3. Real improvement

The problem is that a lot of half-assed improvements look whole-assed when viewed through rose-tinted glasses. You give your future self a little bit too much of the benefit of the doubt. They’ll be smarter, more knowledgeable, less easily distracted, more careful about following directions, and all the things that we wish we’ll be but never will. For instance, you might add items to a checklist, because your future self will always look up the checklist, will always find it, will carefully follow every item in exactly the right order without taking any shortcuts, etc. This unrealistic optimism leads us to believe that we can address complex problems that we failed to solve today by adding complexity tomorrow.

Dan Milstein, then of then Hubspot famously said, “let’s plan for a future where we’re all as stupid as we are today.” Yes, learning is important. Yes, you’re getting better every day. But the way in which you’re going to be better is unpredictable, and you’re not guaranteed to be better in all the ways you need to be exactly when you need to be. If you really want to deal with this problem better in the future, you have to accept that your future self is going to be basically just as flawed as your present self and construct your system to work in spite of those flaws.

Software engineers love efficiency. They love elegance. It’s what they’re taught, and it’s what attracts a lot of them to the field. The problem is they overdo it.

These days I’m not up close to the technology. And yet often I’m able to see solutions that the hands-on people don’t. These are often wasteful or ugly solutions, but they have one big advantage: they’re doable, in some cases more so than what they came up with.

The reason I see what they don’t is that software engineers often prize efficiency and elegance so much that they reject any solution that isn’t both. They may not even be able to conceive of them. Unfortunately, in too many situations, what that leaves them with is nothing. That’s because there either isn’t an efficient and elegant solution, or nobody has thought of one.

Efficiency and elegance matter, but they matter second. What comes first is effectiveness. If you only have one candidate solution that is effective, efficiency and elegance are irrelevant. After all, if you reject your only effective solution on those grounds, you have nothing remaining. The same thing can happen if you have multiple effective solutions, none of which is efficient or elegant.

The answer is not to ignore those considerations. The answer is to apply them only if they still leave you something you can use. Use efficiency and elegance to narrow down the candidate solutions, but not if they eliminate every option. After all, solving the problem in a mediocre way is typically better than not solving it all.

I have highly capable team members, but sometimes they need me to solve a problem or make a decision. Describing a solution or communicating a decision can often be brief, but I spend a lot of time describing how I arrived at the solution or decision. There are a few reasons for that.

The first is that it gives me a way to teach the other person. If I’m doing my job well, my team members are becoming steadily more capable, and I hand off more and more responsibility to them. Certainly they’ll learn from example and experience, but they’ll learn faster if I describe what I see as the key principles and how to apply them to a specific situation. That’s better than only describing principles in the abstract or only giving them answers where they have to infer the reasoning.

The second reason is that I am frequently wrong. I may be missing important facts, I may misunderstand them, or I may have a flaw in my reasoning. If I just deliver an answer, it’s difficult to tell that I went wrong. However, if I explain the facts as I understood them and how I interpreted them, then my team member can observe my mistake and share it with me. I learn something, and we end up with a better decision.

Third, and relatedly, it makes it easier to invite disagreement. If all the other person has is my conclusion, there’s a finality and opacity to it that makes it hard to engage. However, if I describe my thinking, there’s more for the other person to grab on to if they think we should go in a different direction.

Finally, I believe it shows respect. The people on my team are motivated, capable professionals. They’re not flunkies I expect to do my bidding without question. I don’t want to be given orders, and I don’t want to give them. By investing my time in explaining myself, teaching them, and inviting criticism and disagreement, I show them their opinions and perspectives matter to me. It’s about them executing my brilliant ideas, but the two of us putting our heads together to solve problems as partners.

I’ve had many discussions with many people about how an interview process should be constructed. As part of that, I try to understand the other person’s why. What, in their view, is the purpose of interviewing? Take a minute and think about your answer, then read on.

Among the answers I’ve heard and read are to:

• decide if we should hire the candidate
• assess the candidate’s fit
• understand the candidate’s skills
• to assess the candidate’s abilities
• to find out if there is rapport
• verify the resume

The poverty of these answers is depressing. What’s so bad? Some of these answers are too shallow and beg the question, e.g. finding out of there is rapport. Why do we want to find out if there’s rapport? Others try to go go too far, establishing an expectation of an interview that it cannot achieve, e.g. deciding if you should hire a candidate. An interview can’t do that, and any advice that asserts that is not actionable. That one in particular is tautological.

There’s ample advice, some good and some bad, about how to interview for specific roles. There’s also a lot of general advice, similarly a mix of good or bad. Almost never are there clearly stated goals that achieve meaningful outcomes while being specific enough to be useful. The advice is just too much of a cargo cult of dogmas, copying, and shallow thinking. Almost nobody seems to have thought deeply about this from a first principles perspective. Absent that clarity, you will struggle to define a good process to hire the right candidates, you will struggle to assess whether it’s working, and you will struggle to improve it.

The good news is that there is a right answer. There is only one purpose to interviewing, which is the same as any other candidate assessment activity: to gather information to help predict future job performance. No more and no less. Every single word in that purpose is necessary, and it is sufficient to determine all of the activities in the candidate assessment. In slightly altered order:

• to gather information: interviewing is a process of discovering, refining, and verifying information. It is not a decision-making tool. It can be a sales pitch and a relationship-builder, but those are purely secondary. If they happen, good, but don’t sacrifice the primary goal to achieve them.
• future job performance: you don’t care about someone’s past performance. You want to know what they’ll do for you. You also don’t want to turn this into a binary question of hire versus no hire. For one, the interview can’t do that; a person has to do that. For another, the expectations can be somewhat flexible; perhaps you’re willing to lower expectations for a candidate who comes more cheaply. In addition, you’re rarely considering only one candidate for a role. The question isn’t whether to hire a particular candidate but rather which candidates do you most prefer of the ones exceeding the minimum.
• to help predict: you don’t care about someone’s past knowledge, skills, projects, education, etc. for their own sake. These are just a means to an end: making a decent prediction about how well the candidate will do the job. No single piece of information will predict everything, nor will any prediction be perfect, hence “help predict.”

You may have found yourself reading the above and thinking, “that’s what I meant, or “we do that,” or something else. I’m 99% sure you were sort of right but also sort of wrong. This is something where “close enough” is actually something else. Doing something vaguely like this is not at all the same as doing exactly this. It’s like saying the Louvre is a museum.

You may also have found yourself reading the above and thinking it’s obvious. I’m 99% sure it wasn’t, which certainty is based on the number of times I’ve heard the right answer versus all the other ones. I’ve found that this is one of those truths that is obscure beforehand and then obvious afterward. That doesn’t mean you knew it all along.

If you cannot explain how an activity in your assessment process provides information that predicts future job performance, you should discard it. Maybe it doesn’t provide information, maybe it’s backward looking, or whatever. On the other hand, if you have an important element of job performance that cannot be predicted from the information your process collects, then you have a problem. Maybe there are elements that are impossible to predict, but I’ve never seen one. All I’ve seen are more predictive, less predictive, and useless.

None of this doesn’t mean you can’t have a sales pitch in your schedule. It’s just not part of assessing the candidate. Your interview process can have multiple activities in it, but it can’t do them well without you having crystal clear goals for each one. The most important one? Gathering information that helps predict future job performance.

A naive impression of delegation is that it’s about the work. Suppose you’re hiring people to landscape your front yard. You might tell them plant a maple here, spread mulch there, build a wall around the oak, remove the hydrangea, and so forth. Then the crew digs, scrapes, plants, pulls, etc. according to your directions, while you keep your hands clean and your brow unsweated.

This is not how it goes in knowledge work. In knowledge work, what is being delegated is thinking. If someone is putting together a proposal, creating a financial model, constructing a product roadmap, drawing a wireframe, or building a new feature, the work is not the typing or the drawing. The work is the thinking. The work is taking an abstract idea and turning it into something detailed that is the best expression of that idea. If you’re frequently asking for guidance, then you’re not accomplishing the goal the delegator had when they gave you the task. The hard part is the thinking! If they still have to do a lot of the thinking, then the delegation failed. What the delegator wants is to never have to think deeply about this task again. That includes worrying about whether it’s getting done.

To be a successful delegate, you have to discover the questions and answer most of them yourself. For the ones that remain, you have to ask for guidance briefly and in a way that minimizes the cognitive load while also extracting the maximum information both for those questions and any future ones. And then you have to regularly show that you are making the expected level of progress, but with no more information than is needed. I want to be able to live in a world where 99.9% of the time this project does not exist. When I delegate something, the ideal outcome is I hear about it for about one minute every few weeks, and all that I need to say is an acknowledgment that I’ve heard and perhaps an affirmation of the delegate’s effort and talent. More than that and it’s not delegation as much as it is partnership or (ugh) supervision. I want to live with the benefits of this project and none of the costs except one, which I’ll happily pay: employing the delegate.

Almost nobody thinks they’re perfect. We all know we sometimes misunderstand, sometimes misjudge, and otherwise make mistakes. And yet, people still have difficulty admitting they are wrong. I imagine the dialogue going something like:

Person 1: Do you ever make mistakes?
Person 2: Of course, I’m human.
Person 1: Well, what about that time you cut the budget for the redesign project?
Person 2: That was the right thing to do because …
Person 1: And when you fired Jared?
Person 2: I know people disagreed, but Jared had to go because …
Person 1: What about when you promised the client we’d deliver by November 15?
Person 2: Sure, we ended up slipping into January, but if I hadn’t done that …

Somehow what happens is that we agree in principle but disagree in particular for every single situation. That’s odd, right? How is it we can acknowledge that we make mistakes and yet never find a mistake?

The answer is ego. Admitting we make mistakes in the abstract is easy. Admitting that we made a specific mistake in a specific situation means accepting responsibility for the specific negative consequences that resulted. It means admitting specific flaws in ourselves. When that happens, it’s too real.

The fact is that the reasoning that led us to make the mistake is embedded in what we believe, and we probably believe the same things now as when we made the mistake. The problem with the mistake is that it made sense at the time, and so it will also make sense later, even when the results aren’t what we intended. The thinking that made us make that mistake is going to make it hard for us to understand the thinking that recognizes the mistake. To actually manifest our stated belief in real life, we have to accept that it’s when we feel that we’re right that we’re most likely to be wrong.

I had a meeting with a long-time colleague recently. He heard me out on an idea, and he cautioned me that the the way I expressed it might be understood a different way and thus have a different effect than I intended. His perspective didn’t make sense or sound valid to me, which made me want to dismiss it. But that is exactly why I needed to hear it. If it had made sense, then I would have expressed the idea differently, and I wouldn’t need him to tell me what he did. The fact that it felt right was a strong signal I needed to hear how it might be wrong.

I’ve sat in on a lot of presentations: design reviews, product pitches, budget requests, etc. Usually it’s one or two people presenting to many more. This creates an asymmetry between how it feels to provide feedback and how it feels to receive it.

Suppose you’re sitting in a design review with a dozen other senior people. Someone from another team is describing how they want to implement a new system. You think it’s mostly good, but there’s one thing that you see a problem with. Sure there are more things that could be better, but there’s one thing that’s genuinely important, and you don’t want to be a bother. So you bring up your one point, have a discussion, and then things move on. That seems healthy and manageable, right?

Now imagine that everyone else attending the design review thinks the same way you do. There are thirteen people, each of whom is bringing up one criticism. They could argue about more, but they’re being pragmatic and trying to avoid being jerks. Each one of them feels like they’ve been productive and restrained. The person on the receiving end? They just got thirteen different criticisms. It feels like being in front of a firing squad. Maybe they get overwhelmed, maybe they show it. Everyone else is confused at the reaction. That’s because because they’re not under the dog pile. They just feel their own weight. They don’t feel everyone else’s weight crushing them.

What’s the answer? Well… it’s not clear. Those thirteen questions are probably legitimate questions, even if they don’t reflect genuine and serious problems. Clearly they should be addressed. What the critics need to remember is that they’re not coming across as separate individuals with single criticisms. Even if your point is essential and productively stated, it’s going to be received negatively and as a part of barrage. That means you have to soften your criticism and really focus on assisting with the development of the solution, far more than you would in a one-on-one conversation, even if to you it feels exactly the same.

For years, the CEO of Indeed had the worst desk in the whole office. It was by the main entrance in the middle of the floor near some very popular conference rooms. He never explained himself to me, but I inferred it was some combination of humility and wanting to make himself available to people in the company to come talk to him. In all those years, I never once saw anyone walk up to him and start a conversation. Even I only ever did it once, and I’d been at the company for years longer than he had.

This may seem strange. Surely he put himself there so that he could be approached. He removed the physical barrier, but why were people still blocked?

The answer is because the physical barrier wasn’t the only barrier. Consider. You’re an ordinary employee of a multibillion dollar company. The CEO has a lot to think about and do. There’s no way any of your questions or concerns could be more important than what he’s doing right now. Do you want to disturb that? Do you want to risk being the target of his irritation? Even if he’s the most easygoing, good-natured person in the world, he’s still the CEO! Best to leave him alone.

The psychological barrier is nearly impenetrable. There is a significant power dynamic in most American companies between the CEO and most employees. Well-intentioned leaders try to make themselves available. They announce open door policies. What they don’t realize is those aren’t sufficient. They emit a repulsive force, and if they want the average employee to approach, they have to overcome that. They can’t just be available. They have to invite engagement, they have to invite the interruption, they have to invite the conversation. Otherwise it won’t happen.

So why was I the exception? Was I oblivious to the power dynamic? Am I possessed of a steely nerve? Do I have an enormous ego? It’s none of those. That one time I did it, I was anxious and nervous. The only thing that made me do it was the sanctity of my purpose: I was doing it to ask for something for someone else. If it was for myself? I never would have done it.

There are only three things that matter when hiring people, in increasing order of importance:

1. Who they are right now
2. Their durable, persistent traits
3. How well they can adapt

Who they are right now only matters with short time horizons. If you have a job that needs to be done relatively soon, you don’t want to pay a start-up cost. You also don’t care about the person in the long term, because your long term and their long term diverge. The longer you expect to employ them, the less this matters.

When you do have a long term in mind, there are two things that you want to balance. You want to know what their durable, persistent traits are: deep strengths, deep weaknesses, patterns, preferences, and so forth. While everyone has the capacity for change, few of us change completely, and some kinds of changes are much harder than others. You want to identify people whose durable, persistent traits are generally advantageous and operate at a meta-level, for instance work ethic, integrity, curiosity, and intelligence, and you want to maximize these traits.

Finally, and most importantly, you want adaptability. Over a long enough time horizon, adaptability becomes almost the only trait that matters. That’s because over that time, you can expect pretty much every hard skill to become obsolete and the demands for many soft skills to shift and mutate. You want people who are willing and able adapt to all of that change. But you don’t want them to be too adaptable. If the environment evolves to tolerate laziness, dishonesty, or complacency, you do not want them to adapt. You want them to resist the environment changing that way in the first place and fighting to reverse the change if it does happen. Unlike the meta traits describe above, adaptability has a sweet spot. The value of adaptability increases as adaptability increases but only to a point. After that, the value of adaptability diminishes, because it makes it possible to adapt in ways that may be beneficial in the short term but harmful in the long term. That’s why it’s important not just to have durable, persistent traits, but also for them to be the right ones.

Whenever you’re explaining a complex idea to someone, it makes sense to check their understanding. There’s no sense in continuing to explore the idea if the listener is stuck. They’re not going to be able to follow you. However, there are two problems with asking someone if they understand.

The first problem is ego. Everyone wants to learn. Nobody believes they know everything. And yet, in the moment, people often don’t want to admit a lack of understanding. Sometimes they don’t want to admit it to you, but quite often they don’t even want to admit it to themselves. Saying they understand allows them to continue believing the story they want to tell about themselves. That’s a difficult habit to break.

The second problem is confusion. It’s possible to be simultaneously confused about an idea and also be confused about your confusion. In other words, your misunderstanding of the idea is compounded by a lack of awareness that you understand. This is related to the Dunning–Kruger effect. In the words of the great George Bernard Shaw: “The single biggest problem in communication is the illusion that it has taken place.” They think they understand, they tell you they understand, and so you think they understand. You can’t rely on answers. You need a proof.

That means you have to check understanding in different ways, ones that don’t have the same level of ego threat and also don’t rely on the judgment of an unreliable judge. There are at least two ways to do that. One is to ask them to explain the idea back to you in their own words. Assuming they’re not just using a thesaurus to replace your words with theirs, that will get you some of the way there.

Of course, purely abstract understanding, even if sound, does not mean practical understanding. Thus the second test is to have them apply the idea. It could be to a hypothetical situation or a real problem, but have them apply the idea to some specific situation. That will demonstrate the understanding. What’s especially good about this is, if they don’t fully understand the idea, they’ll be more likely to realize it, because they’ll get stuck or come up with a nonsensical result. Better they figure it out themselves than have you tell them.