Flow Engineering in Action: Insights from Authors Steve Pereira and Andrew Davis

Scroll down for how to subscribe, transcript, and more

---

My guests for Episode #512 of the Lean Blog Interviews Podcast are Steve Pereira and Andrew Davis, authors of the new book Flow Engineering: From Value Stream Mapping to Effective Action.

Steve Pereira has spent over two decades improving workflow across various organizations. His experience spans tech support, IT management, platform and infrastructure engineering, product management, and serving as a founding CTO for an enterprise SaaS company. Currently, he is the CEO of Visible Consulting, COO of the Value Stream Management Consortium, and co-founder of the Flow Collective.

Andrew Davis is the Chief Product Officer at AutoRABIT and the author of “Mastering Salesforce DevOps.” With a background as a Salesforce architect, developer, and product leader, Andrew focuses on the human side of software development. He spent 15 years as a Buddhist monk, teaching meditation and personal transformation, and now studies the intersection of business, technology, and psychology through systems thinking.

In this episode, we discuss the principles of flow engineering, the importance of psychological safety in process improvement, and their experiences in writing the book. We also dive into their personal journeys, inspirations from industry giants like Deming and Goldratt, and the challenges and lessons learned in collaborative work. Stay tuned for a deep, insightful conversation on enhancing workflows and fostering a culture of continuous improvement.

Questions, Notes, and Highlights:

• Can you discuss the relationship between making mistakes and learning from a Buddhist perspective, Andrew?
• Why do you resonate with figures like Deming, Goldratt, and Ackoff in your improvement work, Steve?
• How did you two end up collaborating on the book?
• Did you apply flow engineering concepts to the development and writing of the book together?
• How did the process of writing the book evolve over time?
• What lessons did you learn about collaboration and flow from writing this book?
• How does psychological safety impact value stream mapping and flow engineering?
• How do you involve workers in process design to avoid negative perceptions of imposed processes?
• What challenges did you face in maintaining a regular cadence of work while writing the book?

The podcast is brought to you by Stiles Associates, the premier executive search firm specializing in the placement of Lean Transformation executives. With a track record of success spanning over 30 years, it's been the trusted partner for the manufacturing, private equity, and healthcare sectors. Learn more.

This podcast is part of the #LeanCommunicators network. 

---

---

Full Video of the Episode:

---

Quotes:

Thanks for listening or watching!

This podcast is part of the Lean Communicators network — check it out!

---

Episode Summary & More

Embracing Flow Engineering: Insights from Experts

Welcome to an enlightening dive into Flow Engineering, featuring insights from experts Steve Pereira and Andrew Davis. These pioneers in process optimization and value stream mapping provide a profound understanding of how to bring greater efficiency and effectiveness to workflows within organizations. This article explores the thoughts they shared on the interconnectedness of business systems, the importance of embracing mistakes, and achieving personal and collective flow.

The Core of Flow Engineering

Understanding Flow and Value Streams

Flow Engineering revolves around the seamless movement of work and information through systems, ensuring that value is continuously delivered to end-users. This concept is deeply integrated with Value Stream Mapping (VSM), a visualization tool that helps identify bottlenecks, inefficiencies, and areas for improvement within a workflow. According to Steve Pereira, who has spent over two decades perfecting this approach, optimizing flow across an organization requires meticulous planning and strategic execution.

Steve Pereira's background in tech support, IT management, and product management has enriched his expertise in enhancing workflow. As a founding Chief Technology Officer of an enterprise SaaS company, and now CEO of Visible Consulting, his contributions to flow engineering are invaluable.

Principles and Applications

Flow Engineering is not just about identifying and addressing problems, but also about fostering a culture that encourages continuous improvement and adaptability. This approach resonates with the ideas laid out in the new book by Pereira and Andrew Davis, titled “Flow Engineering from Value Stream Mapping to Effective Action.” Their work emphasizes a shift from theoretical models to actionable strategies that can be customized to any organizational context.

The forward of their book, written by Karen Martin, author of “Value Stream Mapping,” underscores the critical nature of this method in driving meaningful change and efficiency in business processes.

Embracing Mistakes as Learning Opportunities

Philosophical Underpinnings

One of the key takeaways from the conversation with Steve Pereira and Andrew Davis is the perspective on mistakes. Their insights draw from both personal experiences and philosophical teachings. Andrew Davis's background as a Buddhist monk emphasizes the importance of accepting mistakes as a natural part of the learning process. He likens the inevitability of errors in engineering to the perfection found in the natural laws of physics, suggesting that every mistake offers a unique learning opportunity.

This approach aligns with the teachings of thinkers like Deming and Goldrat, who assert that systems are perfectly designed to achieve the outcomes they produce. Recognizing and learning from these outcomes is crucial for continuous improvement.

Applying the Philosophy to Business

In the context of business and technology, Pereira and Davis advocate for a mindset that views mistakes as integral to the process of innovation and improvement. By fostering a culture where individuals are not blamed for systemic issues, organizations can create an environment conducive to growth and learning. This perspective is particularly relevant in agile and DevOps practices, where rapid iteration and feedback are vital.

Pereira's role in developing and facilitating flow engineering since 2017 and Davis's contributions to the DevOps community highlight their commitment to integrating philosophical insights with practical applications in the technology sector.

Systems Thinking and Personal Flow

The Interconnectedness of Systems

Both Pereira and Davis emphasize the importance of viewing organizations as interconnected systems. This holistic perspective, influenced by systems thinkers like Acoff, is essential for understanding the complex interactions within an organization. They argue that many problems in business arise from the invisibility of these systems, which span psychological factors, relationships, and technology.

Steve Pereira's initiative in co-founding the Flow Collective aims to bring together professionals dedicated to optimizing these systems, furthering the understanding and implementation of effective flow engineering.

Achieving Personal and Collective Flow

Achieving flow, both at an individual and organizational level, is a central theme in Pereira and Davis's work. Personal flow, as described by Davis, involves creating conditions where individuals can work in a state of deep engagement and productivity. This requires minimizing distractions and creating environments that support sustained focus. On a broader level, collective flow is about ensuring that teams and departments can work harmoniously, leveraging each other's strengths to achieve common goals.

Their collaboration on the book “Flow Engineering” encapsulates these principles, offering a comprehensive guide to creating systems that support both individual well-being and organizational efficiency.

The Interplay of Process and Adaptability

Process as a Double-Edged Sword

Process is a double-edged sword in the realm of software development and organizational management. While process improvements can streamline operations and reduce errors, there is a risk of becoming too rigid. Both Pereira and Davis emphasize the need for flexibility and iterative improvements. They caution against premature standardization, which can stifle innovation and adaptability in fast-moving environments.

Their insights are a reminder that successful process management involves striking a balance between maintaining structure and allowing for ongoing improvements through techniques such as Kaizen.

Enabling vs. Governing Constraints

In line with the theories of constraint management, they distinguish between enabling constraints, which facilitate performance, and governing constraints, which restrict it. Effective flow engineering focuses on implementing enabling constraints that guide teams towards better performance without imposing unnecessary limitations.

Davis's application of these principles within his role as Chief Product Officer at AutoRabbit showcases how organizations can adopt these strategies to maintain a dynamic and responsive work environment.

