We all want our teams to work as effectively as they can. We aim for amazing results — powerful systems, groundbreaking innovations, and insights that will give us a competitive edge. But how do we get everyone to actually delivery on that kind of promise? By putting people first — as opposed to process. Though agile is all about process and that’s where much of our attention has gone, it’s time we shifted out focus on people and interactions. That’s the key to unlocking real success.
In his new book “People Over Process: Leadership for Agility“, technology expert Michael K. Levine delivers a new approach for leading teams to remarkable innovation and results. Levine was an early proponent of agile and is a veteran of systems change and technology management. The strategies in his book have been proven out at complicated, large-scale organizations, and build on his long experience in technology solutions. It’s a new way of thinking about agile that builds in agile’s tenets and takes them to a new level.
Levine recently sat down with Young Upstarts to share his insights on the power of focusing on the human side of agile, and why it’s critical to achieve success.
Can you talk a bit about yourself? What’s your main focus?
I’ve spent my career doing large-scale high impact technology management for major US institutions. I love taking on impactful challenges that require mobilization of large teams and multiple organizations, and delivering solutions that make a difference. From early time-sharing systems on rented mainframe terminals to recent public cloud multichannel solutions, I’ve observed that the real leverage points and challenges are the people, not the technology.
I was an early adopter in financial operations and software of lean operational and product development techniques that originated at Toyota, and then of agile as it was promulgated in the Manifesto. My education was liberal arts, and my interest in sharing my insights to help prevent software disasters led me to write a trilogy of books on lean and agile software, culminating in my latest focusing on people and leadership (People Over Process: Leadership for Agility).
What prompted you to write this book — in terms of your own experience with the question of which comes first, people or process?
Let me answer in two parts: what prompted me to write my first book of the trilogy, Tale of Two Systems, and then this particular book.
I was one of four leaders of an enormous failed development project at Wells Fargo around 2007. My team had already successfully adopted lean operational processes in a very large manufacturing-like process, as well as early agile ideas. Our part of the initiative was great: we had built out pioneering eClosing for mortgages, online document delivery and uploads, a sophisticated document generation system, efficient and accurate document imaging and indexing, but the rest of the project failed. So despite us being ready to release, the whole team was let go and Wells started over. We had tried to help the rest of the team adopt some lean and agile techniques that would have helped, but they were so committed to awful waterfall-type process that we entirely failed.
Almost as therapy, I undertook to write a book that would be accessible to business leaders dependent on large-scale technology to help them avoid such devastating failure. Wells Fargo had great business leaders, plenty of money; I believed that the core misunderstanding of how to do a large project like this was at the root of the problem and wanted to help.
Fast forward a few years. Similar desires led me to write the second book as I saw organizations struggle to implement agile, mostly around top-down mandates versus bottom up organic growth. Neither approach is “right” — it depends on context. Which brings us to this book. Like the others, it grew out of seeing problems in practice, this time the problems of mistakenly thinking that implementing scrum is the same as become agile. After seeing too many “product owners” mindlessly writing out “user stories” in the agile tool, essentially doing big requirements up front just like they used to in waterfall, I resolved to finish up the trilogy.
Obviously, at least to me, people come first. Process and tools are valuable as well. But blindly following processes or using prescriptive tools gets us right back to waterfall.
Can you expand on the idea of “leadership for agility” — are you talking particularly about agile software development, or can this model be applied to other endeavors, other enterprises? It does seem like agile is a work used a bit too often without a clear sense of what it really means.
It is a leadership style for when you need many smart, creative, opinionated people designing and building complicated new things in uncertain context, and the thousands of decisions made need to result in something that fits together and runs with few flaws. I drew inspiration from how Toyota designed a new car. Before I wrote my first book I spent a few weeks at a University of Michigan seminar on lean product development. I was the only person from software or finance. There were even folks from nuclear power plant design there, and I was amazed at how far ahead of us manufacturing was. In short, leadership for agility applies to any endeavor with these kinds of characteristics.
With Pacifica, the mythical company you created, how did you draw from experiences you’ve had with other companies, and in your own professional capacity? What can leaders glean from Pacifica’s efforts to better structure itself and facilitate lasting innovation?
I drew from experiences in my career and also from the leading software companies I’ve had the pleasure of partnering with. The teaching parts of the book draw on what I’ve learned from all these talented, smart people and organizations. The scenes and characters are all fictional, constructed to demonstrate ideas and techniques.
Leaders should start with the right people and interactions. Not to say other structural aspects are unimportant, but people make the difference and people sustain agility. Pacifica wisely began by bringing in some outsiders with experience, and then supplemented that with additional expertise, but never let its important existing team members feel out of the loop or out of control. They taught leadership, not just scrum.
One of the key tenets of agile is keeping leaders out of the teamwork. But you’re talking about bringing leaders in to be deeply involved and facilitate better results. Are you saying there’s no place for scrum, for instance? What about the other principles of agile?
I still love and use scrum widely. But without leadership it fails, and with great leadership it evolves. Organizational leaders are not worthless “middle-managers” — they have experience, power, accountability and should be deeply involved in agile delivery. Think about failed projects: sometimes, the whole team will get fired, but more often it’s the organizational leaders. Agility requires effective organizational leaders … doing facilitative leadership. The agile tenets hostile to leaders contemplated a different kind of leadership, not the kind we need to create and sustain.
What are the differences in terms of leadership approaches between developing new products — as so many organizations find themselves under pressure to do — and manufacturing existing products?
Manufacturing calls for “predictive process control” — standardization and continuous improvement. New product development calls for “adaptive process control” — facilitating creativity, rigorous decision-making based on facts, and the efficient alignment of many viewpoints. This is a key point that’s poorly understood. Getting “which is which” right is a core obligation of facilitative leaders.
Can you talk about the Facilitative Leadership triangle — rigor, alignment, efficiency, and then frameworks?
I learned this from a very wise teacher many moons ago. We’ve taught my teams for a long time and it has become ingrained, changing the culture and feeding outstanding results. It goes back to your earlier question in when it makes sense to use, not just software but situations of new ideas, new tools, new people, new problems, all at scale. Rigor means doing the right things, alignment means most of the team rowing in same direction, and efficiency is about respecting people’s valuable time. Frameworks are just some common tools to help this all work. It is really just common sense: what kind of behavior and leadership fits this kind of endeavor?
