Hey!

Chris here. Welcome to Blueprint—the newsletter to help you build a winning engineering team.

I was standing in front of a firing squad.

Well, not literally. But it was close enough.

I was in a room full of my client's clients. They were taking turns metaphorically punching me in the face for something I didn't do, wasn't responsible for, but represented.

I'd been working my ass off on this project, but the amount of work kept growing. I'd become the bottleneck, and there was no way I could catch up on my own.

That's when it hit me: this wasn't a time problem—it was a training problem.

When you're drowning in work, slowing down to teach feels like an impossible task.

But after 20+ years of building businesses, I've learned the hard way that taking your time is the only real path forward.

Here's why the only way to move faster is to pause long enough to train someone else. 👇️ 

📒 DEEP DIVE

The Paradox of Speed

Why slowing down to train your team is the only way to move faster.

Breaking the Hero Habit

Every founder has the same reflex: "It's faster if I just do it myself."

I was there just last week. A four-alarm fire blaring in Slack on a Sunday. I'm watching and waiting for somebody to jump in...and nobody's jumping in.

In that moment, every instinct in me screams, "Just fix it!"

This hero mentality has always made me feel productive. But it's also kept me stuck.

When you're always the one solving the problem, you become the problem. You're the constraint. If every emergency routes through you, every question waits on you and every decision needs your approval.

The need to be the hero blocks scale. You gain incredible leverage when you're willing to let others struggle through the learning curve.

So instead of putting everything on my back that Sunday, I sat with a project manager—a non-technical person who'd never done any engineering in her life—and trained her from beginning to end.

She solved the problem in five minutes.

The teaching part is easy. It's the stepping back that makes it hard.

Go Slow To Go Fast

The realization that I had become the bottleneck is why I've fully embraced the mindset of "go slow to go fast." It's the paradox that makes you faster in the end.

Now, I spend most of my time going slow by training others.

What's interesting is that I'm training a mix of two completely different audiences: hardcore engineers and non-technical service teams.

Take the project managers I trained a few weeks ago. My job was to help them unlock tools like Claude Code and Codex—tools with "code" literally in the name.

The VP of Services told me up front: "Everyone here is nervous because we don't know what any of these things are."

These tools are life-changing for project managers who constantly wait for engineers to become available to answer questions. It's like having an engineering team at your beck and call, always ready to give a clear answer to any question.

But getting there means going slow—really slow.

Many steps that have become second-nature to me are completely foreign to them and need to be explained in detail.

But in just an hour, we got to the point where they were able to start using the tools. They saw this little glimmer of hope on the other side of it.

This shift changes time ownership. Instead of sprinting to keep up, you're building systems that can run without you.

As you slow down and teach, you eventually create 5 of you where there was once just 1.

Train the Trainer

1-to-1 teaching feels slow. But AI is a powerful multiplier that leads towards efficiency.

In the AI era, when 1 expert can become 20, there's never been a better time to train people.

And when the people I train start training others, they become evangelizers of the technology.

In a larger organization, these evangelizers can launch an incredible cascading effect because expertise compounds as it's shared.

This speed becomes exponential when everyone on the team has expertise, and the knowledge continues to multiply.

Teaching as Reflection

There's another dimension here that matters: training doesn't just benefit the trainee. It's also a great way for leaders to stay sharp.

Teaching forces clarity by revealing the gaps in your own understanding. You can't fake expertise when you're walking someone through their actual problem in real time

That's why in every training session that I do, I ask the trainees the same question: "What's a real problem that, if we solve it in the next hour, you'll be super happy with the result?"

It's a great way to test how well I know my stuff because I need to be technically sound to get through a real problem in an hour.

Whether it's with weekend projects or by regularly coding with the engineering team, the best technical leaders find ways to stay relevant in the details that their teams work on every day.

And for me, that's teaching.

BEFORE YOU GO…

Back to that firing squad moment...

When you're drowning in work, the last thing you want to do is slow down and train somebody else.

But I knew I'd stay underwater if I handled every issue myself.

You have to be willing to trade short-term speed for long-term capability.

You can't scale by running faster. You scale by creating more people who can run.

It's the paradox of speed: you go fastest when you stop doing everything yourself.

So ask yourself: "How can I slow down today?"

Talk soon,

Chris.