If you've worked capital projects in an operating facility, you know that kind of schedule pressure. It shapes everything, starting with how the work gets scoped before a single bidder ever walks the site.

Both projects were infrastructure upgrades. Not new equipment, not a expansion. Improvements to existing assets. One was a wall coating replacement in a kitchen area. The other was a full roof replacement, TPO membrane, over a large section of the facility. On paper, neither one sounded complicated. Two straightforward scopes, two weeks, two crews. What could go wrong.

Project One: The One That Went Right

The wall coating project is worth mentioning because of what we did well, not because anything dramatic happened.

We used hand grinders and diamond blades to remove the old coating and prep the concrete for the new one. We built proper containment, sealed it with plastic, and ran ventilation to the outside so we were actually cleaning the air as it moved through the space instead of just pushing dust around.

The part that mattered most wasn't the technical execution. It was the communication. I took photos every day. I wrote daily reports. I sent progress updates that told plant leadership and the corporate team three things: how we were tracking against the plan, what the risks were to hitting our startup date, and what we were doing about them.

That transparency did a lot of quiet work. Nobody upstairs was wondering what was happening behind the plastic sheeting. When you're asking a facility to trust you with two weeks of downtime, that kind of visibility is not optional. It is the job.

Project Two: Where the Plan Met the Roof

The roof replacement started the same way. Cones out, barriers up, access points defined. We demoed the existing membrane and started pulling off the layer underneath, some kind of wood sheathing.

That's when things got interesting.

As we pulled the old sheathing free, we started backing out eight inch long screws. Long enough that I already suspected this job was going to outlast our two week window. We didn't panic about that part. The roof was external to the building, sitting over a warehouse section rather than an open product area, so the schedule risk felt manageable. Low consequence, we figured, if it ran long.

What I hadn't accounted for was what was happening underneath those screws, not just around them.

I climbed up onto one of the lines to get a better look at what was going on below the roof deck. That's when I noticed it. Those eight inch screws weren't just anchoring the sheathing. Some of them had pierced electrical conduit from the original installation. And as we backed them out, the vibration was shaking loose dust and debris, sending it falling into spaces we hadn't planned for at all.

Most of that fallout landed over the warehouse, which was a problem but not the worst version of the problem. The worst version was directly below a can de-palletizer, a piece of equipment feeding open, unlidded cans toward the filling line. Cans that would become finished product. Cans with nothing between them and whatever was now raining down from the roof deck above.

That is the moment a routine infrastructure project turns into a food safety event waiting to happen.

The Scramble, and What It Cost Us

We didn't have the luxury of redesigning the sequence. The facility needed to come back online. So we improvised an emergency mitigation on the spot: draped plastic sheeting above the de-palletizer and built a false ceiling to catch anything falling through before it reached the open cans.

It worked. But it was scope nobody had planned for, priced for, or scheduled for. It drove a change order, and it drove another one right behind it. Because once we found screws piercing conduit, we couldn't just leave it. Some of that conduit turned out to be abandoned, dead and safe to demo. Some of it was still live, still active, and had to be properly replaced.

Two small discoveries. Two change orders. Neither one catastrophic on its own. But both entirely avoidable if the front end investigation had gone one layer deeper before the bid package went out.

Where the Real Lesson Lives

Here's what I keep coming back to. Both of these projects were "simple" upgrades to existing assets. No new equipment, no unfamiliar systems, nothing that should have surprised anyone with real field experience. And yet the surprises still found us, because the thing we were replacing was not the thing that mattered. What mattered was everything attached to it, buried beneath it, or operating underneath it while we worked.

I climbed up on that roof. I did look. And I still missed the conduit until the screws started coming out. That's not a confession of incompetence, it's an honest look at how easy it is to under scope the investigation phase when a project looks routine and the clock is already running.

So how do we, as the people scoping these jobs on the front end, actually get better at this? I've started thinking about it as three questions that should get answered before a single line item goes into an RFP.

