Lighthouse Logbook

I've sat on just about every side of a construction meeting. I started in the field with tools in my hands. I spent a dozen or so years on the contractor side, running work, then running a division. Learning first hand how a contractor makes money and, more importantly, how they lose it. Then I crossed over to the owner's side and spent a decade there. Same industry, three completely different views of the same project.

I've learned that when a job goes sideways, everybody is dead certain they know who the problem is. Everybody is blaming each other, or maybe they're even blaming themselves, but there is rarely ever any ill intent from anyone. Nobody is trying to sink the project. What you have on every single construction project is a mismatch of goals. The project is born from a need, and then it gets scoped according to the available budget. Some of the potential problems start right there — in that part about the available budget.

So the design team comes in, then the contractor, then you'll have all of the subordinate engineers and trades, throw in some inspectors and whatnot, and you'll find yourself with a huge project team, and none of them necessarily share the same goals as the owner. Everybody has their own schedules and budgets that may or may not have anything to do with that original need. That's just how it is. The only thing they all have in common is they all want to be successful, and that turns out to be a pretty good leverage point.

Your job as the PM is to find some way to let them all be successful. If you can do that, then it's a win for you no matter how many disasters you had to navigate. So the most useful thing you do is just simple translation. It's sitting in the room and saying out loud what each side is actually trying to protect or accomplish until everybody realizes they aren't enemies, they were just misunderstanding each other. Nine times out of ten the "dispute" dissolves the moment people stop defending positions and start talking about what they genuinely need. From there it's a short walk to helping each other get it done.

Every project has a bad week. (lol just one bad week) The schedule slips, a submittal comes back wrong, something in the wall isn't where the drawings said it would be. You might think that's the stuff we get judged on, but I don't think so.

The last thirty years have taught me that your client will not remember the project issues next year, but they will remember the experience. They'll remember whether you called them before they had to call you. Whether you explained the problem in words they could actually use instead of hiding behind the spec. Whether sitting in a room with you made a hard thing feel manageable... or not.

The issues fade. That feeling of trust doesn't.

Now obviously you still have to nail your deliverables, the work is the price of admission, but I believe that two teams can deliver the same project, on the same schedule, for the same money, and one of them gets the call for the next project and the other one doesn't. That difference is never the gantt chart. It's how it actually felt to deal with you.

Surprises are part of this business. Some of them are genuinely alarming. You don't earn trust by preventing every one of them, you earn it by talking about them in plain language and facing them head on. Nobody's mad about the surprise. They're mad because you tried to hide it or play it down instead of taking immediate responsibility.

Your client needs to know that you are truly on their side. There is no other motive than their success, even if that ultimately looks a little different than they may have expected. You are their guide, and if they trust you, then every project is a success. Even the ones that go a little sideways.

Project delivery is lonely work. Everyone heads-down in their own project, their own budget, their own set of fires, each person carrying their load alone. Most organizations accept that isolation as just how the work gets done. That's just how it is.

But a group of people working near each other isn't a team. It's a room full of individuals who share a hallway. The team is the thing you have to build, and it's one of the most important things a leader ever does.

You don't build it by tearing down what makes people independent. Good project people need their own space, their own ownership. We don't want to infringe on their independence, rather we just want to connect them. Allow the team to bond through the work so they actually want to help each other. If the culture rewards giving credit away instead of hoarding it, then the team will begin to see a colleague's problem as interesting, instead of simply someone else's problem. That culture isn't built with a tool or a process. It's built slowly, on purpose, by a leader who keeps pointing at it: We are stronger together than we are alone.

Developing that culture is the most effective thing a leader can ever do for an organization.

Last week I promised I'd say more about what "making it safe" really means. Here's the short version: Make it safe to fail.

I used to tell my team the best mistakes are spectacular. Be proud of whatever you were reaching for, let the whole team learn from the failure, and then plot your course forward. That's really your only option, because a team that's scared of making mistakes just ends up hiding a lot of mistakes.

You can't let fear into the decision-making process. You have to be bold. But the hurdle is usually yours, not theirs. Letting people make real decisions can feel risky. That's uncomfortable. But the alternative is a team that never grows past you, and isn't that what we're trying to do? Help these people become the best they can be? Even if that turns out to be better than you?

The answer is yes. That's exactly what we're trying to do.

So the instruction to my team is simple: use your best judgment, get some advice, and make the call. If it goes sideways, we'll fix it together and we'll all learn from it. I'm not going to stand there asking how you let it happen.

We build things for a living. But the most important thing we build is the team.

More next Friday.

A few years ago I started sending my project delivery team a weekly note that I called the Friday Wraps. There were 71 of them before I moved on from that position, and it was through writing them every week that my Lighthouse Leadership philosophy really began to take shape.

• Psychological safety
• Cross-party trust
• Motivation and accountability without micromanaging

Looking back, the first two wraps were a solid beginning.

In the first, I made my PMs a promise: "I will never blame you for the trouble you find yourself in on a project. I'm here to help you get through it." That's safety, and people do their best work when failure isn't a looming threat.

In the second, I asked them to meet once a month without me. No leadership in the room. Just the team, talking honestly and helping each other. I borrowed the idea from a former colleague, one of the smartest people I know who called his version of the meeting "the Mystery of Project Management." I don't know what my team called their meeting. What they called it wasn't as important as the time together. Trust your team to not just learn from and help each other, but also to hold each other accountable in a way you never could.

Over the years of experiencing good and bad bosses, I feel like the most effective thing a leader can do is simply make it safe, then get out of the way.

That's the job. Not steering every ship, but being the steady light they navigate toward, and trusting them to find their way.

In the coming weeks I'll talk more about what "making it safe" really means and how easy it is to do, once you can get over a couple of your own mental hurdles.

More next Friday.