Why I Wrote This Book

I am writing this from inside the problem.

Not as someone who figured it out, left, and wrote a book about what they learned on the way out. As someone who is still managing teams, still navigating the constraints, still watching the same patterns play out that I have watched play out for the better part of two decades — and still believing that something can be done about them from inside, even when the organization is working against it.

Here is what is happening right now, at my current job, as I write this.

My teams have been successful. We work as a product team — oriented toward outcomes, thinking in problems rather than tasks, delivering consistently and showing the results. The kind of culture this book describes. And the reward for that success is that leadership is considering reassigning some of my engineers to help teams that cannot get their projects done.

The logic is rational from the outside: your team gets things done, these other teams are struggling, redistribute the talent.

What gets missed is the reason my team gets things done. It is not the engineers themselves — it is how we work. The conditions we built. The way requirements get framed as problems, the way outcomes get named before work begins, the way engineers are expected to think rather than just execute. Move those engineers into a project-thinking environment and the conditions disappear. The engineers adapt to their new environment, the way people always adapt to their environments. The thing that made them effective stops being possible.

And here is the part that makes it worse: the engineers who are most likely to get reassigned are the ones who look most compatible with a project-thinking team. The passive ones. The ones who are still in the process of becoming hunters. The ones who need the conditions most.

I have watched this happen before. It is the same mistake, made again, by people who see the output and not the journey.

I started my career as a mainframe developer at a national bank. I spent nineteen years there, working on teams across the full stack — mainframe, internal applications, customer-facing web, partner APIs. I watched the organization go through an Agile transformation. I watched the pilot work because it was set up to work — cross-functional, empowered, given a real problem to solve. I watched the organization scale the rituals instead of the conditions, forcing mainframe teams to run two-week sprints on quarterly release cycles, layering Agile ceremonies on top of waterfall budgets.

I watched engineers learn to perform Agile rather than practice it. To write user stories for work that had no user. To run retrospectives where nobody said what they were actually thinking. To wait to be told what to build because initiative had become dangerous in an environment that said it valued initiative.

Then I joined a second bank and watched it happen again.

Not because the people were different. Because the system was the same.

The thing I hear most often from engineering managers is some version of this: “Agile works — just not the way our organization implemented it.”

They are right. And they are more alone than they should be.

Agile was designed to give engineers autonomy, fast feedback loops, and the ability to adjust based on what they learn. It was designed by practitioners who understood what good engineering work actually requires. What gets implemented at most large organizations is something else entirely — the ceremonies without the conditions, the vocabulary without the values, the appearance of agility without any of the substance.

And the people who pay for that gap are the engineers. They get all the overhead of Agile — the standups, the story points, the retrospectives — with none of the autonomy that makes it meaningful. They get trained, slowly and systematically, to wait. To stay in their lane. To do what they’re told and survive.

The transformation gets designed by people who don’t deliver. It gets forced on the people who do. And then the people who designed it wonder why the engineers aren’t more engaged.

I wrote this book because I wanted engineering managers to have something I did not have when I needed it most.

Not a framework. Not a methodology. Not another set of ceremonies to layer on top of the ones that aren’t working.

A map. Written by someone who has been inside the machine long enough to know where the walls are — and where the doors are, if you know how to find them.

The book is called Getting Engineers to Give a Damn. It is for engineering managers inside large, constrained organizations — banks, regulated industries, anywhere that adopted the rituals of Agile while keeping the infrastructure of waterfall. It is practical and it is honest and it does not pretend the system is going to change.

What it does say is this: the system does not have to change for your team to work differently inside it. You can build a culture of ownership even when the organization is working against you. It takes longer than you want and it is never finished and the organization will always be trying to undo it.

But it is possible. I know because I am doing it right now, in the middle of a reorganization that is trying to take it apart.

The engineers on my teams are not beaten down. They show up to refinement having thought about the problems. They ask why before they ask how. They help each other without being asked because they understand that the sprint goal belongs to all of them. They are proud of what they build.

That did not happen because of a transformation initiative. It happened because someone decided to create conditions where it was possible — and kept creating them, sprint after sprint, even when the organization pushed back.

I wrote this book for the managers who are making that same decision. The ones who know the ceiling is higher than the organization believes, and who show up every day committed to proving it.

If that is you — the book is here.