Comment

A Framework for Front-End Risk Discovery

Look Up. What is above this work, and what happens if something falls, leaks, or drops through during execution? On the roofing project, that meant asking what sat directly below every square foot of deck we were about to disturb, not just what sat below the building in general.

Look Down. What is buried in, attached to, or running through the asset you're removing? Conduit, piping, abandoned infrastructure from a decade of prior work, it's rarely visible until you're mid-demo. Assume it's there and verify, rather than assuming it isn't and being surprised.

Look Around. What is still operating adjacent to this work while you're doing it? A can de-palletizer running beneath a roof deck is a food safety risk. The same work above an empty storage bay is a Tuesday. Context changes the entire risk profile of identical work.

None of these questions require new tools or new budget. They require time, on the front end, before the RFP goes out and the schedule gets locked. That's the hard part. Time is exactly what feels most expendable when you've got a two week shutdown window and a plant waiting to restart.

But the change orders, the emergency mitigations, the scrambling to protect open product with plastic sheeting and plywood, all of that costs more time than the investigation would have. It just costs it later, when you have less room to absorb it.

If I'd walked that roof with those three questions in mind before we ever started pulling screws, I'd have caught the conduit risk in the estimate instead of in the field. I'd have planned for the de-palletizer exposure instead of improvising around it. The work still would have taken the same two projects, the same two weeks of pressure. But it would have looked a lot less like discovery, and a lot more like execution.

That's the standard I hold myself to now. Look up, look down, look around, before the bid goes out, not after the screws start coming loose.

Subscribe

Projects don’t usually fail because someone poured concrete wrong or installed the wrong equipment.

They fail because the project wasn’t clearly defined before execution ever started.

Everyone wants to talk about schedules, budgets, and Gantt charts. Those matter—but they’re not where successful projects begin.

Successful projects start with clarity.

Before a dollar is spent, everyone should be able to answer a few simple questions:

• What problem are we actually solving?

• What does success look like?

• Who owns the decision?

• What assumptions are we making?

• What could derail this project before we even start?

When those questions aren’t answered, teams spend months solving the wrong problems.

I’ve seen million-dollar projects delayed because no one aligned on scope early enough. I’ve also seen relatively small projects finish ahead of schedule simply because everyone knew exactly what “done” looked like.

One lesson I’ve learned is this:

Confusion compounds. Clarity compounds faster.

The more time you invest defining the project upfront, the less time you’ll spend fighting change orders, explaining decisions, and putting out fires later.

It’s not glamorous work.

But it’s the work that separates good project managers from great ones.

Over the coming weeks, I’ll be sharing the tools, templates, and systems I’ve used to manage capital projects more effectively—from early feasibility through execution and closeout.

If you’re responsible for delivering projects, I hope you’ll follow along.

Subscribe

They fail in a fifteen-minute conversation that nobody bothered to have.

Here is the pattern I’ve watched play out more times than I can count: someone has a project idea. It sounds good. Leadership is excited. Everyone wants to move fast. So the team skips straight to planning — timelines, budgets, contractors — and nobody stops to ask the boring questions.

• What problem are we actually solving?

• Who needs to sign off on this?

• What does “done” even look like?

Six months later, the project is over budget, behind schedule, and half the stakeholders are asking why nobody told them about the electrical work. That’s not a planning failure. That’s an initiation failure. And it’s almost always preventable.

Initiation is the cheapest insurance you’ll ever buy

In project management, there are five process groups: Initiation, Planning, Executing, Monitoring & Controlling, and Closing. Everyone loves talking about Executing — it’s where the visible work happens, where you can point to progress. Nobody wants to slow down for Initiation, because on paper it looks like paperwork.

But Initiation is where you define the project and identify who actually has a stake in it. Skip it, or rush it, and you’re not saving time — you’re just moving the cost of that shortcut downstream, where it gets more expensive to fix.

