The Ernie Ball Stage
Mark,
Recently you said something that’s been stuck in my head: “Not many if any of the IT revolutionaries have a full holistic view of how a company works.”
You were talking about the Agile Manifesto signatories. Seventeen people in a ski lodge who figured out something that worked for software development. They were engineers who’d found a better way to build things—but they weren’t business strategists. They didn’t have a holistic view of how companies work because they didn’t need one. They were solving their problem.
Brett Gurewitz started Epitaph to put out Bad Religion records. He was solving his own problem—getting his band’s music out. Then The Offspring’s Smash sells eleven million copies and suddenly he’s running a major label operation he never planned for, dealing with distribution and scale and industry dynamics that weren’t part of the original vision. The Manifesto signatories wrote down what worked for them because they were solving their problem. And that’s fine—that’s how good ideas start. But here’s the thing: everyone talks about digital transformation like it’s an engineering problem, because the people who wrote the founding document were engineers solving an engineering problem. Every book, every conference talk, every training program—it’s all about getting engineering into a continuous learning state. That’s treated as 80% of the work.
But there’s another 80% that nobody talks about: getting everyone else in a position to embrace that same process. Sales. Marketing. Finance. Leadership. The people who set the goals, approve the budgets, and define what “success” looks like. If they’re not transformed too, you haven’t done a transformation. You’ve just created a team that iterates really well on requirements that were locked in six months ago.
This is why we’re starting this newsletter.
You and I have been having this conversation for years—about Agile, about management, about punk rock, about what it means to organize work without making everyone miserable. You’ve got the credentials: MBA in IT Management, Scrum certifications, ten years of experience. I’ve got twenty-five years of writing code, running teams, and maintaining infrastructure that nobody pays me for because someone has to.
We come at this from different angles. You’ve been on the teams responsible for digital transformations—the ones that were supposed to make the company agile—and you’ve watched them fail. Not because the framework was wrong, but because nobody transformed the organization around the framework. I’ve been on the receiving end of those transformations, watching the training end and the old patterns reassert themselves within six months. You sell “Agile is Anarchy” t-shirts, but recently it sounds like you’ve lost faith.
That’s the point. We’re not here to agree. We’re here to discuss what actually works, what’s theater, and whether the stuff we tell teams to do survives contact with the org chart.
Here’s what I keep thinking about: Warped Tour.
You brought it up. Warped Tour used to be where you went to hear bands you’d never heard of. It was a venue for new. And here’s the thing everyone forgets: while the Left Foot and Right Foot stages had the bands that made it, all of those bands started out on the Ernie Ball stage or the Kevin Says stage. The small stages. The ones where you played to thirty kids at 11am and hoped someone noticed. That’s where the actual work happened—the messy experimentation, the figuring it out, the learning by doing. The big stages were just where you ended up after you’d already done the hard part.
Then the shift happened. Atlantic and the other majors figured out the sound was marketable. They packaged it. And Warped changed because the audience changed—people stopped coming for the DIY discovery and started coming for the packaged version. Now it’s a nostalgia act—a venue for familiar. That’s not wrong for All Time Low. It’s just not the ethos that started things, and it doesn’t help the current generation of punk kids find their scene.
The Agile-industrial complex did the same thing. The Manifesto was a bunch of people saying “we tried something different and it worked better”—that’s the Ernie Ball stage energy. Learning by doing, sharing what you learned. But there was demand for the packaged version. SAFe and twelve-week training programs that cost more than my first car. Companies buy it because they want something they can implement without the messy experimentation—they want the ceremonies, not the ethos. That’s not wrong for them. It’s just not what started things, and it doesn’t help the people who actually need to figure out how to make this work in their own context.
And here’s the part that bothers me: the books all do the same thing. Two-thirds telling you what they’re going to explain and why it’s revolutionary (even when it isn’t). One-sixth on the actual idea. One-sixth on some loose guidance about how to maybe apply it to your world. Then they declare victory and leave you to figure out the hard part.
And because that’s how we teach it, that’s how people think about the work. They implement the framework—the part the book spent 80% on—and think they’re done. But they’ve only done 20% of the actual transformation. The other 80% is the application, the consequences, the part that happens when your shiny new process collides with an organization that wasn’t built for it.
The best books invert that. The Goal and The Phoenix Project work because they’re 90% walking you through someone applying the solution to their own problems and dealing with the consequences. You learn by watching someone struggle with implementation, not by reading a manifesto.
That’s what we’re trying to do here.
This is where I think you have something to say that I can’t. You’ve been on the transformation teams. You’ve watched the workshops happen, the victory get declared, and the engagement end. You’ve been left holding the bag when the implementation didn’t stick and the transformation quietly died. And now you’ve got the academic background to articulate why it died—not just “management didn’t buy in” but the structural reasons these things fail. I’ve only seen the downstream effects: the team that’s technically agile but can’t ship because finance won’t approve the budget cycle, the retro where everyone knows the problem is a VP but nobody can say it.
So here’s my question for Thursday: What’s the actual hard part? Not the theory—we’ve got plenty of books for that. The implementation. The consequences. The part that happens after the training ends and you’re the one who has to make it work inside an organization that wasn’t built for this.
I keep thinking about something MC Lars said: “contrived identification with youth sub-cultures to manufacture an antiauthoritarian identity and make millions.” He wasn’t wrong. But some of us still believe in the thing underneath the branding.
Do you?
— Chris
Agile is Anarchy is a conversation between two brothers about work, management, and whether any of this matters. Chris posts Mondays. Mark posts Thursdays. We’re figuring it out as we go.
Member discussion