By exploring these insights, we gain a deeper understanding of how to optimize processes, embrace mistakes as learning opportunities, and foster a culture of continuous improvement. The principles of flow engineering, as articulated by Steve Pereira and Andrew Davis, provide a roadmap for achieving greater efficiency and effectiveness in any organization.

Psychological Safety: The Cornerstone of Effective Process Design

In their exploration of process design and adaptability, Steve Pereira and Andrew Davis emphasize psychological safety as an indispensable element for fostering effective workflows. Psychological safety, a concept popularized by Professor Amy Edmondson, refers to a shared belief that the team is safe for interpersonal risk-taking. This is crucial for encouraging open communication and collaboration, especially in dynamic, high-stakes environments like software development and healthcare.

Intentional Design of Psychological Safety

Andrew Davis points out that while many organizations attempt to cultivate psychological safety, few do so systematically. Instead of treating it as an afterthought or a byproduct of good management, they argue it should be an intentional design aspect of the organizational culture. This means:

• Integrating psychological safety into processes: Making it an explicit goal in team charters, project kick-offs, and feedback mechanisms.
• Monitoring and measuring: Using indicators and feedback loops to continuously evaluate the level of psychological safety within teams and taking corrective actions when necessary.
• Training leaders and managers: Ensuring those in leadership positions understand the importance of psychological safety and how to foster it within their teams.

Bridging the Gap Between Process Designers and Users

One of the profound insights shared by Pereira and Davis is the distinction between those who design processes and those who execute them. This divide often manifests as a source of tension and inefficiency within organizations.

Involving Users in Process Design

Drawing inspiration from Toyota's principle that standardized work should be created by those doing the work, Pereira and Davis advocate for a more inclusive approach to process design. This involves:

• Collaborative design sessions: Engaging team members from various levels and functions in the design and iteration of processes.
• Feedback loops: Creating mechanisms for ongoing feedback and adjustments to processes based on real-world experiences and challenges faced by the team.
• Transparency and communication: Ensuring that the rationale behind process decisions and changes is clearly communicated to all stakeholders.

Balancing Structure and Flexibility

The need for balance between structure and flexibility is a recurring theme in their discussions. While processes provide a necessary framework to reduce errors and enhance efficiency, too much rigidity can stifle creativity and slow down operations.

Agile Methodologies and Process Adaptation

Agile methodologies, which emphasize iterative development and responsiveness to change, provide a model for balancing these elements. Key practices include:

• Sprint retrospectives: Regularly reviewing what worked and what didn't, and making iterative improvements to processes.
• Empowerment: Allowing teams the autonomy to adjust processes as needed to suit their specific contexts and challenges.

Minimizing Cognitive Load and Enabling Flow

In the digital age, where tasks often need to be executed in milliseconds, minimizing cognitive load and enabling flow becomes critical. High cognitive load can lead to burnout, reduced productivity, and increased error rates.

Techniques to Enable Flow

1. Simplifying processes: Eliminating unnecessary steps and automating repetitive tasks to reduce mental burden.
2. Clear and concise communication: Ensuring that information is easily accessible and understandable.
3. Focus time: Creating dedicated periods for deep work, free from interruptions like meetings and non-critical communications.

Value Delivery and Customer-Centric Processes

Central to the mindset of flow engineering is the ultimate goal of value delivery to the customer. This requires a shift from a purely inward focus on processes to an outward, customer-centric perspective.

Backward Design from Desired Outcomes

Pereira and Davis suggest starting with the desired outcomes and working backward to design processes that enable these outcomes. This approach contrasts with the reactive, additive nature of typical process adjustments:

• Defining clear outcomes: Establishing what success looks like from the customer's point of view.
• Designing supporting mechanisms: Creating processes that not only achieve these outcomes but do so sustainably and efficiently.

Conclusion: Redefining Success in Process Design

By embracing these principles, organizations can create environments where psychological safety, user involvement in process design, balance between structure and flexibility, minimized cognitive load, and a focus on value delivery coexist. This holistic approach not only enhances efficiency and effectiveness but also fosters a culture of continuous improvement and innovation. Steve Pereira and Andrew Davis offer a compelling blueprint for modern organizational success in their collaborative work on flow engineering.

Building Rapid Collaboration in Flow Engineering

In flow engineering, establishing psychological safety rapidly is essential to productive collaboration. This rapid development of safety is paramount, as it allows team members to express differing views openly without fear of repercussion. Such an environment encourages diverse perspectives, which is crucial for identifying and addressing any inefficiencies in the process.

Enabling Effective Collaboration

To achieve this, flow engineers can implement several strategies:

• Rapid Onboarding and Ice-Breaking Activities: Start sessions with activities that help team members get to know each other and build trust quickly.
• Setting Clear Expectations: Clarify the goals and expected contributions from each team member to ensure everyone understands their roles.
• Encouraging Open Dialogue: Foster an environment where team members feel comfortable sharing their insights and concerns.

Visualizing Work and Making the Invisible Visible

One of the cornerstones of flow engineering is visualizing work processes. This is particularly significant in environments like healthcare, where processes are not always physically observable but are critical to value delivery and patient care.

Techniques for Visualization

• Value Stream Mapping (VSM): A powerful tool for understanding and illustrating workflows. This helps identify areas of waste and opportunities for improvement.
• Digital Whiteboards: Tools like Miro or Lucidchart can facilitate real-time collaborative mapping of processes.
• Regular Feedback Sessions: Use retrospective meetings to continuously update and refine the visual maps based on real-world feedback.

Addressing Psychological Barriers

Psychological safety isn't just about reducing fear–it's about nurturing an environment where team members embrace imperfection as a natural part of continuous improvement. Accepting current realities without assigning blame creates a foundation for genuine progress.

Fostering Emotional Intelligence

• Emotional Intelligence Training: Equip team members with skills to manage their emotions, handle stress, and work collaboratively.
• Creating Safe Spaces for Honest Discussion: Implement regular sessions where employees can voice their concerns and suggestions without judgment.
• Recognizing and Reinforcing Positive Behaviors: Acknowledge when team members take risks or provide valuable feedback to reinforce the behavior you wish to see.

Beyond Process: Understanding Human Elements

Effective process design also requires a deep understanding of the psychological and sociological elements within an organization. Health workers, for example, often carry a deep sense of responsibility and fear of causing harm, which can create internal pressure and stress. Addressing these underlying psychological factors is essential for fostering an environment conducive to open communication and continuous improvement.

Integrating Psychological Insights

• Counseling and Support Systems: Provide resources for mental health support and counseling to help manage the emotional demands of the job.
• Workshops on Stress Management and Resilience: Offer training to build resilience and cope with the stresses that come with their roles.
• Peer Support Programs: Establish mentorship and peer support groups to create a community of understanding and encouragement.

Mastering the Art of Flow in Knowledge Work

Flow in knowledge work, such as writing a book, requires iterative development and continuous improvement. Steve Pereira and Andrew Davis's journey in writing “Flow Engineering” exemplifies the need for collaboration and flexibility in complex, creative endeavors.

Iterative Development in Writing

• Regular Cadence of Work Sessions: Maintain a consistent schedule for collaboration to ensure steady progress.
• Begin with the End in Mind: Define clear goals and outcomes for the project, then break them down into manageable tasks.
• Revisiting and Revising: Accept that initial drafts are just the beginning. Revisit and refine segments regularly to enhance quality and coherence.

Final Thoughts on Collaborative Excellence