I learned this the hard way on a garage addition early in my career. The scope felt “obvious” going in. It wasn’t. Halfway through, we discovered nobody had confirmed electrical loads with the client, and what should’ve been a two-day fix turned into a two-week delay. The cost wasn’t just money — it was trust.

Share

The two documents that would have saved me

If I could hand my younger self one thing, it’d be a simple system for capturing project ideas before they become expensive mistakes. Two documents do almost all the work:

The Project Ideation Log. This is just a running backlog — every project idea in one place, with rough budget, stakeholders, and target dates attached. It doesn’t need to be fancy. It needs to exist. Whoever’s watching the business — a plant manager, a department head, a PM — should be able to glance at it and know what’s coming.

The Project Approval Form. One to two pages, max. Before anyone commits real time to a project, someone writes down the business case: why this, why now, roughly what it’ll cost. This gets reviewed by the people who control the budget. If the project’s not viable, you find out here — not three months in.

Only after a project clears that gate does it earn a full Project Charter: the document that nails down scope, budget, timeline, risks, and who’s responsible for what. Think of the charter as the contract everyone agrees to before the real work starts. It should answer the unglamorous questions up front — who needs to be notified, what happens if there’s an electrical scope nobody planned for, who’s paying for shipping, who signs off on the final result — so those questions don’t ambush you at week six.

The best scope documents tell a story

Here’s something that took me years to internalize: a good project scope isn’t a checklist. It’s a narrative. It should read like you’re walking someone through the project from start to finish, so clearly that a stranger could pick it up and understand exactly what “success” looks like.

The checklist still matters — the risks, the vendor terms, the safety equipment, the RACI chart defining who’s Responsible, Accountable, Consulted, and Informed. But checklists don’t build alignment. Stories do. If your stakeholders can’t picture the finished project from reading your scope, you haven’t finished writing it.

Walk the job before you price the job

One habit I’d tell any new PM to steal: walk the site with multiple contractors before you lock in scope. It’s not just about getting competitive bids — though that matters. It’s that every contractor who walks the job sees something you missed. A subject matter expert standing in the actual space will catch a constraint or a risk that never would have surfaced in a conference room.

The real lesson

None of this is about paperwork for its own sake. It’s about respecting the fact that a capital project — a new home, a factory line, a piece of equipment with a useful life measured in years, not days — deserves more than good intentions and a start date.

Slow down at the beginning so you don’t have to slow down, apologize, and re-explain yourself at the end. That’s the whole trade. It’s a good one.

Subscribe

Over the years, I've had the chance to work with some great people on projects where the end goal was getting a brand new product into the marketplace. I can't share most of those stories in full — NDAs are NDAs — but I can lean on that experience, and more importantly, I can walk you through my own path of bringing two products to market: a manufactured egress window cover, and a self-help e-book.

Neither of these are massive, venture-backed success stories. They are real, scrappy, self-funded journeys, and I think that's exactly why they're useful. Here's what I learned, step by step, and what I'd tell anyone starting down a similar road.

Finding the Problem: The Egress Window Cover

The idea came to me almost by accident. I was exploring different cities to potentially move to, and I noticed something odd: a lot of houses with basements had egress window wells, and most of them were left wide open. No covers.

I wondered why, and the answer became obvious pretty quickly. The covers that existed on the market required either a trip to pick one up from a local distributor, or a full installation crew showing up at your house. Neither of those is a dealbreaker, exactly, but we live in a world where people expect to order something online and have it land on their doorstep, ready to install themselves. That gap was the opportunity.

That is step one of bringing any product to market, and it's the step people skip the most: find an actual problem worth solving. Not a feature you think is cool — a friction point real people are already living with.

Market Research: Trusting the Gap, Then Testing It

I started researching what was already out there. The cheap plastic covers lacked the durability I wanted to see. The premium options all routed through distributors or full-service installers. There was a real market — I could see it in how many businesses were operating in that space — and there was a real gap in how the product reached the customer.

