After publishing my critique of SAFe Agile, I received feedback that went far beyond what I expected. Rather than simple agreement or dismissal, people came back with some fire takes that genuinely got me thinking.

As a quick recap: my original post argued that SAFe Agile violates the four core principles of agile while giving executives cover to claim “we’re agile” to shareholders. As engineers, our value comes from solving problems - work that happens in code, not meetings. Therefore, we should fiercely protect our deep focus time. If you would like to read it, here’s a link.

The feedback revealed something I’d missed: I was assuming efficiency as a universal driver. Three specific challenges emerged from this blind spot, and I want to address each.

Assuming Efficiency

The most fundamental criticism was my assumption that people naturally gravitate toward efficiency. That’s not reality. Plenty of people don’t care about optimization if they’re hitting their goals, why do more? This is a legitimate approach to work, and my original argument didn’t account for it.

This is where I was weakest. I wrote prescriptively about what engineers should do, but prescriptive language doesn’t invite adaptation - it demands compliance. The irony? This is exactly what makes SAFe problematic: assuming one framework fits all contexts. I was doing the same thing from the opposite direction.

Better approach: share ideas, not mandates. Let people take what works and ignore the rest.

Working in a Globalised World

Tech teams often span multiple time zones sometimes just a few hours apart, sometimes eight or more. How do you protect deep focus time when your European team needs to collaborate with colleagues in Indonesia or the United States?

This is a genuine limitation of my original recommendations. That said, there are practical approaches:

  • Leverage asynchronous communication for standups and status updates
  • Concentrate meetings in overlap hours, preserving non-overlap time for focused work
  • Use documentation to reduce synchronous communication needs

It’s not a perfect solution, but it acknowledges the constraint while still prioritizing focus time where possible.

Operations as a Product

The final pushback: as a security engineer, I’m not building a product like software developers do, so product-thinking doesn’t apply.

I respectfully disagree. I am building a product - it’s just different. Instead of shipping features, my product is vulnerabilities fixed and risk reduction. Security engineering involves significant dev work, platform management, and for pentesters especially, deep investigative work. When you’re pulling on a thread while hacking, unraveling a complex puzzle, that flow state is exactly what needs protection.

Perhaps I failed in language. In my mind, operations is a product - the product of risk management and organizational security posture.

Conclusion

My perspective on SAFe Agile hasn’t fundamentally changed. But I was too dogmatic about pursuing ultimate efficiency without acknowledging context. Any system needs to be adapted to your specific organizational reality—there’s no one-size-fits-all approach.

The feedback I received was energizing. In an age of echo chambers and superficial engagement, taking time for substantive written debate feels increasingly rare and valuable. These kinds of exchanges help refine ideas beyond the atomized attention of social media feeds.

That’s the benefit I see in this corner of the internet: space for organic exploration and debate within my network. And for that, I’m grateful.