Leadership, Craft, and the Art of Jamming Together: Rethinking How Design and Engineering Teams Actually Work

I've been thinking a lot lately about what separates effective technical leadership from the well-intentioned but distant variety. And I think the answer is simpler than we make it out to be: you have to actually work with your team. Not oversee them. Not check in on them. Work with them.

That's the underlying thread connecting five really interesting pieces from this week's Unicorn Club newsletter, and I want to talk through them because they're pointing at something fundamental we keep getting wrong.

Design Leaders Need to Jam With Their Teams

Let me start with something that feels almost revolutionary in how obvious it is once you hear it: design leaders should actively pair with their team members on craft. Not dictate pixels—that's the strawman that keeps this conversation stuck. I'm talking about hands-on mentoring, detailed feedback, and working through problems together.

Victor Wooten, the legendary bass player, teaches through apprenticeship. His students don't learn by watching from a distance; they jam with him. They make mistakes in real time. He corrects them in real time. There's immediate feedback, immediate learning.

But we've created this false binary in design leadership: either you're micromanaging every decision, or you're strategically detached. Either you care about the pixels, or you trust your team. And it's nonsense. The best design leaders I know are the ones who are in the weeds with their teams, working through problems together, mentoring on craft while maintaining trust and autonomy.

This doesn't look like "do it my way." It looks like "let's figure this out together. Here's what I'm seeing. What are you thinking?" It's jamming, not controlling.

The missing piece here? What happens when you have designers with vastly different skill levels or experience. Jamming works beautifully with skilled musicians who understand theory. What about early-career designers who haven't internalized the fundamentals yet? The article doesn't quite address that—maybe jamming needs scaffolding.

But Here's the Catch: You Can't Design Software You Don't Work On

Right after you've decided to get hands-on with your design team, here comes the counterpoint: you can't meaningfully design software if you're not actually working on it. Every single day.

This cuts both ways. If you're a design leader who hasn't touched the codebase in six months, your design advice exists in a vacuum. You're thinking about ideal systems, not real constraints. You're not seeing the architectural debt that shapes every decision. You're not understanding why the engineering team keeps pushing back on your beautiful ideas.

Conversely—and this is the dangerous part—if you're an engineer working on a system, you have authority over that system's design because you understand it at a depth that generic advisors cannot. You see the second and third-order consequences. You see the actual vs. theoretical trade-offs.

Generic design advice is only useful for new projects or as a tie-breaker when you're genuinely stuck. The real work of architectural discussion requires people who are in it. Not architects who fly in quarterly. Not best practices from a blog post. People who work on the system every day and understand its constraints, its history, and its particular shape.

The tension this creates: What about specialized knowledge? A security architect or performance specialist might not work on a system daily but might have insights the daily team is missing. The article seems to dismiss that—but I think the real point is that external expertise only matters if the local team can actually absorb and apply it, which requires understanding the system deeply.

Personas Shouldn't Be Static Documents—Make Them Conversational

Here's a practical tool that solves a real problem: instead of persona documents gathering dust in Notion, build a centralized research repository and use AI to make them queryable.

Picture this: a stakeholder working on campaign messaging can ask the system "What would our users think of this campaign?" The AI synthesizes perspectives across all your personas and provides consolidated feedback. Instead of reading a 15-page persona document trying to extract relevance, you're in a conversation.

The genius here is that personas become AI-consumable. You document the behavioral observations and context—the actual data that matters—and the AI handles the synthesis. This turns research into a living, accessible resource rather than something that feels authoritative but disconnected from day-to-day work.

It's a small technical shift with a big cultural payoff: research actually influences decisions because it's accessible when decisions are being made.

What's missing: Who decides what's in the repository? Who ensures consistency and quality? This approach could easily devolve into garbage-in-garbage-out if there's not governance around the research artifact itself. And there's an implicit assumption that your AI synthesis is accurate—which depends heavily on how well you've documented persona behaviors.

Google's Strategic Shift Shows the Dangers of Command-and-Control at Scale

Google shifted from "let a thousand flowers bloom" to "more wood behind fewer arrows." Fewer big bets, more focus. On paper, it makes sense. In practice?

Many of those big-bet projects failed. And more importantly, the culture of product discovery broke down. You can't maintain real discovery practices when core assumptions can't be challenged. When the bet has already been made at the top, discovery becomes theater—you're validating a decision that's already been made, not actually exploring what might be true.

Layer on performance evaluation systems optimized for visible outputs rather than real outcomes, and you've got a system where people are incentivized to hit targets, not to ship products that actually matter.

This is what happens when you lose connection between strategy and ground truth. When leaders make bets without the information that only teams doing the work can provide. When you remove the feedback loop between execution and strategy.

The real lesson: Scale creates problems that look solvable through better structure, but they're actually solvable through better communication. Google didn't fail at "fewer arrows." Google failed at staying connected to reality.

Micromanagement Fear Might Be Masking Deeper Trust Issues

Finally, there's this scenario that's probably playing out at your company right now: a CPO asks for biweekly team reports. It gets called micromanagement. Teams resist.

But the real issue isn't the reports. It's that teams fear information will be misused. If your CEO is asking for metrics so she can understand how things are really going, that's leadership staying exposed to reality. If she's asking so she can catch teams slipping up and publicly hold them accountable, that's something else entirely.

The framework that matters here is mission command: leaders should be close to reality with frequent feedback loops and safe escalation paths. Your job as a leader isn't to know everything—it's to stay close enough to know when something's wrong and to have a team culture where people can escalate without fear.

The difference between judgment-based leadership and performance contract systems is massive. One says "I trust you to figure this out, but I want to stay informed." The other says "Here are your targets. Hit them or else."

What this article doesn't quite land on: The burden this puts on leaders. Staying close to reality at scale is exhausting. How do you do it without burning out? How do you maintain perspective when you're drowning in data? Maybe the real skill is learning to ask the right questions rather than demand the right reports.

Putting It Together: Work On What You Care About

These five pieces point at the same truth from different angles: effective technical leadership requires presence. Not omniscience. Not control. Presence.

Design leaders who jam with their teams. Engineers who have authority over systems they work on daily. Research that's accessible when it's needed. Strategies that stay connected to ground truth. Leaders who stay close enough to reality to know when something's wrong.

None of that works if you're delegating to distance. You have to actually do the work alongside your team. You have to understand the system deeply enough to make trade-offs that matter. You have to stay close enough to reality that you can course-correct.

This is the opposite of the "strategic detachment" leadership philosophy that's been in vogue. It's also the opposite of pure control. It's jamming—staying in the same key as your team while letting them lead.

Key Takeaways

• Hands-on design mentorship isn't micromanagement if it's built on trust. The distinction between jamming and controlling comes down to psychology and intent.

• Architectural authority should rest with people who work on the system daily. Generic best practices matter only for new systems or tie-breaking; real design happens through intimate knowledge.

• Make research consumable when decisions are being made. Static persona documents don't influence work; interactive, AI-powered synthesis does.

• Stay connected to ground truth or your strategy will calcify. Google's bet strategy failed because it lost the feedback loop between discovery and execution.

• Biweekly reports aren't micromanagement if they come from a place of shared safety. The question isn't whether you want information—it's whether your team trusts you to use it fairly.

• Leadership at scale requires asking better questions, not gathering more data. The burden of staying close to reality grows with team size; the skill is learning what to pay attention to.