I'll admit, some of my conviction came from my own bias: I knew that if I bought a house with a basement, I'd want my wells covered, and I'd want it delivered to my door. But at some point, you have to stop analyzing and start testing. I'm naturally an over-analyzer, and I recognized that I simply didn't have enough information to make a fully confident decision — so I made the call to move into prototyping instead of waiting for more data that wasn't coming.

If you're too afraid to put a little money on the line to find out, you'll never move past the idea stage. That's true of nearly every product I've seen go from concept to shelf.

Product Development: Specs, Prototypes, and Field Testing

I'd spent my early career as a drafter and designer, so building the prototype in-house was within reach. If that skill hadn't been there, partnering with a local fabrication shop would've been the move and honestly, that's the right call for most people at this stage.

I went out into the field and measured actual egress window wells, recorded the dimensions, and brought them into AutoCAD. One size came up again and again in a particular neighborhood, so that became my starting point.

Then I built out a ranked list of what the product actually needed to deliver:

• Shippable

• Lightweight

• Kid-friendly

• Durable

• Cost-effective

• Quality

• Visually appealing

From there, I broke each one down further — could it ship in pieces? Could slots reduce weight while still letting light through? Could a hinge or bolt system make it removable by a kid in an emergency, while still standing up to a 200-pound adult walking across it? Every design decision traced back to one of these requirements.

The first prototype came together in three equal sections, sized to fit a 52" by 36" well. I tested fit and function first, then loaded it with weight. It held a 200-pound guy with minimal flex — but "minimal" wasn't "none." So I drilled holes into the flanges to bolt the sections together, and that one field modification drastically increased the rigidity. That's the iterative loop in action: design, test, find the weak point, fix it, test again.

After that, I sourced a local shop for powder coating and was genuinely happy with the result. A friend who needed covers for his own home asked if I'd build him five. I didn't make money on that batch — I basically donated the labor and customized the units to seal the deal — but it was worth every hour. It put product into the field for real-world, long-term durability testing I couldn't have replicated any other way.

The Business Side: IP, Planning, and Funding

Since I was self-funding, I held off on patents or trademarks at the prototype stage — that's a decision worth revisiting once a product proves itself, not before.

I did put together a business plan: target market, marketing approach, rough financial projections. I didn't over-engineer it, but having something to anchor to kept me focused and honest about where I actually was versus where I thought I was.

On funding, here's the one piece of advice I wish someone had handed me directly: take the number you think you'll need, and double or triple it. Payment terms from suppliers help, but you still need real cash on hand, and self-funding this kind of project always costs more than the spreadsheet says it will.

Manufacturing, Quality Control, and the Unsexy Details

I spent a lot of time here — getting quotes from suppliers across different quantities, packaging styles, and regions. I landed on a manufacturer that built in batches of ten and shipped via wooden crate, which turned out to be the sweet spot for cost and lead time. I'd uncrate them on arrival, then individually group and package each unit myself.

Quality control came together through real conversations with suppliers about surface finishes, bending techniques, and CNC capabilities. We landed on a process: laser or plasma cutting, press brake forming with segmented tooling, SP6 commercial blast cleaning for surface prep, and a high-solids poly or powder coat finish in either Mahogany Brown or Aluminum Gray. None of that is glamorous. All of it is what makes the difference between a product that holds up and one that doesn't.

Branding, Packaging, and Getting It in Front of People

For packaging, I found a box from U-Line that fit the product perfectly — sometimes the boring logistics question has a simple answer if you look.

Branding was harder, and honestly, still is. We chose not to reinvent the wheel and kept the product under my name, since it's a genuine extension of what that brand is about. We've been building that presence through LinkedIn and Facebook, and through a website built on WordPress and Bluehost that's gone through more than a few iterations as we've figured out what actually represents the work.

