Internal Strength for External Load

Strength isn’t just about what you can lift. It’s about what you can withstand.

Anyone can show up strong once. But the mission demands more than that. It demands repeatability. Resilience. The ability to show up strong again and again, under pressure, under uncertainty, under load.

That kind of strength doesn’t come from testing yourself every day. It comes from building yourself for the test, from the inside out.

We know this intuitively in lifting. If you neglect your stabilizers, your joints, your breath control, your bracing, it doesn’t matter what your numbers look like. You’ll break. The biggest total in the gym means nothing if your back gives out the next week. True strength isn’t just output. It’s the integrity of the system supporting it.

The best lifters don’t chase the max. They train the margin.

That’s what Amanda Lawrence understands. A multi-time world champion powerlifter, Amanda is famous not just for her records — squatting over 600 pounds raw at 84kg — but for her poise under pressure. She visualizes every meet lift weeks in advance, rehearses the rituals, manages recovery like a professional sport. She doesn’t just train her muscles. She trains her nervous system, her mental process, her ability to stay composed under load.

That internal strength — not just quad size or grip — is what lets her hit massive lifts on the world stage, even when the bar bends and the cameras are rolling.

They Trained the Tendons of the Product, Not Just the Muscle

The same applies in product.

Notion wasn’t always a darling. In 2015, they were nearly dead. No traction. Technical debt piling up. The team had two choices: patch the pain and push forward, or stop, go dark, and rebuild the core from scratch.

They chose the hard route. Two engineers rewrote the entire editor engine over 18 months. No releases. No hype. Just deep technical investment in a stronger, more flexible system. They bet that the internal strength of the product, not surface-level features, would determine their long-term viability.

They were right.

That rebuilt core became the foundation for everything that followed: blocks, embeds, team permissions, scalable collaboration. The invisible architecture made possible everything the user eventually saw. What saved Notion wasn’t a sprint. It was a rebuild.

Throughout my career, I’ve seen how scale and stability work is often dismissed as unexciting, not flashy enough for slides, not “pressable” enough for headlines. Some leaders fall into the trap of always needing something new to talk about. Something shippable. Something that demos well.

But that pressure leads to bloated products, incoherent strategies, and worst of all, users who suffer when the product finally gets real-world load.

When everything matters most, the engine breaks.

Here’s the truth: capability refinement is not the boring work. It’s the hard work. It’s where the most difficult engineering problems live. It’s where the most intricate, high-stakes user requirements get applied. Not in the pitch deck, but in the heat of usage.

Building a reliable core doesn’t mean every startup needs to design for a Fortune 10 on day one. But it does mean they need to carve out time in the roadmap to move deliberately toward that direction. They need to ask the hard questions early. Not just “What are we building?” but “Who are we building it for?” And just as critically: “Who are we not building it for?”

You cannot build for every user in every vertical in every geo all at once. Trying to do so leads to brittle systems and vague products that serve no one well.

As we said in earlier chapters: laser focus is strength. Define your product requirements. Define your user. Define the scale. Define your edge cases and your tests. Then do the work, especially the work that doesn’t make the press release.

Because that’s where real durability comes from. Not the big reveal. The boring reps.

A Story I’ve Lived

As I described in the prologue, in July 2016 my engineering lead and I stood on the floor of the Combined Air Operations Center at Nellis, watching our agent run through a live Air Force exercise. The story behind that moment starts here.

Early at Endgame, after CEO Nate Fick made the difficult but necessary decision to narrow our product portfolio to one core offering, engineering leader Tony Meehan and I found ourselves at a crossroads.

The product we had was powerful. It delivered real results and we had major enterprise deals on the horizon. But the architecture wasn’t built for scale. The team had shown clearly that it wouldn’t hold as we moved into larger opportunities.

We could have coasted. Closed deals. Deferred the hard part.

But we knew that if we built a base of users on that foundation, the eventual transition would be expensive and painful.

So in early 2016, we made the call to rebuild. We moved the front end to a more modern language, redesigned the back end with a new queuing architecture, and rewrote how the endpoint agent communicated with the platform. All of this had to be done in under six months, alongside new features, for a critical delivery with the U.S. Department of Defense.

It was brutal. Long hours. Hard conversations. Constant doubt.

But participating in that live DoD exercise, watching operators succeed with what we had built, it was clear. The effort had been worth it.

The new architecture held. It scaled. It supported the mission until we joined Elastic in 2019.

Internal strength isn’t flashy. But it’s what gets you through the weight that would break someone else.