What is a Technical Leader? Derrek Cooper's Answer

As a leader, your job isn’t to be the smartest in the room. It’s to help other people speak up, grow, and step forward. That takes vulnerability. It takes security. But it’s the most important part of leadership—making space for someone else to thrive. — Derrek Cooper

When I was just starting out, I had a mentor who stopped me after a long day of obsessing over a broken integration. I had been staying late, trying to stay in control of every piece. He leaned in and said, “If this thing falls apart when you step away, you didn’t build it right.”

It took years for that to really sink in. You don’t build a good system to hold onto it. You build it so someone else can run it, and so you can build something else. No single person can pilot a system 100% of the time, and it’s vital to build systems that work both for you and for your team. 

That memory came rushing back in my conversation with Derrek Cooper, who has spent his life thinking about systems—not just technical ones, but human ones too.

From submarines and CFD to product leadership and coaching, Derrek’s career has followed a quiet but consistent arc: study the system, improve the system, then step out of the way.

Start with the Submarine

Let’s begin in a small metal tube filled with pressure and anxiety.

Derrek’s first real immersion into systems came in the Navy, on a submarine, surrounded by machinery that had to work. He wasn’t particularly mechanically inclined, but he was relentlessly curious—which turns out to be the more important trait when you're under the ocean with limited oxygen and a lot of valves.

“You’re surrounded by systems,” he told me, “and if you don’t understand them, you’re a risk to everyone else. So you learn fast.”

That might sound intense, and it is, but it’s also the perfect training ground for engineering leadership. Because if you can stay calm in a submarine when something hisses, groans, or blinks red, you can probably lead a team through a product launch.

It also taught him one of his most enduring insights: technical systems are only half the story. The other half? The humans who run them.

Finding Meaning in Flow

After the Navy, Derrek studied mechanical engineering and fell in love with computational fluid dynamics—a glorious niche where equations model airflow and heat exchange, and where you can use math to visualize things that are otherwise invisible.

Most people pick up a CFD textbook and quietly set it back down. Derrek stuck with it.

“I loved the idea that you could see how a product behaves before you ever build it,” he said. “It gave me a framework for understanding the world.”

But somewhere between simulation and delivery, Derrek realized something slightly awkward: the most unpredictable variable in any project was not the fluid or the thermal gradient.

It was people.

That discovery turned his attention inward, and sideways. He began managing teams, then teams of teams, and started to spot patterns that couldn’t be solved with an equation. Bottlenecks weren’t always technical. Meetings became the new failure mode. Communication broke before design ever had a chance.

So he started to pay attention. And listen. And ask questions. Eventually, he shifted his focus to coaching.

The Systems You Can’t Diagram

“People talk about ‘soft skills’ in engineering,” he said. “I don’t think they’re soft. I think they’re just hard to teach.”

At Autodesk, Derrek watched smart teams get stuck because they lacked clarity. Communication faltered. Conflicts simmered. Burnout crept in, silently.

“Engineers know how to debug a machine. But debugging a team? That’s a different skill set.”

He started asking different questions in one-on-ones. Less about deliverables, more about energy. What drained them? What helped them feel seen? What kind of leader were they trying to become?

What he found was consistent. Most people weren’t looking for praise. They were looking for permission to be honest, to slow down, and to admit when they were overwhelmed.

That shift to begin asking better questions, and making space eventually became the heart of his work.

Case Study: Leading by Stepping Out

At one point, Derrek was leading a cross-functional team that had grown too dependent on him. Decisions funneled through his desk. People waited for him in meetings.

“I thought I was delegating, but I wasn’t. I was still the final step for everything.”

So he did something simple and hard. He stopped answering every question. He paused more. He asked the team what they thought before offering his view.

At first, people were confused. Then they stepped up.

“It wasn’t instant. But the more I stayed quiet, the more they started leading. They had the knowledge all along. They just needed room to own it.”

That experience shaped his view of leadership. You don’t have to know everything. You just have to create the conditions for others to thrive.

Burnout by Design

When I asked Derrek about burnout, he was clear: it doesn’t always look like a breakdown. Sometimes it looks like over-functioning.

“I was in every meeting. Answering every email. Saying yes to everything. I told myself I was essential, but really, I was afraid of slowing down.”

Eventually, he hit a point where work was consuming almost all of his attention. Family, health, creativity—everything else was shrinking.

