Lighthouse Logbook

There's something strange about running a construction project: The project manager is usually the person with the least actionable authority in the room. Aside from your own staff, none of the project leaders actually report to you. They all have their own contractual obligations of course, but they are certainly not there to do your bidding, and some of them (IOR, Building Manager, Client, etc.) may even take an adversarial position every now and then. Basically, they're all captains of their own ships, and they know how to sail them. What you have is whatever the contract grants you, and the charge to somehow get every one of those ships pointed in the same direction.

For a long time I thought the answer was to be the captain of it all. To grab the wheel of every ship and make whatever adjustments I felt needed to be made. That may seem like the easiest thing to do sometimes, but that's really just a fast way to exhaust yourself and annoy a lot of very capable people. It doesn't work, and it was never going to work. What finally clicked is that a good project leader isn't the captain of all the ships. Your job isn't to manage all of these individual teams, your job is to set the goal and find a way to help them get there with you. Get out of the water and be the lighthouse. You don't board someone else's boat and take the helm. You stand in one place, steady, and you throw enough light that the captains can see the rocks and steer around them themselves. They know how to do their jobs a lot better than you know how to do their jobs, believe me. What they don't know is what they can't see, your job is simply to clear the way, or help the teams navigate around whatever hazard you can't get rid of. Surface the issues, and pull everybody through it together. That part is yours, that's the light. Be steady, be focused, be fearless.

A leader makes people feel confident. A manager makes people feel anxious. Manage the project, lead the people. Be the lighthouse.

Have you ever noticed that the moment a decision goes bad, the whole world becomes an expert? Suddenly everyone knows exactly what should have been done. Funny thing is, not one of those experts was in the room when the call actually had to be made. That's no accident. Very few people will stick their neck out to help you decide something, because deciding means you might be wrong, and vanishingly few people have the courage to be wrong.

I've been called into a lot of projects after something has already gone sideways. And it's always the same scene: a team sitting around a table picking apart a decision somebody made six months ago, using six months of information the decision maker didn't have at the time. It feels productive. It isn't. It's just hindsight wearing a badge that says expert, and one hapless PM who made the only call that made sense at the time.

Here's what I try to remind the room. That call wasn't made in the light you're standing in now. It was made in the fog, on a deadline, with none of the current facts, by someone doing their honest best to keep the project moving. You have to judge the decision by what was knowable when it was made, not by how it happened to turn out. Everybody is a genius after the mistake, including the person who made it, but what is obvious now was not obvious then, you can be sure of it.

I've made plenty of bad calls myself. (Why do you think I wear work boots? Spend enough time stepping in it and you learn to dress for it.) But nearly everything I actually know, I only know because I was wrong about it first. There is no faster way to build good judgment than to exercise a little bad judgment. A bad decision is a funny thing though. Nobody knows it's bad until you make it, and then it's obvious to everybody, even you.

The real danger was never the wrong decision. It's what the fear of being wrong does to a team. Once people learn that every call gets autopsied by a room full of Monday-morning quarterbacks, they quietly stop making calls at all. And a team where nobody has the courage to make decisions is already dying. It just doesn't know it yet.

So don't let hindsight obscure your foresight. Make the best decision you can with what's in front of you, own it, and if it's wrong, then roll up your sleeves and fix it. Some people might call that philosophy reckless, but it's not, that's just courage with its boots on.

A couple of years back I was at my desk, buried in the worst kind of middle management paperwork, (questioning life choices), and one of my PM's yelled a brilliant question across the hall. I responded in the affirmative and added "that's a great angle, I think you just solved it". They yelled back, "I think so too, but it wasn't my angle." They finished with the name of their colleague who gave them the idea. Just yelling it across the hall like they don't care at all who hears it. I chuckled with pride, and then I paused for a minute to wonder why my team was so good. We were growing fast, drowning in new work, and somehow this crew kept knocking everything out of the park.

For the rest of the day I kept thinking about how that happened. What process or strategy did this? I couldn't think of a single thing that I could point to and say: do this thing and you will grow a great team. There wasn't a thing. Later that week, I ended up telling my team the truth: there is no strategy in the world we could have devised to create you. It was the culture they created. It was them.

I think about that a lot now because I don't run a team anymore and I'm beginning to see situations with teams that are quite different. There's a tension I just can't put my finger on and somebody's already noticed and tried to fix it, but the fix somehow makes it worse. It's always another document or policy or tracker that is supposed to help, but just ends up causing resentment at best. More oversight and reporting is not the solution to a dysfunctional team. Maybe less of that is what's needed. Maybe. It's hard to tell because every dysfunction is as unique as the individuals. I'm not going to sit here and pretend I know the answer for everything but I do know at least one thing: you can't fix the culture with a new process, or even a new team.

When a project is sick, the symptoms might show up in the schedule and the budget but the disease is in the organization. When the project meetings are quiet, that means people have stopped telling the truth. That is a team that's learned it's safer to stay quiet than raise a hand. Nobody trusts anybody. You can throw every tool in the world at that and the project will still limp. But make it safe to speak up, safe to fail, safe to disagree out loud, safe to air out an idea that might sound terrible at first, and that same team can be wildly productive.

You've heard that culture eats strategy for breakfast. I'd go one further: Culture is the cure.

When I walk into the mess, I'm not looking for a better spreadsheet. I'm listening to how people talk to each other. Fix that and you'd be amazed at what fixes itself.

I had dinner with a friend recently. She's a sharp, capable project manager, the kind of person you'd want running your toughest job. And she spent most of the evening deflated, worn down by a boss who is, by her account, the micromanager from hell.

You know the type. Every email cc'd. Every decision second-guessed. Every task chased with a "did you do it yet?" before the ink is even dry. She told me she's mostly stopped making decisions at all, because why bother if they'll just get overturned. And there it is. That's the whole tragedy of micromanagement in one sentence.

Here's the thing nobody tells the micromanager: You're undermining your own team. I know that control can feel like safety. (If I touch every piece, nothing can go wrong). But it always goes wrong, because now you've got a whole team of talented people who've quietly stopped thinking. They're not stressing about project decisions anymore, instead they're stressing about the eggshells around your office. You haven't mitigated any risk because it's all still there. What you have done is deflated your team and pretty much ensured that they are not fully engaged. It's the backseat driver effect. When someone in the back seat is giving you directions, what are the chances you miss the next turn the moment they start talking to someone else back there? Every micromanager seems to forget that while they can make decisions, they are not engaged with the project full time. What happens when the Project Manager has their hands tied and the micromanager is busy managing someone else's project?

I've told my own Project Managers for years that each of their teams has a leader, and you must be comfortable letting them lead. This is what you're paying them for. The Architect and GC know what they're doing. A successful Project Manager can navigate the rocks without hindering the project leadership. It's fascinating to me that risk-averse leaders can end up taking on so much more risk just by being afraid to let someone else manage that risk. The micromanager from hell isn't a monster though. She's just tired, and afraid, and holding on so tight she can't feel her own hands anymore. Real leadership takes courage, and the bravest thing a leader can do is to let go of the wheel and trust the people you hired to sail.

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.