We spend years teaching engineers how to work with computers. How to debug them, structure them, make them faster, and keep them from doing wildly unexpected things.

Then one day, the job quietly changes.

Suddenly, your biggest dependency is people.

And people have terrible documentation.

There’s no API. The error messages are vague. Production behavior is wildly inconsistent. And somehow, nobody thought this deserved a course.

As engineers become more senior, technical ability is still essential and being right isn’t enough anymore. Your impact increasingly depends on your ability to explain a technical problem to someone who isn’t technical, push back without becoming “the engineer who always says no,” disagree productively, communicate tradeoffs, influence decisions you don’t own, and figure out what someone is actually asking for.

In this session, we’ll explore the human skills that turn technical expertise into influence. We’ll look at how to translate, not dumb down, technical concepts for different audiences, how to challenge an idea while staying part of the solution, why curiosity is an underrated technical skill, and what happens when your impact starts being measured less by what you personally build and more by what you enable.

Because eventually, the hardest systems you’ll work on aren’t written in Python, C#, JavaScript, or PHP.

They’re made of people.