Distribution, for now, runs direct and that's a space I'm still actively building out, alongside marketing, sales channels, and everything that comes after a product exists but isn't yet in front of the people who need it.

Product Two: "Earn Your Success!"

The second product was a completely different animal: a self-help e-book called Earn Your Success! A Journey Towards Contentment, Growth, and Opportunities, now live on Amazon.

Earn Your Success!

The "problem" here wasn't a physical gap in a market — it was something more personal. I'd lived through enough of my own professional and personal growth, enough hard-won lessons about perseverance, mindset, and figuring out what actually matters in a career and a life, that I wanted to put that into a structure other people could use. The book moves through personal growth, financial literacy, adaptability, leadership, and time management, then pushes into finding genuine purpose and direction, and finally into the discipline of not giving up when things get hard.

Where the window cover taught me fabrication and supply chains, the e-book taught me an entirely different production process. I knew the substance — the lessons, the structure, the voice I wanted — but I'm not a professional writer, so I brought in a ghostwriter to help shape the manuscript into something polished and readable while keeping it authentically mine. For the cover, I went to Fiverr and found a designer who could turn the concept into something that actually stood out on a crowded Amazon shelf.

That's really the core lesson from this second product: you don't have to be the expert in every part of the process. You have to know what the final product needs to be, and then go find the right people to help you get there. With the garage covers, that meant fabricators and powder coaters. With the book, it meant a ghostwriter and a cover designer. Same philosophy, completely different toolbox.

What Both Products Taught Me

Looking at these two side by side — a steel window cover and a self-help book — they couldn't be more different on the surface. But the underlying path was nearly identical: find a real problem or a real need, test your assumption before you're fully confident in it, build a rough version, get it in front of real people, and let their feedback shape what comes next.

Neither of these products turned into a massive business overnight. That's not really the point. The point is that both of them exist now, out in the world, doing what they were built to do — covers protecting basement window wells across actual homes, and a book sitting on Amazon helping someone work through their own version of growth and contentment.

If you're sitting on an idea right now, wondering if it's worth pursuing: it probably is, if it's solving something real. The only way to find out is to stop analyzing and start building — even if "building" just means a rough prototype, a messy first draft, or a conversation with the right person who can help you get from idea to shelf.

Message me

That description isn't wrong. It's just radically incomplete.

The longer I work across both residential construction and industrial project environments, the more convinced I become that "project manager" is one of the most misunderstood job titles in business. The title suggests administration — tracking, scheduling, checking boxes. The actual job is closer to running a small, temporary company. A PM is a mini-CEO, and almost nobody tells them that going in.

The Job Behind the Job Title

Think about what a CEO actually does, stripped down to fundamentals. They have to:

• Make the case for why the business deserves capital

• Secure that capital from people who control it

• Assemble the right talent and coordinate across functions that don't naturally agree

• Resolve conflict when priorities collide

• Manage the money — spending, forecasting, and reporting on it

• Deliver a result that justifies the investment

Now look at what a project manager does on any job of real size. Before a single piece of work starts, the PM has to build the business case — translating scope into dollars and dollars into value stakeholders actually care about. That's not paperwork. That's persuasion. You're asking someone to release capital based on your credibility and your numbers, the same conversation a CEO has with a board or an investor.

Once the money is approved, the PM becomes the connective tissue between disciplines that don't speak the same language. Engineering thinks in tolerances. Procurement thinks in lead times. Finance thinks in variance. The trades think in sequence and access. None of those groups is wrong — they're just optimizing for different things, and someone has to translate between them and keep the disagreements from becoming delays. That's not scheduling. That's executive coordination.

Then there's the money itself, which never stops moving. A PM is signing contracts and purchase orders, committing the project to obligations with real legal and financial weight. They're tracking actual spend against budget in real time, and — this is the part that separates a project manager from a project coordinator — forecasting the estimate at completion. Not "how much have we spent," but "based on what we know right now, where will this land, and does that still make sense for the business." That's the same forward-looking judgment a CFO exercises, just compressed into a single job and a single project instead of an entire company.

