The Responsibility to Finish

In strength training, a lift isn’t counted until it’s locked out, until control is clear, the bar is steady, and the rep is complete. A squat that’s buried deep but racked before standing tall, or a deadlift that’s ripped off the floor but dropped before lockout, doesn’t earn a place on the scoreboard. The intent doesn’t matter if the execution isn’t finished. The responsibility to finish is about more than effort. It’s about seeing your mission through until the work is undeniable.

A product has a lockout too, and I have watched plenty of teams rack the bar early. A brilliant idea or well-laid plan means nothing if it stalls at 90%. Too often, teams sprint through the exciting early stages, the brainstorming, the whiteboarding, the rush of discovery, and then lose steam when the grind sets in. The last mile demands relentless focus on details that don’t win applause: validating integrations, testing obscure edge cases, polishing onboarding flows, aligning final documentation, preparing enablement, and making sure stakeholders are ready. These tasks can feel tedious, but they are the difference between a product that earns trust and one that frustrates users.

One of the most powerful commitments I made to myself came when Endgame joined Elastic. I promised I would never stop advocating for our Endgame users. Their mission would stay as critical and as deeply embedded within Elastic as it was before we joined. To Elastic’s credit, they readily accepted this challenge. Together, we strengthened our platform until our Endgame customers were not only supported, but measurably better protected than ever before. That was the responsibility to finish in action. The work did not pause at the point of acquisition or integration. We carried it forward until the promise made to users was fully honored.

When a user buys a product you helped create, they’re placing their trust not just in the brand, but in you. Not every product carries the same stakes. Misprinted playing cards might frustrate a game night but won’t bankrupt a family. In cybersecurity, though, you’re building your customers’ shield. They rely on your expertise and vigilance to help defend their business, their livelihoods, and the security of the people who depend on them. When you build security tools, you’re shouldering part of that weight alongside them. If you let the lift drop before lockout, if you stop short of complete, tested, dependable solutions, you leave them exposed.

It’s tempting to skip the late nights of final QA, to brush off corner-case bugs as “edge scenarios,” to let organizational friction excuse mediocrity. We’ve already named that trade: short-term comfort for long-term weakness. In a field where real adversaries wait for missteps, that weakness becomes an open door.

When the Agent Did the Work, You Still Own It

There’s a 2026 version of this responsibility that the book has been pointing at since Chapter 1, and it lands hardest here. The most dangerous line in any review meeting next year is going to be “the AI did it.” If you shipped it, you own it. If you signed off on it, you own it. If you let an agent loose in production and didn’t read what it was doing, you still own it. AI is a teammate, and like any teammate, it can let you down. The responsibility to finish does not transfer. The model did not ship the feature alone, the model did not pick the customer to deploy to, and the model did not write the contract you signed. You did.

In February 2024, Air Canada’s AI chatbot told a grieving passenger that a regular fare could be bought and refunded afterward under the bereavement policy. The policy didn’t actually allow that. When the customer tried to claim the refund, Air Canada argued it wasn’t responsible for what the chatbot said, because the bot was, in their words, “a separate legal entity.” The tribunal disagreed. The airline owned what its chatbot put in writing. A court already disagrees with “the AI did it.” I have a lot more to say about what that means for how we work, and it is waiting in the chapter on AI.

Taking personal responsibility for everything you build is not about perfectionism. It’s about integrity, about knowing that when you commit to finishing, you honor the trust your users place in you. Let that trust drive you. Let it fuel you to embrace their mission as your mission. What you start may inspire, but what you finish defines you. Only when you lock out the lift does your work count.