Many years ago, a real estate broker said this to me, and it has stuck ever since. I often go back to it in my mind. The logic behind it is as follows.

The best answer is customarily "yes." "Would you like to invest $100 million into my development project?" "Yes, I'd love to! Where should I send the money? I'll do that right now." This is the outcome you want.

The second-best answer is "No, I don't like you and I don't like your project." This is not what you want to hear, and it will probably sting at first, but it's the next-best answer in that it offers complete certainty. You know where the person stands, and you can move on.

The absolute worst answer is a "no" disguised as a "maybe." "I don't know. Seems interesting. We'll see. Let me talk to my partners about it and get back to you." This answer creates false hope and delays things. Whenever possible, you want to suss out and avoid delaying an inevitable "no."

It's, of course, okay to need to think about things and do due diligence when it comes to important decisions, but ultimately, the goal is to get to either a "yes" or a "no" as quickly as possible.

It's okay to just say "no." In fact, it's the second-best answer you can give to someone.

Cover photo by Ryoji Iwata on Unsplash

We have spoken before about the importance of speed and rapid decision making in real estate development. But in practice, it's obviously a little more complicated than just being good at making quick and high-quality decisions. And that's because building a building is complicated and it requires teams of people, all working toward the same goal. Some of these people will be internal to your organization, but many will be external, which is a feature that further complicates matters. Because it means that, to varying degrees, there are critical path items -- items that control your overall project schedule -- that are not fully in your immediate control. This is one of the things makes development and construction so challenging.

Now, ordinarily, when a team is being assembled people will talk about their project experience, their systems and fancy tech, and perhaps some of the awards they've won because of their extreme talent. But what doesn't often get talked about is the simplest and most basic of things: You want people who will do what they said they would do, when they said they would do it. In other words, you want responsive and reliable people. This sounds pretty banal, which is maybe why it so often goes unspoken, but it's fundamental to the success of a project. The other nuance to this is that, most of the time, it's less about the company itself and more about the individual human who will be working on the project. Is that person good?

Just being responsive, reliable, and on top of things goes a long way. These are the kinds of people you want on your team and it's how you move fast.

Development is tough. Among a long list of other things, it requires making a lot, and I mean a lot, of decisions. Oftentimes you won't have all the information. And sometimes they will be uncomfortable ones to make. But you need to decide on something. It is, arguably, almost always the case that any decision is better than no decision.

In situations like these, I often like to think back to something that my first boss in development used to drill into me. She would simply ask: What's best for the project? Now, this is not to say that you should ever do bad things simply for the betterment of a project. That is clearly the wrong thing to do. What I am instead saying is that it can be helpful to keep this guiding light in mind.

Developers have a fiduciary duty to their investors and partners. But they also have a responsibility to the people who will ultimately occupy the spaces that they're building and to the communities that they're building in. And at the highest level, all of these groups should be aligned in wanting the best possible project.

So if you're ever struggling with a development decision or you just need a goal reminder, try asking yourself this basic question. It may not work or apply in all scenarios, but I have found it to be helpful in situations where I'm wrestling with something and I need to take emotion out of the equation. What's best for the project? That's what it's all about.

Many years ago, a real estate broker said this to me, and it has stuck ever since. I often go back to it in my mind. The logic behind it is as follows.

The best answer is customarily "yes." "Would you like to invest $100 million into my development project?" "Yes, I'd love to! Where should I send the money? I'll do that right now." This is the outcome you want.

The second-best answer is "No, I don't like you and I don't like your project." This is not what you want to hear, and it will probably sting at first, but it's the next-best answer in that it offers complete certainty. You know where the person stands, and you can move on.

The absolute worst answer is a "no" disguised as a "maybe." "I don't know. Seems interesting. We'll see. Let me talk to my partners about it and get back to you." This answer creates false hope and delays things. Whenever possible, you want to suss out and avoid delaying an inevitable "no."

It's, of course, okay to need to think about things and do due diligence when it comes to important decisions, but ultimately, the goal is to get to either a "yes" or a "no" as quickly as possible.

It's okay to just say "no." In fact, it's the second-best answer you can give to someone.

Cover photo by Ryoji Iwata on Unsplash

We have spoken before about the importance of speed and rapid decision making in real estate development. But in practice, it's obviously a little more complicated than just being good at making quick and high-quality decisions. And that's because building a building is complicated and it requires teams of people, all working toward the same goal. Some of these people will be internal to your organization, but many will be external, which is a feature that further complicates matters. Because it means that, to varying degrees, there are critical path items -- items that control your overall project schedule -- that are not fully in your immediate control. This is one of the things makes development and construction so challenging.

Now, ordinarily, when a team is being assembled people will talk about their project experience, their systems and fancy tech, and perhaps some of the awards they've won because of their extreme talent. But what doesn't often get talked about is the simplest and most basic of things: You want people who will do what they said they would do, when they said they would do it. In other words, you want responsive and reliable people. This sounds pretty banal, which is maybe why it so often goes unspoken, but it's fundamental to the success of a project. The other nuance to this is that, most of the time, it's less about the company itself and more about the individual human who will be working on the project. Is that person good?

Just being responsive, reliable, and on top of things goes a long way. These are the kinds of people you want on your team and it's how you move fast.

Development is tough. Among a long list of other things, it requires making a lot, and I mean a lot, of decisions. Oftentimes you won't have all the information. And sometimes they will be uncomfortable ones to make. But you need to decide on something. It is, arguably, almost always the case that any decision is better than no decision.

In situations like these, I often like to think back to something that my first boss in development used to drill into me. She would simply ask: What's best for the project? Now, this is not to say that you should ever do bad things simply for the betterment of a project. That is clearly the wrong thing to do. What I am instead saying is that it can be helpful to keep this guiding light in mind.

Developers have a fiduciary duty to their investors and partners. But they also have a responsibility to the people who will ultimately occupy the spaces that they're building and to the communities that they're building in. And at the highest level, all of these groups should be aligned in wanting the best possible project.

So if you're ever struggling with a development decision or you just need a goal reminder, try asking yourself this basic question. It may not work or apply in all scenarios, but I have found it to be helpful in situations where I'm wrestling with something and I need to take emotion out of the equation. What's best for the project? That's what it's all about.