Thoughts from LeadDev NYC 2025

I recently attended LeadDev NYC 2025.

Lots of people talking about guardrails and evaluations for agents. Reinforces the idea that effectively managing AI agents has parallels with effectively managing people.

Prompt decomposition. It’s hard to experiment with very large prompts because it’s difficult to work out which part of the prompt is influencing a specific behaviour. Do One Thing and Do It Well comes to mind.

The default approach to AI at organizations seems to be mass adoption rather than focusing exploration on the highest impact problems. It’s not surprising that eventually people start talking about “clawback” when the investments don’t produce any significant outcomes. I previously wrote about why unfocused large-scale transformation is bad strategy. It is useful to play around with lower-risk problems to understand capability but at some point, it’s worth redirecting to solving problems that matter.

Thoughts on communicating to non-technical stakeholders:

• When there is sufficient trust, including alignment on shared goals, it can be enough to say you need to do something even if they don’t fully understand why you need to do it.
• The overhead of negotiating each item is not always worthwhile. Instead, agree on an allocation (e.g., X% of work are engineering-driven).
• Learn each other’s language. This goes both ways. Engineers learning the product / business concepts and language. Product / business people learning technical concepts and language.
• There is a related but distinct problem about communicating at different time horizons.

Thoughts on engineering strategy

• “Strategy” is a fancy word. It can be more useful to think about this as problem-solving targeted toward the most critical engineering problems we need to deal with right now.
• Wishy washy product strategy is not the same as actual volatility in the environment.
• The appropriate time horizon for strategy depends on the context.
• It’s better to approach it as one problem, one strategy, not product strategy vs engineering strategy.

A lot of presentations reinventing / rediscovering concepts. It made me think that people really should read more and more presentations should include book references. The ones that came up for me were:

• Extreme Programming Explained
• Turn the Ship Around
• The Art of Action
• Organizational Culture and Leadership

Other miscellaneous thoughts:

• I’m still annoyed when Kanban people redefine what “estimation” and “prediction” mean.
• The company values that are written are not necessarily equivalent to what is actually valued by people in the company. See Schein.
• Being late matters more when you don’t decouple scheduling dependencies with interfaces and backup options.
• I suspect Jevon’s Paradox only applies when the resource is the fundamental constraint.
• Managing cognitive load and focus is a more useful framing than “leadership shield”.
• Over-focus on a locally optimized process is not the same as focus on end-to-end process (aka value stream) providing value to your customer(s).
• Feedback for insight is not the same as feedback for buy-in. See Draft, share, decide.