The iterative and collaborative nature of flow engineering highlights its applicability beyond traditional engineering realms. Whether improving complex systems in healthcare or co-authoring a book, the principles of flow engineering–psychological safety, visualization, and continuous feedback–are universal.

This methodology not only optimizes processes but also enhances the human experience within those processes, creating a more effective, empathetic, and high-performing organization. As Pereira and Davis's work shows, the journey from designing workflows to fostering cultural and psychological elements is key to achieving sustained success.

Impact of Collaboration and Feedback in Knowledge Work

Effective collaboration extends beyond technical processes and permeates the creative spaces of knowledge work, such as writing and content creation. A significant theme discussed by Steve Pereira and Andrew Davis is the importance of consistent and transparent feedback mechanisms in driving continuous improvement.

Open Channels for Feedback

To cultivate a culture that values and leverages feedback, organizations and teams can:

• Regular Check-Ins: Schedule frequent meetings to discuss progress, roadblocks, and improvements in an open forum.
• Feedback Loops: Implement structured feedback loops such as After Action Reviews (AARs) or Plus/Delta sessions to systematically analyze what went well and what could be improved.
• Anonymous Feedback Options: Provide platforms where team members can give feedback anonymously to highlight unspoken issues or ideas.

Applying Lean Principles in High-Velocity Environments

The principles of lean and flow engineering are indeed universally applicable, as emphasized during their discussion. Even in fast-paced tech environments or highly regulated areas like healthcare, lean methodologies can streamline processes and enhance collaboration.

Adapting Lean for Tech

• Kanban Boards: Use tools like Trello or Jira to manage tasks visually, maintaining a continuous flow of work and reducing bottlenecks.
• Automated Testing and Continuous Integration: Leverage technology to automate repetitive tasks, ensuring quick feedback cycles and rapid iteration.
• Lean Startups: Adopt the build-measure-learn feedback loop to develop products that meet real user needs effectively and efficiently.

Encouraging Cross-Industry Learning

One of the pivotal insights shared by Steve and Andrew is the immense value of cross-industry learning. By observing and integrating successful practices from different domains, teams can innovate and improve existing workflows.

Strategies for Cross-Industry Integration

• Industry Conferences and Workshops: Attend events across various industries to garner new ideas and methodologies.
• Case Study Analysis: Regularly study successful case studies from different fields to identify transferrable practices.
• Collaborative Platforms: Engage in online forums and professional networks like LinkedIn to share and gain insights from diverse professional experiences.

community Involvement and Real-World Testing

To validate and refine flow engineering practices, Steve and Andrew encourage feedback from professionals actively engaging with these methodologies. Particularly in fields like healthcare, real-world testing and communal learning are invaluable.

Practical Application in Healthcare

• Pilot Programs: Start with small, manageable pilot programs to test new strategies and gather data on their effectiveness.
• Interdisciplinary Teams: Form teams comprising members from diverse backgrounds to bring multiple perspectives to problem-solving.
• Feedback from Practitioners: Regularly seek input from frontline practitioners who interact directly with the processes being improved.

The Role of Technology in Enhancing Collaboration

Technological advancements continually transform how teams collaborate and communicate. Leveraging the right tools can significantly enhance productivity and drive innovation.

Essential Collaboration Tools

• Real-Time Communication Platforms: Use tools like Slack or Microsoft Teams for seamless, real-time communication.
• Document Collaboration: Google Docs or Confluence for collaborative document creation and editing.
• Project Management Software: Platforms like Asana or Basecamp to manage projects, timelines, and responsibilities effectively.

Continuous Learning and Adaptation

In the rapidly evolving landscape of technology and business, continuous learning and adaptability are crucial. As Steve and Andrew suggest, remaining open to new ideas and willing to pivot strategies based on feedback can lead to sustained success.

Building a Learning Culture

• Training and Development Programs: Invest in regular training sessions and professional development courses.
• Knowledge Sharing Sessions: Hold regular internal workshops where team members share new insights and best practices.
• Adaptive Planning: Embrace agile methodologies that allow teams to quickly adapt to changes and new information.

Conclusion on Collaborative Excellence

The insights from Steve Pereira and Andrew Davis underscore the universality of the principles of flow engineering and lean methodologies. Whether applied in high-velocity tech environments or mission-critical healthcare settings, the focus on collaboration, continuous feedback, and process visualization drives both efficiency and innovation.

By fostering a culture of psychological safety, leveraging appropriate technologies, and encouraging cross-industry learning, organizations can unlock new levels of productivity and employee satisfaction, leading to sustained success in any field.

---

Automated Transcript (Not Guaranteed to be Defect Free)

Mark Graban:
Hi, welcome to lean blog interviews. I'm your host, Mark Graban. We have two guests today. We're joined by Steve Pereira and Andrew Davis. They are authors of the new book titled Flow Engineering from Value Stream Mapping to Effective Action. The foreword is written by Karen Martin, author of a book called Value Stream Mapping. She's a friend of mine and a frequent guest on this podcast. So, Steve and Andrew, welcome to the podcast. How are you?

Steve Pereira:
Thanks so much for having us. Honor to be here and it's great fun.

Mark Graban:
Yeah. So we're going to have a great conversation here today. Let me do the part that's usually like the least favorite part of a guest's experience. I'm going to read bios, I'm going to let. We hate sitting through these. But Steve Pereira has spent over two decades improving the flow of work across organizations. He's worked through tech support, IT management, platform and infrastructure engineering, product management, and as a founding chief technology officer for an enterprise SaaS company. He serves as CEO of Visible Consulting, as COO of the Value Stream Management Consortium, as chair of the Oasis VSM Interoperability Technical Committee, and as co-founder of the Flow Collective to bring flow-focused professionals together. And since 2017, he's been developing and facilitating flow engineering. So Steve, again, welcome. Welcome to the podcast today.

Andrew Davis:
Thanks. Thanks very much. Honored to be here.

Mark Graban:
Was everything correct? Hopefully no mistakes in the bio there.

Andrew Davis:
Yeah, I mean, it's a lot of flow. It's a lot of value streams. That's the TLDR.

Mark Graban:
Yeah. Too long, didn't listen. Break it down here. And we're also joined by Andrew Davis, chief product officer at Autorabbit. Hopefully, it is free so far. It won't last too long, and that's okay. He is author of Mastering Salesforce, DevOps. He's a Salesforce architect, developer and product leader with a focus on the human side of software development. Andrew's been the leading figure in introducing DevOps concepts to the Salesforce world. Trained as an engineer, he spent 15 years as a Buddhist monk. Wow. Teaching meditation and personal transformation and helping develop communities of practice. These days, he studies the intersection of business, technology and psychology through systems thinking. So Andrew, again, welcome. Welcome back to the podcast.

Steve Pereira:
Thanks so much.

Mark Graban:
There's a particular kind of Zen perspective I get neurotic almost about making mistakes, but there's a certain level of teaching kind of in the realm of Buddhism. Can I ask you about that just as a quick indulgence?

Steve Pereira:
Sure. In terms of the relationship between making mistakes and, and learning and.

Mark Graban:
Yeah. Or the idea there are really no mistakes or.

Steve Pereira:
Sure, yeah. I mean, the. I mean, I'm wanting to. I think I'm so. My mind's now so entrained to the world of flow and so forth that I'm wanting to.