And underneath all of it sits cash flow. Knowing not just the total cost of a project, but when money needs to move — when draws are due, when vendors expect payment, when the gap between spend and reimbursement could actually stall the work — is a financial planning function. Get it wrong on a long project and you don't just have a budget problem. You have a liquidity problem, the exact thing that keeps CEOs and CFOs up at night.

Why This Distinction Matters

I think this gap — between what the title implies and what the job actually requires — causes real damage, in both directions.

For organizations, it means project managers often get hired, trained, and evaluated like administrators when the role actually demands business judgment. Companies look for someone who's organized and detail-oriented, and then hand that person authority over six and seven-figure financial decisions, cross-functional leadership, and stakeholder management — without ever naming that this is what they're actually being asked to do. The skills gap that shows up later, when a PM struggles to hold the financial narrative together or freezes during a stakeholder conflict, often isn't a competence gap. It's a role-definition gap. Nobody told them the job was bigger than the title.

For the PMs themselves, the cost is different but just as real. Plenty of capable project managers undersell what they do, because they've absorbed the narrow version of the title. They describe their work as "keeping the project on track" when what they actually did was build a business case, negotiate scope with skeptical stakeholders, manage a portfolio of vendor contracts, and forecast cost-to-complete on a moving target. That's not project coordination. That's executive function, just without the executive label or compensation that usually comes with it.

The Practical Upside of Naming It

I don't think this is just a semantic argument. Naming the job accurately changes how people do it.

A project manager who understands they're running something closer to a business than a checklist starts asking different questions. Not just "are we on schedule," but "does this project still make financial sense given what we know now." Not just "did the work get done," but "did it deliver the value we promised the people who funded it." That shift — from task tracking to value ownership — is the difference between a PM who executes a plan and one who's actually accountable for an outcome.

It also changes how PMs should be developed and supported. If the role genuinely requires business case development, financial forecasting, stakeholder negotiation, and conflict resolution across competing interests, then training people exclusively on scheduling software and risk registers is preparing them for maybe half the job. The other half — the part that looks a lot like running a company — usually gets learned the hard way, through painful experience, because almost nobody teaches it directly.

I've seen this play out on projects ranging from a single residential build to multi-million-dollar industrial installations, and the underlying pattern doesn't change with scale. The PM who treats the role as administrative — track the schedule, log the issues, report the status — does an adequate job. The PM who treats it as a temporary CEO role — own the business case, manage the relationships, forecast the financial trajectory, and stay accountable for the value delivered — does a fundamentally different one.

Same title. Very different job.

The Reframe

If you manage projects for a living, I'd encourage you to sit with this for a second: you are not just coordinating tasks. You are running a temporary business with a defined start, a defined end, a P&L of sorts, and a board of stakeholders you have to keep convinced. The scope changes. The stakes change. But the core function — make the case, secure the resources, coordinate the execution, manage the money, deliver the value — is the same function a CEO performs, just compressed into a shorter timeline and a narrower mandate.

It might be worth describing your work that way. Not to inflate the title, but because it's a more honest description of what you're actually accountable for. And the organizations that get this right — that train, support, and compensate PMs as the business leaders they actually are — are the ones that will consistently deliver projects that don't just finish on time, but actually deliver the value they were funded to create.

He was thrilled. And honestly? So was I.

That text is exactly why I do this work.

The Project

A few years ago, I built a 1,500 square foot, three-car garage addition onto an existing house, enclosing the old porch area in the process. We modeled the entire thing in 3D AutoCAD before a single footing went in the ground, and we spent real time on the front end — walking through every detail together, all the way down to paint colors and roofing material.

The owner was part of the design from day one. My role was to guide him through the decisions: here's what this costs, here's what it gets you, here's the tradeoff. That kind of collaboration is where the good stuff happens.

A few of the choices we made didn't add much cost but added a disproportionate amount of value:

