Kirk Kendall | Why the Best Project Managers Think Like Engineers

Kirk Kendall

There's a particular type of project manager who tends to be excellent at managing complex industrial work. They're methodical. They think in systems. They don't accept vague answers. They understand that small details compound into major consequences.

These are people who think like engineers, whether they have the degree or not.

Kirk Kendall is an engineer, and it shapes how he approaches project management fundamentally. He doesn't just manage schedules and budgets. He manages the engineering logic underneath the project. He understands that if a design assumption is wrong, it will cascade through the entire project. He understands that how you construct something is different from how you design it, and you have to account for both.

The best project managers he's worked with—not all of them had engineering degrees—shared an engineering mindset. They asked the right questions. Why would that approach work? What are we assuming? What would happen if that assumption was wrong? They weren't satisfied with "that's how we always do it." They wanted to understand why.

This matters because industrial construction is fundamentally about solving constraints. A site has boundaries. Equipment has specifications. Timelines are fixed. Regulations are non-negotiable. The question is: how do you make everything work together? That's an engineering problem.

Some project managers approach it like an administrator. They create schedules, assign people, track progress. But they don't engage with the engineering logic underneath. They might not understand why a particular sequence is necessary, so they try to change it to accelerate the schedule—and don't understand why that creates cascading problems.

An engineer-minded project manager understands that sequence matters. If you're installing equipment in a sequence, you can't reverse that just because you're behind schedule. The foundation has to be built before the structure. The structure has to be complete before mechanical work. These aren't arbitrary—they're determined by the physical reality of what you're building.

The same applies to specifications. On a project, there are specifications for materials, for quality, for methods. An engineer-minded project manager understands why those specs exist. They're not compliance overhead. They're the minimum requirements to achieve the outcome you're trying to achieve. Skip them and you don't save time—you create problems that cost you more time and money later.

Kirk has seen the difference in how teams approach problems. One team has a delay. The project manager, thinking administratively, just tries to accelerate other activities. He doesn't ask whether that's actually feasible given the constraints. An engineer-minded project manager asks: what's really delaying us? Is it a resource constraint? A design constraint? A supply chain constraint? Is there something else on the critical path we should be working on instead? The diagnosis is different, and therefore the solution is different.

There's also something about engineering training that creates healthy skepticism. An engineer is trained to check. To verify. To ask for evidence. Not in a paranoid way, but as standard practice. Does that supplier actually have that equipment available? How do we know the site is actually as described in the surveys? What happens if the design calculations are off by 10%?

This skepticism, applied to project management, catches problems early. It prevents assumptions from becoming planning basis without verification. It catches changes before they cascade.

An engineering approach also brings systematic problem-solving. When something goes wrong, an engineer-minded project manager doesn't just react. He diagnoses. What's the root cause? What needs to change to prevent it from happening again? Is this a one-time event or a symptom of something systemic?

One of Kirk's principles is that strong execution comes from repeatable systems. That's an engineering concept. You don't just manage each task independently. You design a system of how work gets done. Then you improve the system based on what you learn. You document it so that people understand what they should be doing. You measure it so you know whether it's working.

This systematic thinking prevents the chaotic "we solve every problem by working harder" approach that exhausts teams. If you're constantly solving the same problem in different ways, you have a system problem, not an execution problem.

Engineering-minded project managers also tend to take safety seriously as a function of planning, not as an add-on for compliance. An engineer thinks about failure modes. What could go wrong? What safeguards prevent it? What monitoring tells us if it's developing? Applied to jobsite safety, that's: what hazards exist? What controls prevent injuries? How do we verify the controls are working?

This is different from a compliance approach where you have a checklist and you verify you're checking boxes. An engineering approach asks whether the actual hazard is actually controlled.

There's a last dimension: engineering training emphasizes clarity in communication. Drawings. Specifications. Calculations. Everything is documented in a way that can be checked and verified. An engineer-minded project manager brings that to project management. Things are clear. Requirements are documented. Expectations are specific. That clarity is what removes ambiguity.

In the best projects Kirk has worked on, the project manager understood the engineering logic underneath. That shaped how he sequenced work. What he emphasized in planning. How he made decisions when surprises occurred. It made him effective because he wasn't just managing administratively—he was managing the actual constraints and logic of the work.

This is why strong engineering backgrounds in project management matter. Not that you have to have a degree. But the mindset—the systematic thinking, the verification, the focus on understanding root causes, the clarity in communication—that makes project managers better at managing complex industrial work.