Mark Graban:
I didn't mean to throw you off. Sorry.

Steve Pereira:
Quote gold rat and so forth, as saying that in physics there are no mistakes, right? There's no such thing as a. Sorry. There's no problems in physics. No problem.

Andrew Davis:
The first thing I thought of, because.

Steve Pereira:
Everything in the world of physics is already perfectly balanced, right? There's something that's falling through the air at every moment. It's perfect exactly where it is because it's the convergence of all these forces. And so I would say the equivalent, like Buddha was a sort of foundational philosopher for our humanity. And I think the equivalent idea is that everything that's going on psychologically right now is perfect in the sense that it's a convergence of this sort of infinite, inconceivable variety of factors, right? That we're a product of biology, you know, our society at this moment in time, everything that's come before that, there's a cause or a reason for everything, including all of the problematic bits. But still, within this, we've got this attachment to everything being perfect, everything going, right. Especially. Especially us. We have attachment to being liked and being comfortable and these kinds of things. And that is extraordinarily problematic, right? Because, as you know, we're in a world where mistakes are happening continuously and the world is continuously diverging from the way we want it to be. We get everything just perfectly, and then all of a sudden it changes. And so from one point of view, it looks like our minds are just the most imperfect thing ever because we're out of touch with reality. We're wholly attached to some ideal that can't be achieved, but that even that is perfect in the sense that there's reasons why that happens and there's ways we can undo it. And I think one of the best ways is learning to be at peace with making mistakes. And so that's why I was so delighted with the thesis of your podcasts.

Mark Graban:
Yeah, well, the other podcast, my favorite mistake, and I hold a mug here. I drink water out of it. There's the logo, but the other side of the mug has my reminders to myself and mantras. And there would be different ways of stating these, but, you know, be kind to yourself. You know, there's at least one way that that's helpful to me, and I think sometimes helpful to others, where we're imperfect. And that includes, I mean, sometimes you hold business leaders to maybe too high of a standard, and there are reminders that we're all imperfect. So it started off, my curiosity gets the best of me. That started off very. We got very philosophical. Steve, what's that bringing?

Andrew Davis:
I just want to dive in because that was the gold rat was also the first thing that came to mind when you started mentioning that. The thing that always stuck in my head, I think, as most profound from Goldrat, it's not the theory of constraints. Washington. There are no conflicts in reality. Right. There's. That is very profound. And then you combine that with, I think it was deming who said that. Maybe it was Decker said that the system's perfectly engineered to produce the outcomes that it does. Those are very freeing concepts if you really take them to heart. They kind of give us permission to fail and to remove ourselves from, you know, the direct cause or let's say, contributors to faults and errors, because, you know, we're all really trying to do our best given the circumstances at any given moment.

Mark Graban:
Yeah. And, you know, I think of how this cascades into organizations. You know, I think, Andrew, it's thought provoking, what you say about, you know, things are meant, I want to paraphrase back, things are meant to be this way. Even. Even the problems and even bringing it back from society or societies. We can think in organizations. How do we balance acceptance or understanding how things have come to be while wanting to change or help organizations improve or even transform? That's a lofty goal, you know, thinking of, well, why. Why do some leaders blame individuals for systemic problems? Or why do some leaders set what seem like unrealistic goals for a development team and then hammer on people when they don't reach those goals? I mean, those. Those things are. There's. There's probably no single root cause to those conditions, right?

Steve Pereira:
I mean, there is a root cause in the sense of, you know, we all want to be free from the pain of things not going well as quickly as possible. And so the root cause is, if I can figure out that actually it kind of looks like it was Mark's fault, then that resolves the dilemma of me trying to figure out what to do, because I've got an answer, right? Oh, let's just play Mark. Right? And, oh, it's Mark again. Right. And then it's a very simple explanation for everybody, because everybody's like, yeah, Mark, yeah. And then it makes the world simple. So everybody, I think, craves a simple solution. Sure. The problem with systems especially these kinds of social systems you're talking about is that they are invisible. I mean, that's one of the biggest problems for them. They're totally invisible and they take place over time and they deal with all these, like, psychological factors in our minds, relationships between people, you know, patterns of behavior, technology, basically, there's so much involved, it's really hard to understand what's going on. It's a system of systems, right? So it's a mess by definition, in Acoff's terms. And so we crave simple solutions, and then, because we crave to be free from pain, if we can find a simple solution to a problem, we're like, yeah, that's it. So that would be my root cause analysis.

Mark Graban:
So we're going to have a chance to dive into, talk about the book flow engineering and some of the principles there not promising or clamoring for simple solutions. There's a lot of thoughtful things in the book. But before talking about the book, maybe the stories cascade into that a little bit. I like to hear origin story of why do people like Deming and Goldrat and Acoff and others resonate with you? Why do you get into these realms of improvement work regardless of how it's labeled? So, Steve, I'm going to ask you, maybe go first, tell your origin story before Andrew.

Steve Pereira:
Sure.

Andrew Davis:
I mean, if I tldr the origin story or TLdr and we have time.

Mark Graban:
So you don't have TL, doctor, then give us the longer version.

Andrew Davis:
Who wants the origin? Everybody just wants. What's the, what's next? What do I, how do I stamp this onto my organization? But the, you know, the origin story for me, if I'm, if I'm thinking about the macro of it, it's, I've always been a creature of inspiration and kind of bursts of energy and enthusiasm. Not a very systematic person, not process oriented. And Andrew's nodding his head because he knows that I'm just constantly distracted and.

Steve Pereira:
I fall into the same pattern, but.

Andrew Davis:
Anyway, and we're similar in that, you know, we've had many conversations about this, and I think that really motivates my fascination with systems and process and how people can kind of come together and dedicate their attention towards getting things done consistently with high quality without burning out and feeling like they're doing meaningful work. And I, and not working against each other, but working with each other. And that to me, is kind of this ideal that I hold in my mind of what a great life looks like is being able to work with others and create wonderful things. And I'm very averse to this idea of work as toil and struggling, rolling a boulder up a hill continuously, because I've experienced wonderful work and beautiful collaboration and inspiration that's shared amongst many people. And so I'm kind of just chasing that feeling and chasing, how do we build that, and how do we build it in a sustainable way? So it's not just these random sparks. So this is abstract, but it's really my first efforts into engineering flow come from building and releasing software all the way back to burning cds and really bad version control systems and running around trying to get people's merges to not conflict, you know, really long, painful meetings, incident response, where I took down production on a critical day, you know, the day before we had a giant customer release. And so it's a lot of struggle, a lot of pain, and a lot of avoiding that, or striving for this state of collective flow that I like to talk about. And, you know, between Andrew and I, we kind of, like, focus our attention in slightly different ways. I'm very much fascinated by this big, big picture of, like, how do you get an entire organization, this very mechanistic idea of, like, how do you make a machine of an entire organization? That's not mechanistic, but, you know, you kind of have a system of work that functions and allows everybody to contribute. And Andrew is my counterpart in kind of the individual. How do you get people into a state of flow and enable that personal experience of flow? So that's how we kind of try to avoid stepping on each other's toes, but also benefit from each other's different perspectives.

Mark Graban:
Yeah, yeah. And I think, Steve, you and I did, we first crossed paths at an agile conference in Winnipeg. Am I remembering that right? It was some time ago.

