Simon Sinek’s The Infinite Game introduces a simple but powerful idea: business, leadership, and even life aren’t finite games with fixed rules and a clear endpoint. Instead, they’re ongoing, ever-evolving challenges where the goal isn’t to "win" but to keep playing and improving.
It’s always baffling when you see a company—well-funded, packed with smart people—consistently struggling to deliver software effectively. We’re not talking about under-resourced startups here; these are established organisations that somehow keep making the same mistakes.
No one sets out to design a bad architecture. But over time, poor decisions, evolving complexity, and lack of visibility can introduce anti-patterns that undermine maintainability, scalability, and clarity.
Tom DeMarco, along with co-authors Peter Hruschka, Tim Lister, Suzanne Robertson, and James Robertson, wrote Happy to Work Here as a follow-up to their classic Peopleware. The premise is simple: great companies aren’t just productive—they create environments where people actually want to work.
Fred Brooks’ The Mythical Man-Month is one of the most famous books in software engineering—and for good reason. Published in 1975 (but still painfully relevant today), it exposes the fundamental misunderstandings that plague software project management.
Michael Lopp’s Managing Humans is not your typical management book. It’s not filled with corporate jargon, pointless frameworks, or idealistic theories. Instead, it’s a brutally honest, often hilarious collection of stories and lessons from the trenches of tech leadership.
In the ever-evolving world of software engineering, the idea of "Architecture as Code" is gaining traction as a way to bring clarity and structure to complex systems. While software architecture has traditionally been something that is captured in diagrams, slides, or documents, treating architecture as code offers numerous benefits for teams, from better collaboration to improved maintainability. Let’s explore what this concept means and why it’s becoming an essential part of modern development workflows.
As engineering leaders, we often find ourselves at the crossroads of multiple teams—product, business, design, and operations. Success in this environment isn’t just about building great technology. It’s about ensuring that technical decisions align with business objectives and that all teams are moving in the same direction.
When it comes to documenting and visualising software architecture, the C4 model offers a structured and effective approach. But what if you could automate the creation and maintenance of your C4 diagrams directly from the code? That’s where Structurizr comes in. In this post, we'll explore how Structurizr makes the C4 model even more powerful by allowing you to define, visualise, and update your architecture in code. That keeps it aligned with the actual system as it evolves.
Simon Sinek’s Start with Why presents a simple yet powerful idea: great leaders, businesses, and teams succeed because they have a clear purpose—their why. While the book is often framed as a leadership philosophy, at its core, it’s just a sensible approach to decision-making, communication, and building organisations that actually work.