• Oversized 9'x18' garage doors — practical, but also just a more impressive presence for the space

• Trey ceilings — small architectural upgrade, big visual payoff

• Extensive electrical circuits — built for how he'd actually use the space, not just the minimum code

• Belt-drive garage door openers with built-in cameras — quieter operation, plus the ability to monitor the garage remotely

• A metal roof, cut in cleanly under the existing house windows, instead of the cheaper standard option

None of these were the cheapest path. Altogether, they probably added 10–15% to the project cost. But that 10–15% is the difference between a garage that functions and a garage the owner is still texting me about, unprompted, years later — happy, enthusiastic, genuinely satisfied.

Why This Matters More Than the Garage

Here's the thing — this project happened to be residential, but most of my work has actually been industrial, specifically in food manufacturing. And the lesson is identical: projects are about value, not just completion.

A project that gets finished on time and on budget but doesn't deliver real value isn't actually a success. It just looks like one on paper. Those are two very different outcomes, and the gap between them is where most of the real risk in project work actually lives.

Where Value Gets Lost

I've seen this play out too many times in the industrial world. A business case gets written, value gets projected — sometimes accurately, sometimes not — capital gets approved, and the asset gets installed. And then one of a few things happens:

The business changes. A line gets built to run a specific product at a specific volume, and eighteen months later the product mix shifts, a customer contract ends, or the company pivots strategy. The asset still works perfectly. It's just no longer pointed at the right problem.

The original assumption was wrong from the start. Maybe the volume projections were optimistic. Maybe the business case leaned on a sales forecast that never materialized. Maybe nobody stress-tested the assumption hard enough before the capital was approved, because the project had momentum and nobody wanted to be the one to slow it down.

Or the value was real, but it never got fully captured. The equipment goes in, it runs, but the operational changes needed to actually realize the projected savings — staffing adjustments, process changes, training — never happen. So you've got a capable asset being run in a way that leaves most of its value on the table.

Any one of these results in the same thing: a piece of capitalized equipment sitting on the floor, partially used or not used at all. That's not a hypothetical. That happens more than most people in this field want to admit, and it's rarely because anyone did anything wrong on purpose. It's usually a slow drift — a good plan meeting a business reality that moved faster than the project did.

What Good Value Capture Actually Looks Like

The garage project worked for a simple reason: the value case was clear from the beginning, and every decision — even the more expensive ones — was made in service of that value, not in spite of it. The owner wasn't paying for upgrades for the sake of upgrades. He was paying for a space that would actually work the way he needed it to, for years, in ways he could feel every time he used it.

I try to carry that same discipline into industrial work, even though the stakes and the scale are completely different. Before a project gets capital approved, the questions worth asking are the same ones we walked through in that garage design: What does this actually need to do? What's the real cost of getting it slightly wrong? Where is the value actually going to come from, specifically, and who is accountable for making sure it shows up once the equipment is running?

That last one matters more than people give it credit for. A business case isn't a one-time document you write to get approval and then file away. The value has to be tracked after startup, not just projected before it. Otherwise you find out two years later — the hard way — that the case never materialized, and nobody noticed until someone went looking.

The Standard

That's the standard I try to hold every project to, whether it's a homeowner's garage or a processing line running food product. Did this actually deliver what we said it would? Is someone genuinely better off because this got built? Is the asset doing what it was capitalized to do, or has the business quietly moved on without anyone updating the plan?

When the answer is yes, you get a text message with a photo of kayaks coming down out of a garage ceiling, from someone who didn't have to send it.

That's the whole job, right there.

Subscribe

I expected to need time to think about it. I didn’t. The answer arrived almost instantly: FOCUS.

Not a person. Not a circumstance. Just the simple, maddening inability to be where I am, doing what I’m doing, without my attention fracturing into a dozen directions.

The Noise Is the Goliath

