Flow & Skills
Grow Potentials, drive Performance.
Photo de Peter Herrmann sur Unsplash
Career breakthroughs aren't luck. They crystallize from expertise meeting opportunity. A practical framework for engineering leaders who want to create their own key moments.
More content
Why I'm Building Noosia
I've spent twenty years circling the same question from different angles. As a researcher, a teacher, a parent, a manager, a builder. Same observation: how we help people learn feels broken. Not the content. The experience. So I decided to stop watching and start building.
Reading the Radar: How AI Became an Engineering Discipline in Twelve Months
Every week a new AI tool trends. Every month someone declares a paradigm shift. But underneath the buzz, the ThoughtWorks Technology Radar reveals a quieter story: across three volumes in twelve months, AI structured itself into an engineering discipline—with its own antipatterns, observability, infrastructure, and vocabulary. Here's what engineering leaders should take from that trajectory.
The Full Circle: 20 Years Ago I Studied AI. Then I Left. Here's What Happened When I Went Back to School.
In 2005, I was publishing papers on machine learning. Then I left research to build engineering teams. Fifteen years later, I enrolled in an AI agent training — not because I needed a refresher, but because exploring has a shelf life. This is the story of a full circle: from neural networks in a lab to building AI agents that solve real problems, and why every chapter in between mattered.
Discovering InnerSource
InnerSource isn't a buzzword here; it's alive. I see leaders empowering a community, driving governance, and supporting projects that span the entire organization. Through hackathons, conferences, and collaborative initiatives, engineers from different corners of the company contribute to shared projects and collectively solve problems.
Your Best Work Shouldn't Be a Secret
Recurring activities often happen on autopilot with inconsistent quality. Playbooks transform your team's expertise from tribal knowledge into repeatable practice through progressive disclosure—quick checklists for execution, practice guidance for learning, and supporting information for edge cases. Turn experience into capability by making your best work accessible to everyone.
Knowledge Silos as Organizational Debt: Why Collaboration is Risk Management
Knowledge silos create organizational fragility that accumulates silently until crisis reveals it. Collaborative practices like pair programming and systematic code review aren't operational overhead—they're strategic investments that strengthen team resilience, improve software quality, and reduce long-term costs by preventing systemic failures.
Code as Shared Space: Why Software Development Is Fundamentally Collaborative
Software development is fundamentally collaborative, but not in the way most people think. Every line you write is an act of communication with three distinct audiences: your future self, current teammates, and future maintainers. Understanding code as a shared space—like a flat with multiple roommates—reveals why clean code, clear naming, and thoughtful documentation aren't optional niceties but essential collaboration tools.
The Four Pillars of Software Craftsmanship: A Framework for Professional Growth
When code is unclear, every interaction requires explanation and negotiation. What we call technical debt is often code so unclear that working with it requires constant interruption. This reframing matters because it changes how we think about code quality—it's not about perfectionism, it's about whether your team can actually work together effectively.
The 1968 Software Crisis Never Ended: Why Complexity Still Wins
More than fifty years after the 1968 NATO conference identified the software crisis, we're still fighting the same battle against complexity. Each new abstraction—from high-level languages to AI-assisted development—solved complexity at one level while enabling even larger systems at the next. Understanding this pattern helps us recognize that managing complexity is ongoing work, not a problem to be solved once.
Why Technical Debt is Really Collaboration Debt
When code is unclear, every interaction requires explanation and negotiation. What we call technical debt is often code so unclear that working with it requires constant interruption. This reframing matters because it changes how we think about code quality—it's not about perfectionism, it's about whether your team can actually work together effectively.