Andrew Davis:
I would love that to be our origin story, but I don't think I had the pleasure. No, I don't. I can't recall ever being in Winnipeg for an agile conference.

Mark Graban:
Okay, then that is my mistake, and that's be wonderful.

Andrew Davis:
I'd love for us to have a long, storied history.

Mark Graban:
Right.

Steve Pereira:
Like a romance, you know? You remember that agile conference in Winnipeg?

Andrew Davis:
Yeah, it was.

Mark Graban:
Well, I haven't gotten yet to the question of how you two ended up collaborating on the book, so that's a teaser. We'll come back to that, but no, I mean, I appreciate you wanting to talk more about aspirations than origins, is what I hear you say.

Andrew Davis:
Well, I feel, you know, humble origins, but, yeah, in service of, you know, how do we avoid friction and these, you know, these terrible feelings of failure and being part of a system that is working against us and moving towards a system where, you know, we can all contribute and be a part of something wonderful.

Mark Graban:
Yeah.

Andrew Davis:
Has really been the thread for me.

Mark Graban:
Yeah. So stepping back from origins for a second, when you talk about processors, I've learned to say in certain parts of Canada, process through the wringer on that one. I've had conversations. I mean, you know, I've attended some of these agile conferences. This is certainly not my domain, but as being somebody who I would describe myself as, well. I have a degree in industrial engineering, but you often think about process engineering and process design and process improvement. And to me, process, this has such positive connotations. More process generally helps us, but then there's this, it seems like backlash sometimes in software circles are like, people cringe and no process like process is the enemy. So to kind of try to frame it as a question, is that backlash because people have tried to make things too rigid in a way that that's actually kind of interfering instead of being helpful. I see you nodding your head, Steve.

Andrew Davis:
Well, I'm going to throw out an answer to that, and I'm going to throw to Andrew for his origin story. But, like, I think that what happens in software and product development is aversion to premature convergence and premature standardization. So what do we know about software? It's you're delivering change, you're not producing duplicate items, you're not manufacturing products, you're developing products. So that means that every focus is dedicated towards change. And process doesn't typically do too well in facilitating that and enabling it, at least in large organizations, which is where we see a lot of our opportunities. A lot of times, process gets implemented in response to mistakes, in response to breakdowns of communication and collaboration. It ends up being constraining a governing constraint rather than an enabling constraint. I don't know if this language is something that gets thrown around a lot in these circles, but if you think about things that help us do the right thing versus stop us from doing the wrong thing, I think the negative perception of process is this is just holding us back by restricting us from making mistakes that could be beneficial. Right. Sometimes you change things. There's a little, you know, issue, but you're actually on the way to something great. And so the more you constrain, the more you kind of restrict bad things from happening. That can restrict innovation, it can restrict collaboration and freedom and flow and all these things that we actually want.

Mark Graban:
Yeah, but I think there's a piece to that, the concern about premature standardization. So understandable if we, we need to be iterative if we're going to continue going through Deming's PDSA cycles. We don't want to stop those cycles. But then, you know, it seems like there's always this, or often this concern that process means permanent as opposed to continued PDSA cycles like, you know, process and then Kaizen strengthening and improving the process. It seems like if bigger organizations that don't have that Kaizen have it, I could see where some sort of thing, I understand the fear of things being locked in, and I think that wouldn't be the intent of a lane or a Toyota based or a deming based.

Steve Pereira:
System to defend process in defensive process. I would, you know, I'd love to, you know, obviously, if somebody listens to this and they've got a better insight than I can offer, you know, I'd love to reach out and tell me, but I think life looks very different if you're the industrial engineer, process engineer who's creating the systems that everybody else has to operate in versus if you're a worker be who's living in those processes, living in those systems. And so if you're, if, you know, as an industrial engineer and so forth, designing processes are beautiful because they're a creative act for you. You tune them and you optimize them and you make them work and so forth and so, but the experience of having a process that was created by somebody you don't know at some time, probably in the distant past, for reasons that may not be relevant to what you're facing right now, that's a very different experience. And I think that there is a, I think some of it is the transition into the digital world. I keep doing this with my hands. I don't know if it doesn't come.

Mark Graban:
Through in the audio, but.

Steve Pereira:
So in this transition from whatever pre digital organizations to digital organizations, obviously in digital organizations, things are happening at a much faster timescale. So where you've got processes that were designed to unfold over days, weeks, months, and the software developers are doing things that are designed to unfold over milliseconds and seconds and minutes. I do think as a software person, my brain was a little bit rewired on a faster timescale. Like, I've got a little bit of impatience, like, come on, do this, do this, do this. And so not as much patience for these long term project managery kinds of things that. And so I think that there can be a, there's kind of a generational rebellion from the digital generation to the pre digital generation. And then as well, I think the, you know, software development is fundamentally it's a creative act and it's very concentration intensive. And if you're dragged out of your flow, so to speak, your concentration and forced to go to a meeting you didn't really want to go to or fill out a form, you don't really understand the process or the context. You don't understand how that could possibly be beneficial for you or who it's helping and how it's helping. You're just lacking that context. That was a big topic that we did touch on in the book, this lack of clarity when you're operating in organizations at scale.

Mark Graban:
Yeah. And I think there's another trap that I think you touched on there of that separation between the process thinkers and the worker bees, the engineers. And I think one of the huge innovations within Toyota, looking at the factory as a model, which is probably not a great parallel to software development, I realize, but this idea is Toyota. People will say standardized work is created by the people doing the work. Now there may be input from engineers and supervisors, but it's really blurring or smashing that silo of, well, you're going to be involved in designing the process. You're certainly going to be involved in monitoring and improving the process. You know, I think that's, that's one thing that is really important to bring. I mean, it's helpful in a factory. But now we think of you bringing into healthcare organization where everyone's got a master's degree and an advanced degree, of course they want to be respected and involved and engaged that way. And I think the same would be true for people working in software.

Steve Pereira:
Yeah, certainly, certainly. And I think that there's also, you know, the, you know, it's bad process. It's process that's imposed from somebody else and that's what maybe a little bit of a bad name. And then as the sort of agile wave happened over the last 20 years, I think it's an energy, as an energy saving technique, we all try to learn the absolute least we have to about something to figure it out. And so like, I learned agile by being on a team of developers. And so I'm like, oh yeah, angel. Oh yeah, that's the thing where you do the daily stand ups, right? Yeah, yeah, okay, yeah, we do that. And so you've not really looked into, well, what's this sprint retro thing about again anyway, which is all about the team designing their own processes designing their own standard work. How did that work? What do we need to improve? And so there's a, there's a lack of, you know, people, developers in many cases have been, have, you know, they slot into the rhythms and the tactics and the methods of some of these practices, but haven't really understood the principles.

Mark Graban:
Yeah, I think there's risk of that or not having the foundations, as you touch on in the book, favorite practice of my concept and practice of mind, psychological safety. Like, you know, none of this works without that foundation. And I think Toyota people kind of take it for granted. I don't mean that as an insult, but, like, you know, if they have that environment and then they write and talk about, well, here are all the things that work really well at Toyota. You try to put those practices in an organization where people get punished for speaking up. Of course it fails. Steve, you were going to jump in.