We live in a world engineered to interrupt us. Social media, push notifications, texts, emails, the news cycle - every minute carries some small vibration demanding a piece of our attention. None of these interruptions feel like much on their own. A glance at a notification. A quick check of email. Thirty seconds, easy.

But thirty seconds, a hundred times a day, isn’t thirty seconds. It’s death by a thousand cuts to your concentration.

Here’s the thing I keep coming back to: mental energy is finite. You wake up with a certain amount of it, and every interruption, even the ones you barely register, spends a little of it. By the time you sit down to do the work that actually matters, or look up at the person who actually matters, you’re running on fumes you didn’t know you’d burned.

If mental energy is that valuable, why do we spend it so carelessly? We protect our money. We protect our time, at least on a calendar. But we let our attention get picked apart by anything that buzzes.

The Friday Afternoon Email

I’ll give you a specific example, because abstractions are easy to nod along to and hard to actually feel.

It’s Friday afternoon. An email comes in. I open it, because of course I open it, and it’s something that genuinely cannot be addressed until Monday. There is nothing productive I can do with this information right now. And yet I carry it. Into the weekend. Onto the trail while I’m hiking. Into the boat while I’m fishing. Into time with my family, where part of my brain is quietly chewing on a problem that hasn’t even started yet.

That’s not diligence. That’s just noise I let win.

So I’ve started asking a different question: what if I changed the system instead of trying to white-knuckle my way through more willpower? What if I checked email once a day, at a set time, with intention, instead of letting it check in on me all day long? Whatever doesn’t get handled that day simply waits for tomorrow, because it was always going to wait until Monday anyway. The only thing that changes is whether I spend my weekend pretending otherwise.

This isn’t really about email. It’s about designing a life where the noise has to ask permission to come in, instead of just walking through an open door.

What Presence Actually Feels Like

Early in my career, I worked relentlessly. I told myself — and honestly believed — that I was present for my young family, because I was there. Physically, mostly. But looking back now, I can see the gap between being in the room and being in the moment. I was thinking about work while I was playing on the floor. I was halfway somewhere else during dinner. I don’t say this with heavy regret — I think most of us go through a season like that — but I needed to live it before I could see it clearly.

Fast forward to now. We just had another baby. And I’ve noticed something different in myself this time: I am here in a way I wasn’t before. Fully absorbed in this tiny person, soaking up the moments instead of just logging them. It’s surreal, honestly, how much more there is to experience when you’re not dividing your attention three ways. The bonding feels deeper. The beauty of it actually lands instead of skimming past me on the way to the next thing on my mental list.

I had a similar moment earlier this month on a hike. No phone in hand, no mental tab open in the background. Just sun, trail, and view, fully absorbed in what was actually in front of me. It was a small thing. It was also one of the best feelings I’ve had all year.

And here’s what I want: I want that to be my baseline, not the exception. I want that same quality of presence when I’m holding my newborn and when I’m buried in a spreadsheet, tuning setpoints on a processing line, or building out a project Gantt chart. Presence shouldn’t be reserved for the moments that are obviously beautiful. The task in front of you, whatever it is, deserves the same full attention as the mountaintop.

Fighting Goliath

David didn’t beat Goliath by matching his size. He used something smaller, faster, and more precise. I think that’s the move here too. We’re not going to out-muscle the noise of modern life by trying harder or gritting through it — there’s always going to be more of it than there is of us.

The win comes from small, precise choices: a set time for email instead of constant checking. A phone left in the other room during dinner. A walk taken without a podcast in your ears, just to let your mind actually be quiet. None of these are dramatic. All of them, repeated daily, are the stone in the sling.

I don’t have this fully figured out. I’m writing this as much to hold myself accountable as anything else. But I know what I’m aiming for now: to be present with whatever is in front of me — baby, hike, spreadsheet, family dinner — instead of mentally somewhere else entirely.

What’s your Goliath? I’d genuinely like to know what you’re wrestling with, and how you’re fighting it.