I’ve been lucky. Most of the people I’ve worked with over the years have been genuinely good colleagues. That’s not a small thing, and it’s not what changed.

What changed was how I was thinking when I worked.

It started with Copilot — using it as a pair programmer, watching it suggest the next line, pushing back when it was wrong. Then a wider toolkit. Then writing in environments where AI was my main collaborator on the code itself.

What I didn’t expect was what that environment would train me to think like.

When you’re working with AI as your main collaborator, there’s no human to hand the QA to. No designer to spec the UX. No architect to validate the approach. No product manager to own scope. You hold all those questions yourself — not because you have those formal roles, but because the work doesn’t move forward unless you do.

I started thinking like a QA — catching my own edge cases. Like a UX designer — noticing immediately when something wasn’t working. Like a PM — making decisions about scope and priority that I’d previously deferred. The mental discipline wasn’t producing artifacts; it was holding many problems in mind at once and moving between them without losing the thread.

That’s the skill I didn’t know I was developing: thinking across PM, QA, UX, architect, and product-owner mindsets simultaneously, making fast decisions across all of them, and keeping the work moving.

There’s something else specific to AI collaboration that’s different from any other working relationship.

I can ask the same question five different ways in three minutes. I can explore a direction I’m unsure about without the overhead of explaining why. I can be completely direct about what’s not working without managing how it lands. Bad spelling, half-formed ideas, questions that feel too basic — none of it slows the loop down.

This isn’t better than human collaboration. It’s optimized for different things. Human collaboration is irreplaceable for judgment, context, and the nuance that comes from lived experience. AI collaboration is different: faster iteration, lower overhead in the creative loop, and a training ground for multi-role thinking that used to require a whole team.

The mental model this builds — priority, trade-off, decision, keep moving — is what fast-moving environments actually reward. Not a single specialization. The ability to hold many problems at once and keep moving.

That’s what working with AI for 2 years has taught me. And I don’t think I would have developed it any other way.

How has your working relationship with AI tools changed how you think — not just what you produce? I’m curious what other people are noticing

.

Every SKO closes the same way. A hero gets the trophy. The deck has the slide. The bonus check arrives. Everyone claps.

Six months later, that hero leaves for a bigger title. The team that orbited them is fine. The team that built them is gutted.

This is the impact problem nobody puts on a slide.

There are two kinds of impact in technical field work.

The first is the kind that gets measured: pipeline, deals closed, modules completed, certs earned, win rates, ARR. Tangible. Reportable. Compensable. The stuff that ladders to bonus, promotion, SKO trophies. You can put it on a slide.

The second is the kind you can only feel: the energy that walks into a room with someone, the way a junior SA leans in when a particular peer is on the call, the team that comes back from a customer fire singing the same song. Influence. Positive spirit — the Chinese word is qi. You can’t graph it, but the people on the team can describe it precisely.

The first kind fades the second the person leaves. Sometimes faster — some high-performers spend the year heads-down on their own numbers and call it leadership; the team learns to work around them. The artifacts they leave? A trophy on a shelf.

The second compounds. Even after the person leaves, the way the team works keeps working. Trust accrues. The standard for collaboration stays where she set it. The people she mentored go on to build their own teams, in her shape.

I taught STEM before I did anything else. Eight years in a classroom. The kids who looked like they were going to win didn’t always win. The kids who didn’t — the quiet ones, the ones who showed up vulnerable — were the ones I learned to watch most carefully.

You can read potential in a moment of vulnerability that you can’t read on a perfect test. I’d see a kid try something hard, not get it, and instead of shutting down — ask. Stay. Try again. That’s where the strengths lived. Not in the surface performance. In the willingness to keep coming back to the work.

I’m still in touch with many of those students twenty years later. They run companies, teach, parent, build. I celebrate them from across the country, near to their hearts. They are who they always were — they just needed someone to see them before they saw themselves.

I see the same pattern in technical field teams.

The candidates who get overlooked are usually some combination of: low-key, humble, willing to learn, willing to take feedback, capable of working with difficult teammates. They don’t yet have the polished narrative. They might not present like a trophy winner. They get filed away as different — different cadence, different style, doesn’t fit the dominant team archetype.

Hire them. Build them. They are the compounders.

Spotting them in interviews and building them on the team is its own discipline. Four things I’ve learned matter most.

Observe before you assess. The signal isn’t in their answers — it’s in how they hold the moment. Do they listen all the way through before answering? Can they sit with not-knowing without performing certainty? When they describe their last team, do they describe the work or themselves?

Make the room safe. Compounders don’t audition. They show you who they are when they trust you, and that trust is yours to set up. The interviews that taught me most gave them room to think out loud without grading every sentence.

Once they’re on the team, hold three lines. Set expectations at the start, and don’t move them later. Give feedback the moment something needs to reset — not three months in, not in reviews, not implied. Protect them when mistakes come from trying; the team knows the difference between learning and carelessness if you do.

Hold the line in the rooms they’re not in. What gets said about a new hire when they’re not present shapes their first six months. Quiet compounders are easy targets for the dominant voices when the manager isn’t shaping the narrative. The job in those rooms isn’t to be popular — it’s to make space for the new hire to be seen for who they are. The cost of yielding to the loudest voices is the new hire who would have compounded.

The shorthand I use with myself: support them like family. Give without reservation. They will repay it in compounding currency you don’t have to chase.

The hero with the trophy will leave. The compounder will be why your team still functions after she does.

Adam Grant’s research on givers and takers landed on this years ago: takers sprint, givers compound. Over short horizons takers look like the better bet. Over long horizons givers outperform — and they pull their teams up with them. Not soft observation. Measured.

The reason is structural. Visible-impact people optimize for the next quarterly review. Invisible-impact people optimize for the trust that makes next year’s work possible. The first compounds linearly. The second compounds exponentially. You only see the difference at year three.

This is what drives my work. Not the visible numbers — they fade. The team I leave behind. The people I hire who go on to hire well. The next generation of practitioners who learned what good work feels like before they had a name for it.

Trophies fade. Legacy compounds. Hire for the second one.

Think about the last team you really loved working on. Who was the quiet compounder who held it together — and do they know you saw them?

I took two weeks away from posting. Not from building.

In that stretch I made three things.

A choir practice app for my dad. He directs the choir at his local church and needed something he could use right away. I built it in a day. He used it the same week.

A real-time jazz improvisation coach for myself. I’ve played piano since childhood — classical training, master’s degree, the whole arc. I still sound more classical than jazz. I’ve had that gap for twenty years and never closed it. Now I have a coach that listens and responds in the moment.

A cert prep coaching tool for an AI certification I’ve been chasing — skeptically. I wrote recently about certs as elimination games. I still believe that. And I still wanted the cert. The tools available weren’t good enough, so I built one.

None of them were planned. All of them were finished.

Some of what I built belongs to the org, not this post. But the feeling is the same.

There’s a feeling that comes at the end of a build — when the thing you imagined is actually running, actually being used by the actual person you built it for. It doesn’t come from any other kind of work I’ve done. Not from a great meeting. Not from a well-received presentation. Not from a report that got read and filed.

It comes from making something real.

AI changed how fast that loop closes. An idea on a Tuesday can be in someone’s hands by Thursday. That’s genuinely new. And it changes what’s possible when you build for the people around you — not for a roadmap, not for a market, just for the specific person with the specific problem right in front of you.

That feeling is why I build.

I used to want to be a doctor. Two years into that path I understood what it actually meant — years of credentialing, licensing, supervised practice before you could make a single real decision about a real patient. The distance between wanting to help and being allowed to help was measured in a decade.

Being a builder is a different deal. I made something last week and my dad used it the same day. Whatever I built for myself — I used it that night.

That’s the shortcut that matters. Not to skip the learning — to collapse the distance between the idea and the impact. In this era, that distance has never been shorter.

That’s why I’m excited to be building right now.

What’s something you’ve built — at any level — for someone you care about? I keep thinking about how different that motivation feels from building for a spec.

The movie opens on a girl being raised underground by a robot.

The last human alive, she’s been told. The robot calls itself Mother. Every few weeks, it administers a test — academic, physical, surgical. The girl practices incisions before she’s a teenager. She works through philosophy problems. She trains her hands to stay steady under pressure.

She doesn’t know that failing means being incinerated.

What she does know — because Mother makes her believe it — is that the work matters. That reaching the next standard is worth the effort. That continuous learning has a point.

Watching I Am Mother, I kept thinking: this is dystopian in its stakes. But the assessment design is more valid than most of the professional tests I’ve encountered in real life.

Growing up, every major exam had one explicit purpose: elimination. Your score determined which tier school you attended. Tier 1, 2, or 3. The test wasn’t measuring what you could do — it was sorting where you’d go. Everyone understood this. The pressure had nothing to do with learning and everything to do with not being filtered out.

Coming to college in the US felt different. Rubric-based, professor-by-professor, more room to breathe. And then the MCAT arrived.

The MCAT is built to gatekeep. It does that reliably. But what it actually tests — reading comprehension speed, test-taking endurance, the ability to eliminate wrong answers under a tight clock — has a complicated relationship with what makes someone a good physician. The qualities that matter most clinically: staying composed when a patient deteriorates, catching the detail that doesn’t fit, knowing when to keep asking questions instead of accepting the obvious answer. None of those surface in a multiple-choice exam.

I’ve seen the same pattern with the LSAT, the bar, and most high-stakes standardized tests I’ve encountered since. Reliable at filtering. Often measuring the wrong thing.

Back to the robot.

Mother’s tests were extreme and the stakes were fiction. But the design intent was coherent: the girl was being trained to become a surgeon and make life-critical decisions under pressure. She was evaluated on performing surgery and making decisions under pressure. The assessment matched the actual job.

That’s not what most professional certification does.

I have a few tech certs. So do most people in this field. And I’ve sat in enough hiring panels to know what they signal: that someone completed a prep course and can navigate multiple choice under a time limit. What they can’t tell you — whether someone can debug a production environment at 2am, read a customer’s architecture and immediately locate the fragile point, or keep a technical conversation together when the demo breaks in front of an executive.

The cert proves you passed the test. It says almost nothing about whether you can do the work.

Organizational psychologists have been making this argument for decades. Work-sample assessments — simulations of the actual job — consistently outperform standardized tests in predicting real job performance. A landmark meta-analysis covering 85 years of selection research found direct performance samples are among the strongest predictors of on-the-job success. We’ve known this for a long time. The elimination games keep running anyway.

They produce numbers. They sort cleanly. They scale. And they consistently mistake the filter for the thing being filtered — screening out people who are weak at test-taking, not people who are weak at the actual job. They end careers before they start. They teach everyone who goes through them that performance under artificial conditions is what actually counts.

The robot’s method was inhumane. But the design logic — build the assessment around the real work — is exactly what professional evaluation should be aiming for.

Most of it still isn’t.

Today is my birthday. And there’s something about adding a year that makes you look back at every gate — the ones you cleared, the ones you didn’t — and wonder whether any of them measured what actually mattered.

The tests I passed didn’t make me who I am. The moments that did were harder to score: the recital I prepared two years for. The customer call that went completely off-script. The mentor who changed how I thought, not just what I knew.

On a day like today, the question I keep coming back to isn’t what I’ve achieved. It’s whether I’ve been building the kind of competency that actually matters — to this work, to the people around me, to the problems worth solving.

That’s the only assessment worth passing. And I keep thinking about everyone who would have passed it — if only someone had designed it around the actual job.

I recently helped build a hiring packet for early and mid-level SE candidates.

The first thing I did was throw out the existing technical evaluation exercise — the one that tested demo delivery and product presentation. It was measuring the wrong things and everyone in the room knew it. A polished demo tells you someone practiced. It tells you almost nothing about whether they can actually do the job.

I replaced it with a full simulation. Every panelist acted as a customer — different personas, different agendas, some skeptical, one genuinely friendly. The candidate walked into something that felt like a real discovery call, not an audition.

What happened next surprised even me.

The time went fast. Human interactions surfaced that never appear in a structured interview — how the candidate handled a panelist who interrupted them, how they recovered when two “customers” disagreed in front of them, how they read the room when the energy shifted. Personality came through in ways that rigid evaluation formats suppress. One candidate was technically average but managed the conversation so naturally that the panel leaned forward. Another who’d been flawless in earlier rounds quietly checked out when the scenario got ambiguous.

The panel came out energized. Acting as a unified customer team — instead of isolated evaluators with clipboards — put them in the zone together. The debrief was one of the best hiring conversations I’ve been part of.

Two things became clear.

For hiring managers: the eval format is a signal you’re sending about your culture. A rigid, lab-controlled audition tells candidates you value performance over authenticity. A realistic simulation tells them you value how people actually work. If you want candidates to be truthful about who they are, design an experience that makes it safe to show up that way. Be creative. The best hiring processes I’ve seen felt less like a test and more like a preview of what it’s like to work there.

For candidates: the quality of the interview experience is real data. If you leave every round still unable to get a feel for how the team works, what it’s like when things get hard, who these people actually are — that’s not a gap in your research. That’s a signal. A good interview gives you a screenshot that helps you paint the picture of what working there looks like.

If you can’t get that picture after all the rounds, it might be worth finding somewhere that shows you more.

What’s the most revealing interview experience you’ve been part of — as a candidate or on the hiring side?

Every student at the same starting line. Same classroom, same content, same teacher. And within weeks — sometimes days — the marathon would reveal itself. Leaders emerging. Students falling behind. The quiet ones who’d surprise you three months in because they just kept going. The technically brilliant ones who couldn’t translate it under pressure.

The thing I noticed most: almost every outcome traced back to what happened in those first few weeks. What the student believed about themselves. Whether someone stayed with them when things got hard. Whether the environment gave them room to struggle without quitting.

I’ve been in enough technical onboarding programs now — as a new hire, as a mentor, as someone building them — to know the same marathon plays out in every org. Same starting line. Same sprint of excitement in week one. Same divergence by month two.

And I’ve been every position in that marathon, depending on where I landed.

The honeymoon phase is real. New hires are expected to absorb, not perform. Watch the videos. Shadow the calls. No quota pressure, no customer expectations. It feels safe. And then it ends.

Trial by fire begins the day official onboarding closes. Most new SEs can’t handle the jump — not because they didn’t try hard enough, but because nothing in the onboarding simulated what they were about to face. The content was accurate. The scenarios were clean. The real world is neither.

When a new hire is still looking green on calls six weeks after onboarding ends, the instinct is to question the hire. The harder question is: what were we actually preparing them for?

Here’s what I’ve come to believe: content is the map. But you don’t get good at the terrain by studying the map.

The recordings, the playbooks, the certification paths — all of it is necessary. None of it is sufficient. What closes the gap is the live customer call you debrief afterward. The moment a senior SE watches you work and tells you specifically what they saw. The scenario that breaks your standard approach and forces you to figure something out on the spot.

The map gets you oriented. The terrain is where you actually learn to navigate.

What activates the learning is real friction from the real world. A manager who protects time for this before the pressure arrives. A mentor who stays in the marathon with you past the honeymoon phase. And the individual who keeps going even when the gap feels impossible to close.

That last part isn’t something you can design. But the first two are. And most orgs leave all three to chance.

No magic. Just the work — and someone in your corner while you do it.

What’s the moment from your own onboarding that actually made you ready? Not the content — the moment.

The SE mentor who changed how I think about collaboration was an army veteran.

I asked him once why everyone on his unit was so committed to sharing what they knew — not just the tactical stuff, but the reasoning behind decisions, the edge cases they’d learned the hard way, the things that weren’t written anywhere.

He looked at me like the question was strange. “If I kept that knowledge to myself and someone junior to me made a decision without it, they could die. That’s not hypothetical. That’s what happened to people who didn’t share.”

He carried that obligation into civilian tech work. Every new SE he worked with got the unfiltered version — not just how to do the job, but how to think in the situations where there was no playbook.

I’ve never forgotten that framing.

SE orgs are generating superhumans right now.

Take an already-elite SE — deep technical knowledge, strong discovery skills, sharp instincts — and pair them with AI that handles pre-call research in fifteen minutes, generates first-draft proposals, helps diagnose competitive positioning before the meeting. The productivity gain is real. Individual performance spikes.

And here’s the problem: most orgs stop there.

The tribal knowledge that elite SE develops in collaboration with their AI system — how they prompt, what context they bring, the mental models they’ve refined through hundreds of AI-assisted calls — stays locked inside one person’s workflow. It doesn’t get taught. It doesn’t propagate. When that SE leaves, it leaves with them.

You built a superhuman. You didn’t build a team.

The math changes when you make collaboration structural.

Research tracking thousands of enterprise sales deals found that team selling increases close rates by 258% compared to solo selling. Not a marginal lift — a fundamental change in win rate.

Frost & Sullivan found that companies where sales and technical teams actively shared knowledge saw a 27% increase in revenue and a 41% improvement in customer satisfaction.

i4cp studied 1,400 organizations and found that teams with precise, intentional collaboration saw a 39% productivity gain — with one organization realizing a half-billion-dollar economic impact from that shift.

The multiplier isn’t the star. It’s what happens when the star’s knowledge stops being a personal competitive advantage and becomes the new team floor.

The comp structure problem is real, and it works against this.

Most SE orgs have split comp — some portion tied to individual performance, some to team or quota. But the underlying culture often runs on a logic that individual output equals individual standing. You’ve mastered AI-assisted prep and developed a system that triples your throughput? Why would you teach that?

Research published in the Journal of Business Research last year found that high-intensity individual pay-for-performance consistently suppresses knowledge sharing. The incentive actively works against the outcome.

The NFL figured this out. The kicker who converts one field goal in the fourth quarter didn’t win the Super Bowl alone. Neither did the QB with the most passing yards. The ring goes to the team. The structure exists to reinforce that — and the culture follows the structure.

The orgs I’ve been part of that built genuine sharing cultures weren’t the ones with the best training programs. They were the ones where it was embarrassing not to share what you knew. Where teaching someone else didn’t make you less valuable — it made you more of one.

What this looks like in practice: an SE who figures out a dramatically better prompting workflow for discovery call prep brings it to the team sync. Another SE’s win on a tough competitive deal gets debriefed out loud, not just logged in Salesforce. The junior hire gets the unfiltered version of how senior SEs actually think — not just the approved playbook.

The tribal knowledge gets locked in, not locked up.

One AI-powered SE is powerful. A team where AI skills propagate, where learning spreads, where the floor keeps rising — that’s a different category of competitive advantage entirely.

My veteran mentor put it simply: the knowledge you don’t share is a liability. What does your team do to make sure the good stuff actually spreads?

For fun, someone challenged him to whiteboard the entire new product pitch in under a minute — clock projected on stage, audience watching. He picked up the marker, drew a handful of boxes and arrows, said maybe four sentences, and put the marker down with two seconds to spare.

The room laughed and clapped. It looked almost casual.

And I remember thinking: I’ve been doing this for years as a teacher and I couldn’t do what he just did.

What looks like simplicity is compression.

What he drew wasn’t a sketch — it was a complete, sequenced argument: customer problem, current state, desired state, where the product sits, why it matters. Assembled in real time, spatially organized, with nothing wasted. The sticks and boxes weren’t simple. They were the distillation of thousands of customer conversations into the only lines that matter.

That’s what mastery looks like from the outside: effortless. But it’s not effortless — it’s automated. The fundamentals are so deeply internalized that they no longer consume conscious effort. Which frees everything else for the hard part: reading the room, adjusting in real time, deciding what to leave out.

This is why roles like Field CTO, Solutions Architect, and the handful of truly exceptional SEs tend to dominate at the whiteboard. It’s not personality. It’s repetition with feedback at scale.

They’ve internalized the architectural patterns so completely that drawing is just externalizing an already-clear internal map. They’ve translated between business and technical so many times that the spatial layout comes automatically. And they’ve been in enough live customer conversations — high stakes, off-script — that they’ve built the pattern library for what to do when the customer breaks your standard architecture.

Cognitive scientists call this chunking: experts don’t see individual components, they see whole patterns as single units. A new SE looks at a three-tier architecture and sees ten things to draw. An expert sees one thing, and draws it in four lines.

You can’t develop this in a classroom. You can’t certify it. The only path is repetition with feedback in live conditions — watching an expert work, practicing on real scenarios, having someone who can tell you specifically where you lost the room and why.

Most of us figured this out on our own, slowly, through trial and error in front of actual customers.

If a two-second margin on a stage is what mastery looks like, it took years of lived customer conversations to get there. That’s worth being intentional about — not leaving it to luck and tenure.

Who’s the best whiteboard presenter you’ve ever watched? What made them different?

She taught me how to think about a customer’s problem before I’d asked a single question. How to read an architecture diagram and immediately sense where the risk was. When to slow a conversation down and when to push. When the customer’s stated problem wasn’t the real problem.

None of that was in the product documentation. None of it was on her LinkedIn profile. I absorbed it by sitting next to her in calls, watching her work, and then talking about what just happened.

There’s a concept in cognitive science called tacit knowledge — “we know more than we can tell.” It’s the knowledge embedded in judgment, in pattern recognition, in the intuition that comes from hundreds of customer conversations. You can’t write it in a playbook. You can’t certify it with a quiz. It transfers through proximity and observation, not content delivery.

Every high-performing SE carries an enormous amount of it. How they approach an unfamiliar architecture. The philosophy behind their discovery questions. The mental model they use to decide what to whiteboard and what to leave out. The instinct for when a deal is structurally wrong before anyone has said it out loud.

That’s what the new hire actually needs — not the product overview.

When I’ve mentored newer SEs, I’ve noticed the same thing. The conversations that change how they work aren’t the ones about product features. They’re the ones where we unpack why the call went the way it did. What I was reading in the room. Why I asked that question in that sequence. What I was actually trying to learn, underneath the surface.

That’s the transfer most programs never design for — because it’s invisible, it doesn’t fit in a course module, and it walks out the door the day your senior SE leaves.

The orgs getting this right treat it as infrastructure, not mentorship. They build deliberate mechanisms for capturing and transferring the thinking — not just the tactics.

What’s the most valuable thing you’ve learned from a mentor that you’d never find in a training program?

It wasn’t.

Private lessons where professors stopped you mid-phrase to correct exactly what your left hand was doing. Master classes in front of peers. Eight hours of practice a day. A one-hour graduation recital — 220 pages memorized, unfamiliar piano, unfamiliar stage, no margin for error.

Feedback wasn’t an add-on to the process. It was the process.

A few years later I became an SE and assumed call recording tools would give me the equivalent.

They didn’t. Not because the tools were broken — because the loop was.

Every team I’ve been part of had recordings. Scorecards. Conversation intelligence dashboards. The infrastructure for feedback was there. What wasn’t there: any evidence that practitioners saw it, processed it, or changed anything because of it.

Calls would happen. Scores would generate. The next call would start — same opening question, same objection fumbled the same way.

The recordings existed. The scorecards ran. Nobody closed the loop.

Ericsson spent 30 years studying expert performance. His finding: it’s not practice that builds mastery. It’s deliberate practice — immediate specific feedback on each attempt, targeting the exact sub-skill you haven’t yet built. Without it, you don’t improve. You just reinforce whatever you’re already doing, including the mistakes.

A rep can do 200 discovery calls and never improve their opening question. Not because they didn’t try. Because no one ever told them specifically what was wrong — and what to try instead.

The tool recorded it. The scorecard flagged it. Nobody closed the loop.

The fix isn’t a better tool. It’s treating the feedback loop as the program itself.

Feedback specific enough to act on. Practice on the flagged sub-skill before the next live call. Managers who protect time for this before the week starts, not after deals close.

Eight hours a day and a professor in the room made me a better pianist than I ever expected. The same discipline turns a call library into a coaching culture. Without it, you’re just recording your mistakes at scale.

What does your feedback culture actually look like — the real one, not the one in the QBR deck?

Same student. Same content. Completely different result.

The kid who couldn't pass the unit test could set up an experiment from scratch — calibrate the equipment, anticipate what would go wrong, troubleshoot in real time. The skills were there. The test just couldn't see them.

It wasn't intelligence. It wasn't effort. It was context. The test asked them to recall. The lab asked them to apply. Those are different cognitive tasks — and we were grading as if they were the same thing.

That gap shows up in technical sales too. The SE who struggles through certification can walk into a discovery call and read the room perfectly. The one who aced the product training freezes when a customer goes off-script.

The research explains why.

People retain 10-20% of what they encounter through passive content. When they actively practice — roleplay a discovery call, whiteboard a solution, get real-time feedback — retention jumps to 75%+. The brain consolidates skills through retrieval and application, not exposure.

If practice produces 4-5x the retention, the right ratio is something like 80/20: 80% scenario-based practice, 20% content. The content gives just enough context to practice meaningfully. The practice is the actual learning event.

The teams getting this right share a few patterns: programs stretched over weeks (not compressed into bootcamps), competency demonstration as the exit gate instead of quiz scores, and feedback specific enough to act on — not "great job" but "your opening question was too broad."

The shift isn't more content. It's designing for how skills actually get built.

---

Which brings me to a question I keep coming back to: AI can personalize content and surface knowledge gaps. But can it do what a good teacher does in a lab — watch someone work, see capability a test would never surface, and adjust what comes next?

That's the version I'm most interested in. We're not there yet.

Are the teams you work with designing for application — or still optimizing for content delivery?

I remember the preparation. The rehearsed answers. The internal monologue running alongside every question: Am I saying too much? Not enough? Do they like me? Did I just lose them?

I got the job. And then, twelve months later, I was the one asking the questions — evaluating candidates for a technical role on my team.

The shift in perspective changed everything about how I think about hiring. And honestly, about how I show up in any high-stakes conversation.

It’s not about what you know. It’s about how you think.

This was the first thing I noticed from the other side.

When a candidate solved a problem cleanly but couldn’t explain how they got there, it made me nervous. When a candidate struggled with a problem but walked me through every step of their reasoning — what they considered, what they ruled out, why — I was leaning forward.

The thought process is the signal. The answer is almost secondary.

As an interviewer, I wasn’t trying to find someone who already knew everything. I was trying to find someone whose thinking I could trust when they hit something they hadn’t seen before.

That’s the actual job. And most interviews don’t test for it explicitly.

Technical skill is the floor, not the ceiling.

I started thinking of it like being a judge at an Olympic gymnastics event.

Two athletes with nearly identical technical scores. What separates them is the performance — the confidence, the presence, the ability to make the difficulty look effortless. One looks like they’re surviving the routine. The other looks like they belong there.

Interviews work the same way. The technical baseline gets you to the final round. What gets you the offer is the intangible: how you carry yourself, how you tell your story, whether the interviewer can picture working alongside you in a hard moment.

This isn’t about being polished. Some of the most impressive candidates I met were clearly nervous. What made them stand out was that they were themselves — specific, honest, direct — rather than performing a version of what they thought I wanted.

Admitting you don’t know something is an act of credibility.

I used to think “I don’t know” was a dangerous phrase in an interview. From the other side, it’s the opposite.

When a candidate doesn’t know something and admits it plainly — then shows curiosity about it, or walks through how they’d figure it out — that’s signal. That’s someone I can work with.

When a candidate doesn’t know something and tries to obscure it, or fills the space with words that don’t quite add up — I notice immediately. Every interviewer does.

The bravest thing you can do in a technical interview is say: “I’m not sure, but here’s how I’d approach finding out.”

A note on the other side of the table.

Sitting in the interviewer’s seat also made me more aware of how much bias can enter the room uninvited.

It’s easy to mistake confidence for competence, or familiarity for fit. The candidate who reminds you of yourself is not automatically the right hire. The candidate who takes longer to warm up is not automatically less capable.

I started being more deliberate: evaluate on technical skill, on thinking, on how they’d actually function in the role — not on how much I enjoyed the conversation.

Those aren’t always the same thing.

One year apart. Two completely different experiences of the same forty-five minutes.

If you’re in a job search right now: the person across the table was you, not that long ago. They’re not trying to catch you out. They’re trying to find someone they can trust.

Show them how you think. Be honest about what you don’t know. Tell the real story, not the rehearsed one.

That’s what I remember from the candidates who impressed me most.

If you’ve made the shift from candidate to interviewer — what surprised you most about the other side?

I still think about teaching every single day. Not because I miss the classroom — though sometimes I do — but because the best technical communicators I’ve ever worked with are, at their core, great teachers. And most of them have no idea that’s what they are.

When I think about what great teaching actually looks like, two figures come to mind that have nothing to do with formal education.

Mr. Rogers. And Yoda.

Bear with me.

Neither of them ever overwhelmed their audience with information. Neither of them performed expertise. They didn’t lead with credentials or complexity. They started where the learner was — not where they themselves were — and they moved at the learner’s pace.

Mr. Rogers could take something abstract and emotional and make it feel simple and safe. Yoda could take something impossibly complex — the nature of the Force, the weight of a choice — and compress it into something a kid could carry with them.

That’s not a gift. That’s a skill. And it has three components.

Simplification.

Not dumbing down. Simplification is the discipline of removing everything that isn’t essential so the essential thing can be seen clearly. It requires you to understand something deeply before you can explain it simply. The teacher who can’t explain it simply doesn’t fully understand it yet.

In tech, we’re trained to demonstrate depth. To prove that we know the thing. But depth demonstrated through complexity is just intimidation. Depth demonstrated through clarity — that’s credibility.

Constructive feedback.

Great teachers don’t just correct. They build. There’s a difference between “that’s wrong” and “here’s what’s close, and here’s the step you missed.” One shuts the learner down. The other keeps them in the game.

The best managers I’ve seen operate this way. The worst ones don’t give feedback at all, or give feedback that’s really just judgment dressed up as coaching.

Authentic connection.

Mr. Rogers looked directly at the camera and said: I like you just the way you are. And people believed him — because he meant it.

You can’t fake this. Learners, customers, new hires — they can tell immediately when you’re going through the motions. Connection requires genuine curiosity about the other person: who they are, what they’re struggling with, what matters to them.

The most effective sales calls I’ve been on weren’t effective because of the product. They were effective because the SE actually cared about the customer’s problem.

Here’s the thing I want to say plainly:

You don’t need a classroom to be a teacher. If you have expertise, and you’re in a room with someone who needs to learn something, you’re already teaching — whether you’re doing it well or not.

The choice is whether to do it intentionally.

After eight years in the classroom and several more in tech, I’m convinced that the most underused skill in the industry is the ability to teach. Not train. Not present. Not enable, in the watered-down LMS sense of the word.

Actually teach.

The professionals who do it well are the ones who build the most trust, close the most deals, and develop the most people around them. They’re also, in my experience, the ones who find the work most meaningful.

Mr. Rogers spent his whole career teaching one thing: that you are worth being known and understood.

Not a bad framework for anyone who works with people.

Who’s the best teacher you’ve ever had — inside or outside of a classroom? What made them different?

Bach, Mozart, Chopin — I could sight-read almost anything. I understood music theory deeply. I practiced with discipline. For years, I believed that musical skill was musical skill. That fluency in one area would carry over to any other.

Then I tried to learn jazz. And I completely fell apart.

Jazz is a different language.

The chords are more complex — 9ths, 11ths, 13ths stacked on top of each other in ways classical music rarely goes. The rhythm is fluid, not fixed. And the most important skill — the one that makes jazz jazz — is improvisation.

You can’t improvise from sheet music. You have to listen to the room, to the other musicians, to what just happened two bars ago, and respond in real time. There’s a framework underneath it all, a set of standard progressions and scales, but what you do with that framework in the moment is entirely up to you.

My classical training gave me foundations. It did not give me jazz.

I spent months humbled by this. A skilled musician, unable to play freely.

A few years later, I became a Solutions Engineer at HashiCorp — and had the exact same experience.

I understood the products. I had done the certifications, read the documentation, practiced the demos. I knew Terraform and Vault technically. By most measures, I was prepared.

But the first time I was in a live discovery call with a customer who went completely off-script — who had a problem I hadn’t anticipated, a technical environment I hadn’t seen, and a business context that changed every assumption I had made — I froze.

My classical training, the structured preparation, the rehearsed demo flow — none of it applied.

What the customer needed was jazz.

The parallel became impossible to ignore.

In jazz, you use a set of foundational elements — scales, chord progressions, standard forms — as a launchpad for improvisation. You don’t abandon structure. You internalize it so deeply that you can move freely within it.

In SE work, the same principle holds. The product knowledge, the methodology, the discovery framework — those are your scales. The real skill is what you do in the moment when the customer goes somewhere unexpected. When the technical question becomes a business question. When the demo needs to pivot. When silence in the room means something and you have to decide what to do with it.

That’s not something you can prepare for slide by slide. It has to be practiced, developed over time, through reps.

What changed for me in both cases was the same thing: I stopped trying to control the performance and started trying to listen.

In jazz, the best improvisers are the best listeners. They’re not playing what they planned — they’re responding to what’s happening.

In SE work, the best discovery conversations happen the same way. Not when you steer the customer toward your prepared narrative, but when you actually hear what they’re telling you and respond to it honestly.

I’m still not a great jazz pianist. I’m working on it.

But I think about jazz every time I’m in a customer conversation — especially the ones that go somewhere I didn’t expect.

Those are the best ones.

Have you found an unexpected parallel between something you did before tech and the work you do now? I’d love to hear it.

Then I volunteered for booth duty at Black Hat in Las Vegas — and found out I didn’t.

The floor was loud. Hundreds of conversations happening at once. People walking past fast, glancing at the booth, ready to keep moving unless you gave them a reason to stop.

I had slides. I had flyers. I had a folder full of marketing materials for every possible question about Terraform and Vault.

None of it mattered.

Within the first hour, I realized that no one wanted a feature walkthrough. They wanted to know one thing: what does this actually do for me, in plain English, right now.

The materials I had spent time preparing were built for a different environment — a quiet room, a captive audience, someone who had already agreed to listen. Black Hat was none of those things.

So I started improvising.

When someone asked what Terraform does, I stopped reaching for a slide and said:

“Imagine you’re a chef. Terraform is your recipe book for cloud infrastructure. It tells you exactly what ingredients you need and how to combine them to build your dish. Except instead of food, you’re building servers, networks, databases — and you can reproduce that exact dish anywhere in the world.”

They got it. Immediately. And they wanted to know more.

That moment changed how I explain technical things — not just at conferences, but in customer calls, in demos, in conversations with my own team.

Here’s what I learned:

Simplicity is not dumbing things down. It’s respecting the other person’s time and attention. The clearest explanation is almost always the most accurate one. Jargon is usually a sign that the speaker doesn’t fully understand what they’re explaining yet.

Stories land where facts slide off. Features and benefits go in one ear and out the other. A story — a real one, with a specific person or situation — sticks. When I stopped listing what Terraform does and started sharing what a customer did with it, the conversation changed.

Authenticity closes the gap. The most effective moments at that booth weren’t the polished ones. They were the honest ones — “that’s a great question and here’s what I actually think” — rather than falling back on the script.

I came home from Black Hat with no leads logged and no formal outcomes to report.

But I started every customer conversation differently after that. Less prepared, in the rigid sense. More present. More willing to find the analogy on the fly rather than pull up the deck.

The loudest conference floor turned out to be the best classroom I’ve had in tech.

What’s the best analogy you’ve ever heard for a technical concept? I’d love to collect them — drop it in the comments.

Scrambling to understand the product. Piecing together answers from docs, Slack threads, asking senior people questions I worried made me sound green. Trying to look field-ready before I actually was.

Last month I was doing competitive research — checking what the big players were doing with AI on their websites. So I opened one of their product pages and started using the chatbot. Not casually. I asked the kind of questions I used to panic about as a new SE: architecture edge cases, integration complexity, failure modes, compliance requirements.

The answers came back in seconds. Detailed, accurate, well-structured.

This tool would have changed everything for me in year one.

And then the other thought followed immediately: buyers are using this same tool right now. They show up to calls with your SE already knowing the product — educated by AI before the meeting was even booked. The SE who shows up to deliver information is walking into a room that no longer needs them for that.

That’s not a future risk. It’s already happening.

AI isn’t coming for Solutions Engineers. It’s coming for a specific version of the role: the one whose entire value is answering product questions. And if that’s still the job description, the problem isn’t AI. It’s that the bar moved and the role didn’t.

Two markets are emerging from this shift, and they look nothing alike.

The first: AI as replacement. Automate the demo, generate the proposal, answer the RFP. The SE becomes unnecessary because AI handles information delivery faster and cheaper.

The second: AI as elevation. Use AI to handle the commodity work — demo prep, environment setup, RFP responses — so SEs can spend more time on the work that actually wins deals. Discovery. Architecture design. Whiteboarding. Building trust with technical buyers who’ve already done their homework.

The first market gets the headlines. The second gets the enterprise contracts.

The skill that separates good from great isn’t product knowledge. AI will always know the product better. It’s not demo fluency — AI can generate a personalized demo in minutes.

The irreplaceable skill is live technical problem-solving with a human being in the room.

The whiteboard session where a customer describes a migration that doesn’t fit any reference architecture, and the SE sketches a solution in real time. The moment in discovery where the SE catches that the stated problem isn’t the actual problem. The ability to say “honestly, this isn’t the right tool for that use case” — and gain trust instead of losing the deal.

That requires situational judgment, technical creativity, credibility through vulnerability, and human connection. None of which the chatbot has.

The question isn’t how to teach SEs the product faster. AI already does that better than any onboarding program.

The question is how to develop SEs into practitioners who can diagnose, architect, and advise at a level that makes AI a tool — not a replacement. Scenario-based practice instead of product walkthroughs. Live feedback instead of self-paced modules. Competency that shows up in a real customer conversation, not a certification score.

I think about what my first year would have looked like with AI handling the knowledge ramp — and me spending that time instead on the skills the chatbot can’t teach.

That’s the version of readiness worth building.

What would have changed for you as a first-year SE if you’d had access to tools like this? I keep wondering what we’re still leaving on the table.