Andrew Davis:
I think one thing we talk about psychological safety a lot, and the thing that I find is missing is intention. Well, let's say intentional design of psychological safety versus intention of psychological safety. We can talk about it and we can sort of make best efforts to kind of create it in our spaces. But how is it actually systematically implemented as part of the organization so that we know that if we do these things and if these things are true, then we have created psychological safety in a way that we can interrogate it. We know when it's failing. We have signals that tell us if it's going away or if it's being violated. You know, I think, I think we're missing that in a lot of places. We're talking about it now and we're sort of making efforts, but I think it's still kind of rare to have it be part of the DNA of or that, you know, as you say, the foundation of the organization. One other thing that I came to mind talking about process was, you know, that process is often kind of implemented moving forwards versus working forwards rather than working backwards. So sort of we encounter an issue, we find a flaw, we create an error in production, and then we create process to kind of avoid that rather than working backwards. From what kind of outcome are we trying to create? And then what mechanism will enable that outcome to be produced at scale and sustainably over time and not impact psychological safety or incur a undue cognitive load that is in a way that multiple people can contribute without stepping on each other's toes? That's very hard to do when you're working forwards because you're just reacting to, okay, well, this happens, so let's make sure it never happens again. And that's just this additive, and that's really taxing on people. Right. Because it's like, well, what's the process this week in response to the thing that happened last week and who's going back and saying, well, let's, knowing what we know, let's redesign the process to enable what we want rather than avoid all the things that we don't want.

Mark Graban:
Yeah, I mean, that one approach you described there, Steve, makes me think less of process and more of firefighting or workarounds. And that's a very common thing in healthcare. Layer reactive, double check workaround, firefighting on top of kind of a shaky process, and then that just adds a lot of burden and may or may not help with the underlying problem. Or even if it did, people can only work so many minutes in an hour, and you start piling these things on top that slow the work down. I think of John Grout, who's been a guest on this podcast a number of times, an expert on mistake proofing. He always points out the best. Mistake proofing doesn't slow you down. That's, I think, the ideal. And maybe some of these process things are slowing people down, and there's understandable conflict maybe caused by that.

Steve Pereira:
It's very interesting thinking about psychological safety as a foundation. I sort of went deep thinking about what you're saying there. I mean, I would say the whole of human history, we've been trying to figure out how to establish psychological safety in the sense of what are the rules or norms that allow a group of people to work peacefully and exist peacefully together. And the bigger societies have gotten, the more you've got whole new kinds of crises arising and so forth. So it just, you know, it's a very subtle thing, this whole idea. There's this asymmetry of trust, right? That it takes a long time to build trust, and it can be destroyed very, very quickly, right. And so there is a sort of a settling in period where you're getting to know another person, your manager, your coworkers, people on another team and so forth, where you don't immediately trust. And, you know, and maybe that's a not inappropriate, but there's a relaxing, like a deep kind of relaxing to where you get to the point where you can share your ideas and your insights openly. And I think Steve and I at some point asked about Steve and I writing the book together. And certainly one of my big experiences starting to work with him three and a half years ago was we just jammed. Right. And I just felt like I could share my wackiest ideas with him, like the ones that I wasn't, you know, I never quite articulated because they didn't quite seem like people would understand them or be open to them in the, in the, in the workplace. And so, and then when I did that, it was just this, this real creative, you know, cauldron, uh, you know, all kinds of ideas getting kicked up and, and, you know, and some of them he. Some of my wacky ideas he found more useful, maybe some less useful, whatever. But that's kind of a settling in. Right. And certain environments, it's like a team that works really well together. One of the points of psychological safety is that you can be honest with each other. And if I say, steve, I really think that's a terrible idea, I feel psychologically safe enough with him to say, actually, that was a really terrible idea. And so you've got some strength in the relationship that allows you to surface unpleasant facts, observations, hey, this really isn't working. So sorry, I messed that up.

Andrew Davis:
There's one other aspect to this that actually adds a really interesting dynamic in that we're collaborating where the ultimate goal is value delivery to a customer. And so psychological safety is in service of being able to say, I like that, but how does that serve our customer or our target outcome or what we're trying to do, and how do we leverage that and bring it into alignment with somebody else's sense of what they're hoping to do, what we want to enable their kind of context? And there's another piece about writing a book. You want to establish a sense of safety for the reader. We're not dumping a bunch of stuff on you and saying that if you don't understand this, you're way behind or you'll never really understand how to work effectively if you don't get these concepts. That was very, you know, that was a welcome challenge, and I think that that was very, a positive, very positive experience for me, was trying to place this target outcome outside of my own goals and say, what does it take to bring a reader to where I am with my mindset of how I look at work? And, you know, the things that I find important and what I've seen work well in organizations without dragging them along, inviting them, and enabling their kind of engagement with the material and these ideas, and how do we package it in a way that's accessible to them and inclusive and more invitation based than demanding or downloading information to them. So I really enjoyed that. And that reconciliation thought was very rewarding. You know, trying to, you know, work with Andrew as a counterpart and a colleague with different ideas, and then having this reader, you know, who represents all these different people, right. It's us in the past. We're trying to, like, you know, what would I tell myself ten years ago? And what do I tell that person who's just starting out? And what do I tell the person who's jaded and thinks about processes like this totally negative thing and all of those things kind of packaged up into this avatar that we're trying to serve?

Mark Graban:
Yeah, I mean, I think one of the interesting things about psychological safety and trust, interrelated concepts there is how situational it is. The two of you, Steve and Andrew, have worked together for years now. You collaborated on the book. You know, at some point, I, you know, that trust had to be built. Or maybe, you know, Andrew, you're, you tend to, maybe you tend to be a candid person, and you tested the waters with Steve, and he responded well, you know, to some of the candor. So you think, well, okay, well, may I give Steve more Candor and, or, you know, who, who's, who's inviting the candor? Who's receiving the candor? Well, as opposed to thinking of the three of us here, Steve and I have talked briefly. Andrew and I have never met. You know, Andrew, would you feel. Would you feel the same candor to say, hey, Mark, that was a really terrible question.

Andrew Davis:
Andrew would never say that. A question is terrible. First of all, it would never be so short sighted and offensive.

Steve Pereira:
I err on the side of being polite. That's fair. You know, I think some of it is situational, depending on the people. But then you build confidence, right? And that's the power. That's where there is a flywheel effect, right? Where you get comfortable working in an environment where you open, collaborative and so forth. You go to your next organization. You just set that expectation. Like, all right, listen, I'm just going to tell you directly. And so there is a kind of internal strength that we can build. And I think a lot of it is this sort of, you know, we're, you know, the counterpart of psychological safety is the fragility of our ego. Right? Like, how vulnerable do we feel? The less vulnerable you feel, the more safe you'll feel much more safe in most environments. And so, you know, everybody has environments that frighten them. Fear is the most fundamental reaction we can possibly have. So, you know, how's your psychological safety doing when you're in a pit of wild dogs.

Mark Graban:
Physical safety is a problem, then.

Steve Pereira:
So there's always a threshold that's beyond our capacity. But we build capacity as we build expectations of what it's like to interact with others and then become less and less self conscious, less and less. Whatever factors are conspiring to cause that fear internally, then bring your safety with you.