That awareness didn’t come from a breakdown. It came from reflection.

“I started journaling. Not long entries. Just jotting down what felt good, what didn’t, where I felt stuck. That gave me insight I couldn’t get from just grinding forward.”

This was a turning point. He enrolled in a master’s program in positive psychology at the University of Pennsylvania. Studied resilience, optimism, identity. Applied it to himself first, then to his team.

Now, as a coach, he helps others do the same.

A Mentor Who Let Me Lead

During our conversation, I found myself thinking about a project I was given early in my career. The architecture wasn’t finished, the documentation was thin, and the scope was changing by the hour. I kept checking in with my lead, waiting for approval. Eventually, he turned to me and said, “You’ve got this. Stop asking. Start owning.”

That shift gave me confidence I didn’t know I had.

Derrek talked about that same pattern in his own teams. “Leadership isn’t holding on to control. It’s knowing when to get out of the way. If you’ve done your job well, they won’t need you in every decision.”

It’s subtle and permissive leadership which makes all the difference to the burgeoning engineer. Who were you when you found the mentor who gave you the right permission to pursue your own ideas, your own work ethic?

Making Time for Thinking

Derrek and I spoke at length about time—how to spend it, how to reclaim it, how to stop it from getting eaten by urgency.

“I used to fill every hour,” he said. “Then I realized my best work came from the hours I protected.”

He now blocks time each week with no agenda. Time to think, write, reflect. Not for deliverables—just for clarity.

“You can’t lead clearly if you’re always reacting. You need space to observe your own mind.”

This wasn’t a productivity hack. It was a survival tactic. A way to stay grounded in a role that often pulls you in too many directions.

People Are Systems Too

One of Derrek’s most quietly radical beliefs is that humans are not exceptions to engineering. We are systems—complex, recursive, unpredictable, sure—but systems all the same.

This reframing changes everything.

If a teammate is struggling, you don’t just “motivate” them with a pep talk. You ask what inputs they’re getting. What feedback loops are in place. What constraints they’re operating under. You debug with compassion.

“If you see someone shutting down in meetings, it might be that they don’t feel safe,” Derrek said. “Or that they don’t know how to speak the language being used. That’s a system problem.”

Once you see humans as systems, you stop blaming them for failing to act like machines. You start wondering where the signal got lost.

And that, more than any product launch or dashboard, is what real leadership looks like.

Takeaways: Lessons for Builders and Leaders

If you're an engineer, manager, or team lead looking to grow—not just in scope, but in clarity—here are a few lessons drawn from Derrek’s story:

1. You don’t need to be the smartest in the room

Your job is to make the room smarter. That starts with asking better questions and listening longer.

2. If the team can’t run without you, the system isn’t done

Real leadership creates sustainability. Teach, delegate, then step back.

3. You are not your inbox

Time is the only asset you can’t get back. Block space for thinking. Protect it like a critical dependency.

4. Writing is thinking

Journal, brain dump, reflect. If you’re stuck, start writing. You’ll find the signal underneath the noise.

5. Burnout doesn’t always announce itself

Check in with yourself before the system crashes. Slow is not broken.

Closing Thought

Derrek Cooper didn’t follow a linear path. He followed curiosity. And what he discovered is something most of us take too long to learn. That building systems—whether in code, airflow, or people—requires both clarity and space.

If you want to lead better, stop trying to hold everything. Teach. Trust. Step out of the room.

That might be the most human thing an engineer can do.

It’s a rare gift to meet someone who’s both completely in command of complex systems and remarkably chill about the fact that nothing is ever really under control.

Derrek Cooper has that gift.

He’s spent the better part of 25 years navigating the quietly chaotic ecosystem of engineering, from CFD and submarine mechanics to leadership in product and strategy at Autodesk. But these days, he talks more about listening than optimizing, and more about awareness than throughput.

And here’s the kicker: it actually works.

He’s built software, managed teams, and now coaches technical professionals on how to lead better without losing their minds—or their calendars. Along the way, he’s discovered something I wish I’d known years ago: you don’t have to do it all yourself. In fact, you’re not supposed to.

Hardware Rich Development is a series from Quilter.ai that explores what it means to build high-integrity hardware in a fast-moving world. If you’re leading an engineering team or driving technical decisions in your organization, and you’d like to share your insights, reach out.

We’re building a community around better hardware thinking.