A few years ago, while working on my controls engineering homework, I came across a YouTube channel by a guy named Brian Douglas. Let’s just say this man saved my sanity multiple times while I was trying to understand Bode plots, Kalman filters, and so much more.

He also inspired me to love controls even more and to become more curious about the incredible possibilities within this niche field. More than anything, though, I was fascinated by how he could take a very complex concept and break it down in ways that no one else could.

Fast forward to 2025. For my birthday, a friend of mine emailed Brian and said, “Hey, my friend is a big fan of your work. Would you send her an email for her birthday?”

Brian said, “Well, I’m also in Seattle, so let’s meet up for coffee instead.”

So I met the GOAT on my birthday. I was stoked.

What’s even cooler is that Brian is not only a brilliant engineer, but genuinely one of the most fascinating humans I know. I’m lucky to say that today I can call him a mentor and a friend—someone I’m always learning from and am just so grateful to know.

One of the first questions I ever asked Brian was how he paved his path from working as a full-time engineer in the space industry, to making content on YouTube, to now working at MATLAB while also creating content.

I loved his answer. He said he didn’t necessarily have it all laid out as a path. He lets opportunities come to him and chooses what serves his purpose.

That approach of curiosity and being willing and open to learn, grow, and adapt is the same approach he takes to engineering.

Recently, we sat down to chat about controls and answer some of the most common questions I get from students, and I wanted to record our conversation so I could share it with my controls nerds.

During our conversation, my goal was to really pick his brain and find out what it takes for someone to become a successful controls engineer today—from the skills to learn, to the projects to work on, to how to stand out.

Brian, as usual, blew me away with his answers because they are never the textbook, straightforward “do X to get to Y” answers.

He always leads with curiosity, which is something I have found that all the engineering leaders I’ve met have in common.

Brian explained how he likes to start with an interesting problem—perhaps something that isn’t the regular playbook controls example, like an inverted pendulum project where everything goes perfectly.

Instead, try something like “LQR for Tetris.”

Then figure out what skills you need to learn to make it work. Or at least try, fail miserably, and learn something anyway—which should be the goal, besides having fun, of course.

Students, including myself many times, forget that the whole point is to enjoy the process of learning and discovering new skills and ideas. To truly think outside the box and allow yourself to learn.

Because, yes, we often learn more from trying and failing than we do when everything goes smoothly and the code compiles on the first try.

Sometimes we just want something to put on our resume, so we take the safe path. We don’t reinvent the wheel. We do what has worked for everyone else.

I don’t think there’s anything wrong with starting there, but it shouldn’t be all we do.

When Brian was describing this, all I could think about were the projects from my own resume that I was most excited to talk about. They were always the unexpected, “wacky” problems.

I could go on and on about what I tried, what didn’t work, what I learned, and everything I did confidently. And people always loved hearing about those projects in my interviews.

From taking a gas-powered remote-control plane and turning it electric, crashing it, fixing it, and doing it all over again, to asking my manager for time to work on a side project so I could build a tool that would help my team model solar torques faster.

I loved those projects, and I learned so much from working on them. I developed skills that went far beyond the classroom.

There was no step-by-step guide. No YouTube video to follow. Nothing other than me sitting down and drafting the steps of everything I thought I needed to learn and do to make it work.

Then designing, building, breaking, fixing, and repeating.

Because, like Brian said, “that is what engineering is.”

The moral of the story is this: when you’re asking yourself, “What should I put on my resume? What should my summer project be? What skills should I be learning?” try starting somewhere else.

Find something that genuinely excites you.

Take a concept you learned in class or something you’re curious about and try to apply it to that problem.

Then figure out the steps, tools, and skills you need to make it happen.

Build it. Break it. Fix it. Learn from it. And have fun along the way.

You might end up with a great project for your resume, but more importantly, you’ll have a story about how you think, how you solve problems, how you learn, and maybe crack a few jokes while you’re at it.

And that is what makes you stand out as an engineer.

Check out Brian’s MATLAB Tech Talks here: https://www.mathworks.com/videos/tech-talks.html

Brian’s Youtube Channel: https://www.youtube.com/channel/UCq0imsn84ShAe9PBOFnoIrg

For more resources and project ideas: https://engineersteatime.com/projects/