Andrew Davis:
So let me pick this up and kind of, you know, I'm thinking of the reader who's like, I thought this was a book about value streams. What are you guys talking about? So this actually is a pivotal requirement for, you know, that kind of underpins flow engineering as an effort, because the hardest thing that you'll encounter when you try to work with a group of people to map out the flow of their work is this sense that people feel personally scrutinized and criticized by this effort, unless it's properly framed in the context of, we're looking at the system, we're looking at the team level, not the individual level. We're not looking at what people are individually doing. We want to understand the overall flow of work. And for us to do that, we need people's direct experience of that work, and we need the truth from people about how long it takes to do things, what's involved, who hands work to who? What happens? Does it pile up? Does it flow right through? Does it get stuck? Is it reworked eight times? Because there's some kind of missing requirement that never makes it into the definition of the work that needs to be done. Are we testing and retesting? Are we throwing things over walls to people who don't have all the context? To really understand the flow of work, you have to have this level of visibility and insight that requires psychological safety. It requires people to show up and say, here's what I see. You might see something different, and that's a reason why we get a variety of stakeholders involved, but we don't want somebody off in the corner saying, this is a waste of time. Or if I speak up, this is just going to come down on me. And, you know, I don't want to invite an argument about this or, you know, we disagree, but it's not worth me voicing my opinion, because we'll be here forever while we try to battle this out. All of those things work against the. The efforts of flow engineering. So it's very important for us to have that. And that's been my biggest learning as a facilitator, is how do we build that rapidly? Because our whole thing in flow engineering is, you know, we're saying, we can do this quickly, we can do this quicker than you think.

Mark Graban:
Yeah.

Andrew Davis:
And so, you know, you've got to drop into that state of productive collaboration very quickly because it's, you know, it's an absolute requirement.

Steve Pereira:
Yeah.

Mark Graban:
So you talk about value stream mapping, visualizing work, making the invisible visible. Like this happens a lot in healthcare. It's not just a strictly observable physical process like you might see in manufacturing. People have to feel safe to be candid, to say things like, as you're mapping out the work and someone said, you know what, that's not how I do it. I do it differently. If they fear, like, they're going to get in trouble for admitting that, they're going to keep that to themselves and just let the mapping exercise march along, but then the organization doesn't have the opportunity to evaluate, maybe that person's way of doing the work is better.

Steve Pereira:
Right.

Mark Graban:
So we can not just visualize the work, but help improve the work. That's where it seems like psychological safety then, is a foundation for doing what you're writing about and why you booked a.

Andrew Davis:
And that aspect that you highlighted, Andrew, about. It's very difficult to build trust, very easy to lose it. If you lose people along this process. Really, the early stages of flow engineering in any continuous improvement effort is you're in the negative by stepping away from the work, you're just assessing, you're collecting information. This is not necessarily contributing to value until you get to the point where, okay, well, what do we do about all this stuff that we found? Where are the Kaizen improvement opportunities? Where are those? How do we redesign the flow to be better? And so if you lose people early, you're not going to benefit from their perspective and their contribution and their expertise when it comes time to actually produce why we're there in the first place, which is to re engineer the system to create a better flow and to actually get better outcomes.

Steve Pereira:
There was the point that Mark started off with about there are no problems in reality, something like that. What we're doing, however we want to frame it, but what we're doing is we're dealing with a system that's continuously imperfect, it's continuously changing, we're continuously forgetting or making mistakes. The process is always unfolding, and so it's in a state of perpetual imperfection. And so that means that we never quite know are we doing things right or not. There's always this uncertainty, and that creates some pain. And normally, when we have any kind of pain, mentally, we freak out, right? It's like, and so the sense of psychological safety extends to even feeling safe, even when there's pain arising in the mind, you know, feeling safe even when, you know, I don't know what I'm doing or I'm making a mistake or I got criticized or something like that. And then that a very deep level of psychological safety that you're like, the system's imperfect, but we're going to work one now. I've seen the whole system. I've seen how it fits it all together and it's a complete mess and it's a disaster and the performance is super low, and that's perfectly fine. And let's go forward. Let's work on it. That's level of psychological safety.

Mark Graban:
Yeah. Something to be said for accepting the current reality. You know, I think of, you know, Toyota people, former Toyota people I've worked with, of just trying to accept, here's how it is. Let's, let's avoid the game, the, the blame game. Let's, let's just accept it for what it is. And now let's think forward about how are we going to improve the system. Like, there's a certain amount of emotional intelligence required for that because it's easy to, you know, just react in a way of, you know, getting upset about or people feeling a sense of shame. That's actually, I think, the more common dynamic, even when there's no external fear, people in healthcare I've seen get very upset. And it's really, I think, more internally driven, the sense of shame of like, oh, my gosh, our system is really screwed up and we've, we all care a lot. We all, we've all been trying hard, but look how, you know, I have to kind of work through the cycles in a way I don't feel qualified to help as an engineer. Like you need more of a counselor mindset, you know? And I think, I think that's, that's just, you know, I got sidetracked there. But even when it's not externally driven fear, there's an interesting psychology of why people feel so bad about the current state and recent past that it becomes a barrier to moving forward.

Steve Pereira:
It's one of the reasons we chose this term flow engineering, because it does have this sort of double meaning of team workflow, but as well, sense of psychological flow. It deals with the process, but as well, it deals with the psychology of the individuals. And so I feel like that's, that's somebody else's job to deal with the psychology of shame. And so forth. But there's a sense in which if we really want to master flow in ourselves or in an organization, then we've got to start getting into these levels that there's an engineering of sorts that we can do even, you know, how do you undo, you know, like Steve said, what's, you know, how do you approach building a sense of psychological safety? How do you help people to deal with a sense of shame like it is? It is that very sense of shame that makes them such a major healthcare workers because they care about patients. They want to do a good job. They absolutely never want to hurt anybody. You know, that is the most precious thing that's driving that organization is that sense. You know, I want to be a good person. I want to help. I never want to cause any harm. And then, so at some point, you know, if you care enough, you pull the threads. You have to go beyond whatever it is, the code base or the patients chart, you know, and you have to get into these realms of psychology and sociology to try to figure out how you can engineer a better, better workplace for yourself and for everybody else around you.

Mark Graban:
Yeah, well, so we've been talking today with Steve Pereira and Andrew Davis. Their book is flow engineering, from value stream mapping to effective action. I wanted to ask one other question. Whether or not you want to talk about some of the origin of how you met, how you started working together on the book. Maybe a better question is did you have an opportunity to apply flow engineering concepts to the development and the writing of the book together? Imagine you're doing it remotely, collaboratively. I think of a book as being like software, you know, kind of an iterative product development process. And do you treat it like a startup? I guess I'm asking like, okay, how much did you get to eat your own dog food, as they say, or what opportunities would there be writing another book?

Steve Pereira:
I'd say the first iteration of any flow is always going to be. You'll always think, oh, we could have gotten that done a lot faster. I mean, I joke it took us three and a half years to write a book about fast delivery. Right?

Mark Graban:
Yeah, that's okay.

Andrew Davis:
Yeah, I mean, it gets manifested in many different ways along the road to the book. Like, we initially wrote very different book. I think we've written the book three times. You know, our first stab at it was very much, let's divide and conquer, and we'll have two parts of the book. You write the first part, I'll write the second part. We'll work in parallel. This will be super efficient. We won't step on each other's toes. Delivered that book. And our publisher, of course, said you wrote two books.

Steve Pereira:
Yeah.

