Understanding What Engineers Actually Need, with Lara Hogan

TLDR: Refactoring's Luca Rossi sat down with Lara Hogan, a coach and former VP of Engineering at Kickstarter and director at Etsy, to talk about leadership that started with a philosophy degree. The conversation covers how strong teams are adopting AI in a way that keeps engineers feeling safe, and how the BICEPS framework helps you decode what people actually need at work instead of guessing.

Summary: Lara Hogan's career is a useful reminder that there's no single approved on-ramp into engineering leadership. She studied philosophy, then built a long run as a director at Etsy, VP of Engineering at Kickstarter, and roles at other companies before moving into full-time coaching for managers and leaders across the industry. That philosophy background isn't a footnote. A lot of what she does now is about asking better questions and noticing the assumptions people carry into a room, which is exactly what good engineering leadership comes down to once you stop firefighting tickets and start managing humans.

The part of the interview I'd pay closest attention to is how the best teams are adopting AI. Hogan's angle is less about which model or tool you pick and more about psychological safety. When you drop AI tooling on a team without context, people quietly start wondering whether the message is "get faster" or "you're about to be replaced." That fear doesn't show up in standup. It shows up as people not experimenting, not sharing what worked, and not admitting when a tool wasted their afternoon. The teams getting value out of AI are the ones where leaders explicitly make it safe to try things and safe to say they didn't work.

That connects to what she calls AHA meetings, a format for learning together. The idea is to create a regular space where people share what they've figured out, including the dead ends. It's a small ritual, but it does real work. It turns scattered individual tinkering into shared team knowledge, and it signals that exploration is part of the job rather than something you sneak in between "real" tasks. For AI adoption specifically, that matters, because most of the useful patterns right now are being discovered by individuals and never make it past their own editor.

The centerpiece is the BICEPS framework, which Hogan uses to understand people's core needs at work. BICEPS covers belonging, improvement and progress, choice and autonomy, equality and fairness, predictability, and significance or status. The argument is that when someone reacts badly to a reorg, a new process, or yes, a new AI mandate, they're usually reacting to one of these needs being threatened. A reorg can hit belonging and predictability at once. A new tool that automates part of someone's craft can hit significance. Naming the specific need lets you address the actual problem instead of treating every objection as generic resistance to change.

I'll push on one thing the interview seems to soft-pedal, at least from the summary. Frameworks like BICEPS are diagnostic, not prescriptive. They help you name what's threatened, but they don't tell you what to do when two people's needs genuinely conflict, or when the business decision really does reduce someone's autonomy and no amount of framing changes that. The honest version of this work is sometimes "I can see your need for predictability is taking a hit here, and I can't fully fix that." What's missing from a lot of leadership content, and I'd want to hear Hogan address it directly, is the limit of empathy when the underlying decision is non-negotiable.

Key takeaways:

Engineering leadership has no canonical entry path; Hogan came in through philosophy and a coaching mindset, and the questioning skill transfers directly.
AI adoption succeeds or fails on psychological safety more than tool choice; fear of replacement quietly kills experimentation.
AHA meetings turn private AI tinkering into shared team knowledge by making it normal to share both wins and dead ends.
The BICEPS framework (belonging, improvement, choice, equality, predictability, significance) gives you language to diagnose why people react to change.
Most negative reactions to reorgs, processes, or new tools map to one of these threatened needs rather than plain stubbornness.

Why do I care: If you lead frontend engineers or sit at the architect level where you're nudging a team toward Copilot, Cursor, or whatever's next, this is the practical layer under all the AI hype. The technical rollout is the easy part. The hard part is that a senior engineer who's proud of their craft hears "use the AI" as "your significance just dropped," and they'll quietly resist in ways that never show up in a sprint board. BICEPS gives you a vocabulary to spot that and talk about it directly, which beats pretending the resistance is about the tool's autocomplete quality. This is mostly a management and team-dynamics story, but as a developer you should care too, because recognizing which of your own needs is getting poked makes you a lot less reactive when the next mandate lands on your desk.

Understanding Engineers' Needs — with Lara Hogan