Quick note: I still intend to publish the edition with my thoughts on how AI is reshaping engineering careers, as promised in the last two editions. 🙂 It will go out in the next regularly scheduled edition on Sunday, October 4 at 4 p.m. Pacific.
The two weeks leading up to LDX3 disappeared into final talk preparation, travel, and the conference itself. I came home with plenty to think about, so I’m sending this shorter midweek edition for two reasons.
First, I’d love to invite you to a free interactive workshop on influence I’m hosting as part of the Uncharted Career Series: Build Influence Beyond Technical Expertise, on Thursday, October 1 from 12–1 p.m. Pacific.
Second, my experience speaking at LDX3 gave me a new perspective on influence that I’d like to share with you.
Why a workshop on influence
I learned fairly early in my engineering career that I was not especially influential.
I could have strong technical opinions and good reasons behind them. Sometimes those ideas made their way into the code I wrote or the design documents I authored. But they often did not travel much farther.
Other people did not necessarily buy into those ideas just because I thought the reasoning was sound.
That frustrated me for a long time.
At some point, I came across the idea that facts and evidence alone are usually not enough to change someone’s mind. I remember feeling quite irritated by it.
I valued intellectual honesty and rigor. I believed that if we researched a problem carefully, gathered the relevant evidence, and made a strong argument, reasonable people should be persuaded by the quality of the reasoning.
If that was not enough, what exactly were we supposed to do?
The more important realization came years later.
Even after learning that technical correctness alone was insufficient, I was still trying to solve my influence problem through more technical knowledge and better technical arguments.
I had revised what I knew about influence, but not changed how I approached it.
Influence is a human problem
Looking back, I was treating influence primarily as an intellectual problem: if the reasoning was sound, I assumed people would eventually see what I saw.
But influence is also a deeply human problem.
Once I began taking that seriously, the questions I asked changed.
Before trying to persuade someone, I needed to understand what I was actually trying to influence. What was the current state? What did I want to change? Was I trying to change someone’s understanding of a problem, the priority we gave it, a technical decision, or the action we took next?
I also needed to understand the people involved. What did they already believe? What did they value? What incentives and constraints were shaping their position? What context did they have that I did not? And what kind of relationship existed between us? Or did one need to be built first?
Then there was the ongoing work of advocacy. I had to make my reasoning clear in language that connected with the other person’s context, listen to what came back, incorporate information that changed my own thinking, and continue bridging the distance between our evolving positions.
Over time, these became the three ingredients I believe comprise influence: Clarity of Purpose, Thriving Relationships, and Skillful Advocacy.
None of them replaces technical depth.
But technical depth becomes far more useful when you know what change you are trying to create, understand the humans whose participation that change requires, and can advocate for an idea in a way they can actually engage with.
What changed at the Staff level
As my scope at work grew, this became increasingly important.
By the time I was working as a Staff Engineer, some of my projects spanned all of engineering. I needed context and support from people I had no authority over. I needed other engineers to trust the direction we were shaping, contribute their own perspective, and eventually choose to adopt what we were building.
A technically sound design could not create that participation on its own.
The engineer who once wondered why good ideas were not enough eventually had to work on problems that only succeeded when many other people chose to participate.
That shift took me years to understand.
Today, I see many technically strong engineers get stuck here: when an idea is not gaining traction, they often respond by strengthening the technical argument instead of examining what else may be getting in the way.
That is why I wanted to make the next Uncharted Career Series session an Uncharted Lab focused on influence.
If you have an idea that keeps stalling, a technical concern that is not gaining traction, a difficult stakeholder relationship, or a decision you want to shape, this workshop will give you a practical framework for examining where your influence may be breaking down.
We’ll start with a short lesson on the three ingredients of influence and the technical, organizational, and business contexts in which influence plays out.
Then you’ll apply the framework to a real influence challenge from your own work, followed by group discussion and open Q&A to help refine your thinking and identify one concrete influence move to try next.
Join me Thursday, October 1 at noon Pacific.
What LDX3 taught me about influence
Last week, I spoke at LDX3 in New York on a very different topic: how working with legacy systems can build technical judgment.
I had spent months trying to create an intellectually rigorous talk. I wanted engineers who had inherited old systems, lived through migrations, and watched earlier technical decisions age to see what those experiences could teach them about judgment.
The talk was incredibly well received, despite a conference schedule with plenty competing for people’s attention. I was speaking at the same time as Charity Majors on the other stage, and my office hours later ran at the same time as Jez Humble’s.
But the strongest signal came afterward.
As soon as my office hours started, one person arrived with a question about designing an interview loop that would hold up in the age of AI. Then more people trickled in.
One engineer wanted to brainstorm how to position years of legacy-heavy experience at a major technology company more favorably in interviews.
Another wanted to talk about how the schema ecosystem I had described in the talk had proliferated so much, and how I would solve the problem today.
Someone else wanted to know what eventually happened to the “magic phone” from one of my stories.
The conversation kept going for 45 minutes, until I finally had to excuse myself for a dinner for which I had already missed the provided transportation.
I also received several messages on LinkedIn and Slack from attendees I hadn’t met, telling me how much the talk had resonated with them.
What people were actually taking away
As I reflected on those conversations, I realized that people had received more than an argument about technical judgment.
Many had recognized their own careers in the talk.
Work they may have considered unglamorous, dated, or even career-limiting could now be seen differently.
Living with imperfect systems had exposed them to decisions and consequences. They had learned things about tradeoffs, operational reality, failure, maintenance, and second-order effects that are difficult to learn from greenfield work alone.
In retrospect, I had been so focused on whether the talk would give people a useful intellectual framework that I had underestimated what can happen when an idea helps someone understand their own experience differently.
That brought me back to something I have written about before:
Your influence lives in other people's minds.
We can put a lot of care into an argument, a design document, a technical decision, or a conference talk.
But effective influence needs to take into account what another person understands, trusts, remembers, chooses to reconsider, or does differently.
Learning how to do that well takes a lot of practice.
12 noon–1 pm Pacific Time.