Andrew Davis:
This is not one book. And that is a lesson in collaborative flow and thinking about the entire end to end value stream. You know, these handoffs don't work. Delivering things in silos doesn't work. This trying to reconcile things late in the process doesn't work. We've learned all those things, and we continue to relearn all the time because these are, you know, these are ideals. These are things that we strive for. These are things that don't necessarily come naturally to, certainly to us. And we just maybe why we're, you know, we're really interested in this stuff. And, you know, I think that's really valuable because trying to teach someone something that comes naturally to you, I think, is extremely challenging. But as someone who has learned this right and had to kind of learn this the hard way, you know, that's, that gives me the confidence to, to be able to say that we've got something that other people could learn from, that people can sort of adopt and pour it into their own experience, because this is not just us kind of surfing on our good fortunes.

Mark Graban:
Yeah. And, you know, there's no shame or it's not that unusual what you described there of, you know, again, the book being an iterative process, sometimes the iterative cycle is okay, whole book. And you're not the only ones who, you know, kind of started over or made significant changes. I have a author friend of mine who's more of a journalist background, so he's really a writer's writer. And, you know, he says if you publish the book, you thought you set out, you were setting out to write, then something went wrong. Like, it's very natural and normal for things to evolve. But like you said, maybe there are lessons to be learned about how to iterate in smaller batches or smaller, quicker cycles.

Andrew Davis:
I guess there's definitely, I mean, a couple of key things that I thought were very helpful. Like, first of all, we very consciously started with beginning with the end in mind, thinking about what do we want to deliver to the reader, what do we want to kind of give them, and where do we want them to be by the time they finish the book? And then sort of think about laddering to that or building a staircase to that with the book. And that was very helpful. And then, you know, of course, we had regular working sessions. I think, you know, we really lost momentum when we lost a regular cadence of working in small batches so, yeah, I mean, I could go on. There's just. There's so much that really would. Would be extremely helpful to this because it is knowledge work. Right. It's the same type of work that we're struggling with in all these different contexts.

Mark Graban:
Well, maybe we could do another episode someday diving into that topic. Or as I get more into your book, where you write some sort of article or something, how to write a book using flow engineering. I might have some ideas, or we can. We can put our heads together and think, because, you know, different authors always, or people who want to write a book ask for tips and thoughts and advice. And I have some experiences. That doesn't mean I have it all figured out, but, yeah, I mean, how do we deliver, especially collaborative work? You know, I did a book with a co author, and it was a great experience. Joe Schwartz and I did our book, Healthcare Kaizen. I don't think I ever had a hypothesis that having a co author meant the book was going to be half the work, because it certainly. It certainly was not half the work, or it would only be half the work if we did it the way you tried. First, if you write that half, I'll write that half. And, yeah, it was maybe almost the same amount of work, but the book was certainly better. It was much, much better than it would have been if I had tried writing it alone. I'm sure the same is true with your collaboration.

Andrew Davis:
Undoubtedly. Yeah.

Steve Pereira:
I revisited recently, Steve and I, from the very beginning, even the COVID of the book, we've got post it notes decorating the book, and it's post it notes throughout the whole book. And from the very beginning, he and I were doing it on a digital whiteboard, and I revisited that recently. From November of 2020 into the pandemic, we connected at the DevOps Enterprise Summit, now, the Enterprise Technology Leadership summit, the digital version. And, you know, the original ideas that we set forth on what we wanted to accomplish in the book are basically what we ended up with. Now, we took a very long, circuitous route in there, but I would say, I know my thinking has evolved dramatically. Like, in that very long, circuitous path, I have come to understand the world in a dramatically different way. I feel like that was kind of my. I did a tremendous amount of thinking about how all this stuff fits together, and the vast majority of my thinking and my writing was not published in the book, but it's like. So I've changed, my understandings evolved, and I'm looking forward to other opportunities to share.

Mark Graban:
Yeah, I forget who this would be attributed to. But the idea of the great way, a great way to deepen your knowledge of a subject is to start writing a book about something you feel like you know a little bit about. And in that process, you end up understanding it even better. To your point, Steve, how do you articulate it to others? That's knowing how to do something and knowing how to teach it or communicate it are, you know, related but different.

Andrew Davis:
I think that, you know, that the level of understanding that you gain from trying to teach something is unparalleled. And one of the hacks that I fortunately stumbled into early in my, early in my career was signing up to speak at events about topics that, you know, I really, I felt interested in and I felt passionate about, but I didn't feel like an expert in any sense. And I would, you know, if I could pitch this and it gets accepted, that's enough motivation for me to get it into shape such and deliver it such that I do not embarrass myself and, you know, make everyone's experience at this event, you know, horrible. And that, I felt was a, you know, a super hack. You know, something that, that obligation, the deadline, all those things really worked to help me, you know, get my thinking straight, get the ideas in a state that I could present them effectively. And that's really effective.

Mark Graban:
Yeah.

Steve Pereira:
Then you really start working backwards. You're like, okay, if you combine that with procrastination, you're golden. Right. Okay, presentation is tomorrow. I need to be on. All right, how do we do this?

Mark Graban:
Yeah, that's why conferences always want you to send the slides two months in advance. They're guarding against the procrastination. Yeah, here's some slides. This is absolutely not what I'll be presenting, but here's some slides. Because, I mean, if I haven't learned anything in the last two months that would make my presentation better, I'm doing a terrible job. Well, this has been fun. I've enjoyed talking with our guests again, Steve Pereira, Andrew Davis. The book is flow engineering, from value stream mapping to effective action. The show notes will have links to websites and the book and more. Anything else that either of you would like to say? Give kind of a wrap up, final word. That's like the worst, most open ended question. But anything else you'd like to say here, as we.

Andrew Davis:
Well, luckily, you know, we don't like to talk too much, so it'll be quick. But no, this has been a wonderful privilege. You know, we, as aspiring podcasters and content creators, we really admire what you've done with this series and your other series, you know, your other series alone has reached a level of consistency that truly establishes trust. And I admire that a lot. So thank you personally for me.

Mark Graban:
I appreciate that. Thank you. I wasn't trying to. I'm going to start asking that question in a way that doesn't make it sound like I'm fishing for a compliment.

Andrew Davis:
Oh, I didn't take it that way at all.

Mark Graban:
No, no, no. I should have been more gracious about that instead of self effacing. Thank you. Thank you for saying that, Steve. Andrew, I'll give you the last word.

Steve Pereira:
Well, anyway, also delighted to be here and really happy to have a chance to share these ideas. And hopefully this gives technologists who are listening a much broader sense of the world and the lean people who are listening a sense that their messages resonating into the tech community. And even though the tech community is operating orders of magnitude faster than some of these other in real life processes, the same principles apply.

Mark Graban:
Yeah, the book makes that very clear. So thank you for that work there. But Steve.

Andrew Davis:
Yeah, sorry, I forgot about this, but I would love to hear from folks in your neck of the woods in healthcare. If anybody is putting these practices to work and learning and finding gaps or things that we haven't spoken about or things that are unclear in their context, I'd love to hear from them on LinkedIn or through email in any way possible, because we really see this type of work applying in any kind of collaborative environment. Love to see it tested in contexts like healthcare. That's wonderful.

Mark Graban:
Yeah. Well, good. I hope some people will reach out. So, Steve, Andrew, thanks again. Really appreciate you being here.

Andrew Davis:
Thank you. Lots of fun.

---

What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.

Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.

---

Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation: