Software Dojo: Learning That Sticks

Joining me for Episode #351 of the podcast are my friends Joel Tosi and Dion Stewart, co-founders of the company Dojo & Co.

They're the authors of the new book (to be released on November 19) called Creating Your Dojo: Upskill Your Organization for Digital Evolution.

A “dojo” is a learning environment — whether that's for the martial arts or if it's a “safety dojo” in a Toyota factory. Today, we talk about what it means to create an “immersive learning environment” in a workplace, such as a software company or a product development group within a larger company — the goal is more effective learning, progress, and adoption of new methods or products. It's interesting to think about how one might use a “dojo” in the context of Lean design or improvement efforts in a hopsital or other settings.

Joel, Dion, and I have collaborated before on a few events, including our Learning Symposium where we visited Toyota and Garrison Brothers Distillery last year.

Streaming Player:

For earlier episodes of my podcast, visit the main Podcast page, which includes information on how to subscribe via RSS, through Android apps, or via Apple Podcasts. You can also subscribe and listen via Stitcher or Spotify.

New! Subscribe and listen with Spotify:

Questions, Topics, and Links:

When developers become coaches or managers, do they keep coding?
Parallels in healthcare and manufacturing: leaders who no longer know how the work is done today
A quick history of software methods: Extreme Programming (XP), Scrum, product thinking, and DevOps
- Building quality in earlier in the process, instead of testing or inspecting it in
- Getting closer to the customer
- Measuring how fast teams go vs. whether they're going in the right direction
Mary and Tom Poppendieck and Lean software development
- Test-first development as a way of building quality in
- Seeing the entire value stream, not just the coding in the middle
“Everybody optimizes the queue, they don't optimize the flow”
Agile vs. Scrum, and why not to get lost in the vocabulary
How Joel and Dion met through the late David Hussman
The first dojo at Target, and why learning in a silo didn't stick
What is a dojo?
- 6 weeks, full time
- The team's real product work, not made-up exercises
- Teams define their own learning goals and what success means
Example: engineers who built a platform for three years that nobody uses
Why six weeks? What happens when it's shorter or longer?
Learning over delivery: repetitive practice vs. one-time training
“It doesn't matter what this team produces, as long as they produce it on time”
When organizational incentives and measures work against learning
Go slow to go fast: Toyota plant ramp-ups and cloud migrations
Could you set up a dojo for creating a dojo? “Coaching the coaches”
The book: Creating Your Dojo: Upskill Your Organization for Digital Evolution
- Who is it for, and could hospitals use this approach?
- Why “evolution” instead of “transformation”
Their website

Thanks for listening!

Episode Transcript

Introduction

Mark Graban: Hi, this is Mark Graban. Welcome to episode 351 of the podcast. It is November 11th, 2019, and joining me today are my friends Joel Tosi and Dion Stewart. They're co-founders of the company Dojo and Company. They're the authors of the new book, being released on November 19th, titled Creating Your Dojo: Upskill Your Organization for Digital Evolution.

A dojo is a learning environment, whether that's for the martial arts or what they call, for example, a safety dojo in a Toyota factory. So today, we're talking about what it means to create, as they call it, an immersive learning environment in a workplace, such as a software company or a product development group within a larger company. The goal is more effective learning, progress, and adoption of new methods or products. We'll talk about this a little bit, but it's kind of an open question: how might one use a dojo in the context of Lean design or improvement efforts in a hospital or other settings?

Joel, Dion, and I have collaborated before on a few events. They've had me come speak at an Agile conference and at one of their Dojo Consortium events, and we also collaborated on hosting a learning symposium in Texas last year, where we visited Toyota and Garrison Brothers Distillery. We had a lot of great discussion with the people who came from around the country to take part in that.

If you want to see links to their book, the interesting work they're doing, and everything we talk about here, you can go to leanblog.org/351.

Well, hey, Joel and Dion. It's great to have you here on the podcast. How's it going?

Joel Tosi: Going well, Mark. Thanks for having us.

Dion Stewart: Yeah. Good morning, Mark. Good to talk to you again.

Mark Graban: We've collaborated on some things and had a lot of chances to talk in person, and I'm really glad that we can now do the podcast, share a little bit about your work and your book, and explore this idea of dojos and how it might apply even outside the realm of software.

But before we get into all of that, I always like to let guests introduce themselves. Tell us about your professional backgrounds and what you do, and then after that we'll talk about how you two started working together and about your company. Joel, if you can go first.

Joel Tosi's Background

Joel Tosi: Sure. My name's Joel Tosi. I was born and raised in Chicago and live there now. I started off early in my career as a software engineer building trading systems for the Chicago Mercantile Exchange. I did that for a while. Then in the early 2000s, I was an architect at the time, and my executive director was asking me to figure out why we were doing a lot of things in duplicate. He wanted me to create a better system so we didn't have to duplicate work.

It was around that time I started getting exposed to some of these, quote unquote, “Agile practices” and XP practices. But software aside, I'm sure you can imagine that the problem wasn't that we needed a better system. The problem was really that nobody ever talked to each other. Nobody knew who was doing what or why, and that's why we got all this duplicated effort.

So I did that for a while, then I started going into the space of helping teams. At first it was helping teams just learn to talk better. Over the years, I went through various roles in software, and around the time I started meeting Dion, I landed in a space where it was less about technology and software, and less about process, and more about people creating interesting products. That's kind of where we're at today.

Technology is fun, writing code is fun, but sometimes the best thing is when you get to see people get excited about making other people happy and making other people excited about using their products. That's where I'm at today.

Mark Graban: When you talk about Agile and XP, we'll come back and ask you guys to define some of that, because I think a lot of our listeners might not be from a software background. But it's interesting you talk about communication challenges. That's so true in a lot of settings where we have process issues. It's not the technical issues, it's the social issues that trip us up so often, right?

Joel Tosi: Yeah, exactly.

Mark Graban: So we'll talk more about that today. Dion, if you can introduce yourself, please.

Dion Stewart's Background

Dion Stewart: Hi, I'm Dion Stewart. Like Joel, I have a background as a developer. It's been a while now, but a few decades ago I was doing programming and development in a language called Smalltalk. It wasn't a real popular or common language. It was a bit of a niche language.

But there were practices that the community of developers using that language were doing, and those eventually got codified into a methodology called Extreme Programming that Kent Beck created. He was sort of a luminary in the Smalltalk community. I know we'll talk about Agile and some of these other things as we go forward, but for right now, the set of practices I learned doing Smalltalk became part of this Agile style of development.

In the early 2000s, in addition to programming and doing product development, I was also put in roles where I was asked to help other people learn how to do some of these practices. I moved into this developer/coach role, sort of a player-coach kind of thing. Somewhere around the end of that first decade of the 2000s, I moved into full-time coaching.

For the last 10 years I've been coaching teams, and coaching at a higher level than teams, eventually in some organizations up to the C-suite, helping organizations go through change initiatives. Ultimately that's led to this thing called the dojo that Joel and I are doing now.

Do Coaches Still Code?

Mark Graban: It's interesting you talk about being a coach or a player-coach. What happens in software development career paths when someone moves from being an engineer, a coder, a developer into some sort of management function? Do people generally stop coding? What's typical?

Dion Stewart: That's an interesting question these days, because “stop coding” implies that you coded at one point. Fifteen or 20 years ago, anyone I knew who called themselves a coach had a background in coding. There were a lot of technical practices that were part of Extreme Programming, and everyone who called themselves a coach knew those technical practices and had a coding background.

I didn't set out to call myself a coach. The consulting firm I was working for at the time threw that title on me and started billing me out that way. At the time, there was an advantage in doing that. Now, there are a lot of people who call themselves Agile coaches or Lean coaches who don't have any kind of technical background whatsoever.

I think there's good and bad there. I've met people without technical backgrounds who are really, really good coaches. They understand the people, the collaborative side, the process side, and the really good ones understand the product development side: how to do product discovery, really get inside the heads of customers, and develop new customers in markets where it's a whole new product and there isn't a customer base yet.

I don't know if I can answer the question about moving from an engineering role into a coaching role for the whole industry. For me, it was a weird, gradual transition. It started off with me not having any general coaching skills, just, “Well, I know how to do this practice. Let me show you.” At a certain point I realized, if this is going to be my role, I probably need to start studying coaching and leading and how to teach people, all of the general coaching skills that a lot of really good coaches have.

Leaders Who Understand the Work

Mark Graban: So what I hear you saying is that the answer to my question varies. It depends. There are pros and cons. I think of the healthcare realm, where people tend to move up from frontline professional work into management. A nurse becomes a nurse manager, then might get promoted to director, and however far up they go, they generally stop the practice of bedside nursing.

As time goes on, there's a risk that these leaders know how the work used to be done, but technology and practices in medicine change, sort of like software languages and development practices change, right?

Dion Stewart: Right. I don't think I answered your question directly about whether I still code.

Mark Graban: That's right.

Dion Stewart: I do. Last night on the plane home from a client site, I was doing a little bit of work in F#, which is a newer programming language, trying to learn how to apply some techniques from a method called domain-driven design in that language. As much as I can, I stay as close to the tech as I can. There's still a difference between coding eight hours a day and the amount of time I'm able to spend coding. But for me as a coach, it's important to keep my technical chops up.

Mark Graban: I can see where that would be important, and it's a thought starter for parallels to other industries. When I was at General Motors, in manufacturing, supervisors and managers were generally hired in as such. There was a split between the hourly workers and the salaried workers. The salaried workers generally had a college education, and they had skills and knowledge, but some of them were better than others at understanding the frontline perspective, since they had never done that work and weren't allowed to do that work because of union rules, for example.

Toyota tends to have people progress from team member to team leader. They don't have the union constraints. I can see where there's real value in understanding the work, and that helps you understand the people doing that work, right?

Dion Stewart: Yeah.

From Extreme Programming to Scrum to DevOps

Mark Graban: Before we talk about Dojo and Company and the book, I think this might be helpful background. Some people who know all this may want to hit fast-forward 30 seconds at a time. But if you guys can give the elevator pitch overview for those of us, me included, who don't really understand software. Does it make sense to start with XP, or Extreme Programming, as you both mentioned, then Agile, then DevOps? Or is there a historical order that makes sense? What do you guys think?

Joel Tosi: I think the historical order might make a lot of sense. Is that cool, Dion?

Dion Stewart: Yeah. Why don't you go through that?

Joel Tosi: Going back to the '90s, there was always the in-swell of technology. Back then, the challenge was how do we take these big deliverables, these big initiatives that we want to deliver over the course of a year, and get some level of transparency into how we're going about delivering them?

In the '90s, especially in software, it was really hard to figure out until the very end of a project if you were going to be on time. Historically, everything was always on track. You're at 80% of your time, you're 80% done, but it turns out that last 20% took a lot more than 20% of your time. You'd be integrating code, you'd actually be doing real testing. So back then, the challenge was how do we get transparency into whether we're delivering projects on time?

So some practices like the ones Dion mentioned, XP, started popping up. XP did some things around trying to make quality come sooner in the process and trying to give more transparency. It also did some nice things that I think people forgot about, around trying to get closer to the customer. That was the intent early on in the XP space: thinking about the project timeline and how we know if we're doing well on the project.

What happened then in the early 2000s is it became a process space. As Dion mentioned earlier, things started to become codified, and as soon as they were codified, they started to be sold. People would sell certifications showing you knew the process. You lost the idea of whether things were on time, and it all became about the process.

To your point, Mark, all these bad metrics would come up. All of a sudden, people were tracking how fast a team was going, and they weren't really thinking about whether they were going in the right direction. It was always, “Man, they're going really fast somewhere. We don't know if they're going to run into a wall or go off a cliff, but they're going fast, and if I'm their manager, I want to know how they can go faster.” So the early 2000s became about process and even certification.

That's where some of these ideas around Scrum come in, if you've heard about Scrum. Scrum is focused on a process and almost a management aspect of the process. Moving forward, people realized it's not just about going fast, it's about doing the right thing.

Then I think two things started happening. People started asking, “How do we learn about our customers better? How do we deliver better products sooner?” So design thinking and product thinking started coming into the Agile space. At the same time, maybe 2010-ish, people started asking, “What's slowing us down from learning about our customers?” For a lot of places, it was the ability to create infrastructure to support the software: getting servers ready, getting networks ready. Those things started to become the constraints.

This is where the DevOps movement came in. It was all about how we make it easier for developers to deploy products so that somebody could learn about products. It was about automating the right side of the value stream, if you think about it, the operational runtime side.

So XP was really about getting transparency into our projects and a better idea of whether they're on time. Scrum codified a process and more of a management view of the world. Around the late 2000s, it became heavier on product thinking: are we building the right thing? Then DevOps came in and said, “Let's create stable systems so people can experiment and learn better.” Maybe that makes sense. Dion, could you synthesize it better if I did a bad job?

Lean Software Development and the Whole Value Stream

Mark Graban: Before I ask a follow-up, there are some common Lean themes that you mentioned, Joel, of trying to build in quality earlier in the process instead of, I guess the software equivalent of inspection is testing, right? And getting closer to the customer. That's a good goal.

Joel Tosi: Yeah.

Dion Stewart: Yeah, exactly. Another important thing to mention here is that probably 16 or 17 years ago, Mary and Tom Poppendieck started writing about Lean software development. Mary had worked at 3M as a programmer for a while, and at a certain point she was in a leadership role in their videotape division, which tells you how long ago it was. She tells stories about how they converted to a Lean manufacturing process over a weekend at one point, because they were getting clobbered in the marketplace by their competitors. By doing that, they had all the benefits you might imagine: reduced cycle time, improved quality, et cetera.

I was lucky enough to meet her a long time ago when I was living in Minneapolis, and there are a lot of principles from Lean that she got many of us thinking about in terms of software delivery. The idea that you can't inspect quality in by doing testing at the very end ties back very much to Extreme Programming. Kent Beck is the creator of the automated unit testing framework for code that originally came out in Smalltalk and has since been ported or copied to just about every programming language on the planet.

The idea with that framework is that you write the tests first. You think about what the code needs to do, you think about how you're going to prove that the quality's there, and you create those tests before you write any code. It was the complete opposite of inspecting quality in at the end. It was building it in, literally.

Other ideas that Mary and Tom exposed the rest of the world to were things like eliminating waste. There are the seven classic forms of waste in Lean, and they talked about how those translate to various aspects of software development. But I think the even bigger thing, sort of the punchline with them, is they were the first ones, at least in my world, who got me and a group of other people in Minneapolis thinking about the entire value stream for developing software products.

Prior to my introduction to them, the world for most software developers started with a project kickoff meeting. A lot of work had already been done. ROI decisions had been made. You weren't part of any of that. You did your work, and your work was done when the artifacts you created were checked in to a repository or somewhere on a file system that other people would then deploy, as Joel was mentioning, putting things on servers and into production. As a developer, your view of the value stream was very narrow. It was the segment in the middle. Mary's really the one who first got us thinking about the entire thing.

DevOps, to a large extent, is an extension of that, like Joel mentioned, on the right side of the value stream. Let's talk about everything that happens after you commit code, all the way up until the product is in the customer's hands and they're getting value from it, and let's optimize that part of the value stream.

This is maybe looking ahead a little bit, but part of what we're doing in the dojo is trying to help organizations reconceive their ideas of what a team is. It's not just coders, and maybe not even just coders and testers. It's everyone who has something to do along that entire product development value stream. Let's figure out how to connect those people so they can collaborate effectively and really align around product delivery by thinking about and working on the entire value stream. As opposed to: here are some people who do work up front, they define a project, then we staff that project with a totally different group of people and hand things over the wall to them, and they do their work and hand things over the wall to a different group who does operations.

Optimizing Flow, Not Queues

Mark Graban: So part of all of this is trying to connect different functions into a better value stream. Is that another way of putting it?

Joel Tosi: I think the functions already exist. They just tend to not exist together. Everybody optimizes the queue, they don't optimize the flow.

Mark Graban: And so you're trying to break down those silos through the product development process.

Joel Tosi: Yeah, yeah.

Mark Graban: One other question, or people can go research these different terms. To me, it's still a bit of a jumble. For example, the difference between Agile and Scrum. Is Scrum a subset of practices within Agile, or is that not the case?

Joel Tosi: It tends to be that Agile's the big umbrella, and Scrum's a piece of it. But I think the question's even more interesting than that, Mark. A lot of places we go, people ask us, “How do we do Agile? How do we do this?” And what Dion and I tell a lot of groups is that we shouldn't focus on the words, because as soon as we focus on the words, we've lost the meaning. Wasn't it a Taiichi Ohno thing? He didn't want to call it Lean, because he didn't want people to worry about doing Lean.

Mark Graban: Well, he didn't want to codify things.

Joel Tosi: Exactly. It's the same thing. By all means, your listeners can look it up. We just shouldn't get lost in the vernacular of it all. That's what we want people to get out of it.

Mark Graban: It seems like the goal is how to have a better product development process, how to have a more effective company. It's not about the details of how the coding is done per se, right?

Joel Tosi: Exactly.

How Dojo and Company Started

Mark Graban: You shared a little bit about your backgrounds. Before we talk about the book, Creating Your Dojo, how did you start working together and create your company, Dojo and Company? Or do you say Dojo and Co.?

Joel Tosi: I want to hear Dion's story, because, well, partially I don't remember how I met you, Dion. So let me hear your story on how we met.

Dion Stewart: I think it's pretty simple. I was working with a guy in Minneapolis named David Hussman, who was pretty well known in the Agile community for years. Sadly, we lost him a year or so ago. I was coaching with him, and as I remember it, Joel, he had already worked with you at the Merc in Chicago, but I hadn't met you yet. Then we got to a point where we needed more people to coach with us, and he brought you on. I think the first time I met you in person was when we were both at a client down in Orlando. From that point on, we were at conferences together, at various clients, meetings with David, things like that.

Joel Tosi: All right, I'll go with that story.

Dion Stewart: So, picking up from there, Joel and I were working with David, not on too many clients together, but Target was the first company that started one of these dojo environments. They're headquartered in Minneapolis, where David's company was headquartered, and Joel and I both started working with them.

Initially Joel was inside the dojo and I was outside the dojo, doing other workshops and working with leadership, helping them understand Agile and Lean principles applied to software development. Eventually I got pulled inside the dojo, and we coached there together. We moved on to a second company that wanted to start one of these immersive learning environments that we call dojos, and we both coached there for a couple of years. While we were there is when David got sick, and we said, “We might want to start looking at doing something on our own.”

We put up the Dojo & Co. website initially just to see where this whole dojo thing would go. As it turns out, there are many companies now that are implementing or are interested in implementing these kinds of immersive learning environments. Last count, the line of sight we had was over 30 companies doing them.

So the initial idea was just to keep us working, to help each other stay billable, so to speak. On the other hand, we've both been coaching for a really long time, over 15 years apiece, and we've had conversations about this many times. For both of us, this dojo model seems to be the most effective form our coaching has taken in terms of really having an impact in organizations, and really getting to a point where the learning that's happening with the teams we work with sticks. They're able to carry it forward.

We'll revisit and follow up with teams months after they've been through one of these dojo experiences, and they're still able to apply a lot of the practices we worked on with them, and in many cases they've adopted new practices. Part of what we're trying to help teams learn in the dojo is this approach of continuous improvement and this learning mindset. Success is really when a team not only learns things in the dojo but adopts this style of continuous improvement, and it just becomes part of the way they work going forward.

What Is a Dojo?

Mark Graban: You've given the high level: a dojo is an immersive learning environment, as you call it. But I wonder if you could go into a little more detail about what a dojo is. I think of the movie The Karate Kid, the karate training dojo. At Toyota, if I remember right from tours, they have an area they call something-or-other dojo, where production workers are brought offline to learn different techniques. It's a really interesting concept. Can you share a little more about what this means in a software development context? Maybe the story about how and why it got started at Target might help illustrate some of that.

Joel Tosi: I'll start and give you a little background on Target and how it evolved, and maybe we talk about the teams a little bit. As Dion mentioned, we'd been coaching for years, and we were brought in at Target. When Target first started up their dojo, a few months before Dion and I were there, the concept was they wanted to get better at the right side of the value stream. They wanted to get better at DevOps.

So they got a small group together and said, “Let's do some experiments and see what we can learn together to get better at this one small set of practices.” The reason they called it the dojo was that one of the gentlemen there, Jason Walker, was asked, “What should we call it?” And he said, “Well, ninjas go to the dojo to train. Let's call it a dojo.” I don't know if ninjas train in the dojo, but that's the background I was given.

The team worked well, and then a manager came in and said, “That was interesting. I want to send some of my engineers down there to learn some things, but they have to be done in 30 days.” So they came into this space, worked for 30 days, learned some things, and moved on. Then they wanted to grow and scale this, and that's when they brought Dion and me in. I was there a little bit before Dion.

I remember I sat down the first day to coach a team, and the team had no idea why they were there. They had no orientation or alignment, but they were going to learn some things. I remember thinking, “That's interesting, but if the team doesn't know why they're there, how do they know what's going to help them?” It was just fuzzy.

Then I talked to a few other groups. “How did it go with other teams before?” “Oh, they learned some things.” “Okay. Did it help?” “Well, not really, because of X, Y, and Z. As soon as they left, it didn't stick.” You could understand they were learning in a silo.

So we introduced some simple things around, and it's going to sound silly, giving context to your learning. If we learn X, how does it affect the overall flow? Why do we want to learn X? How do we know X is helping us? Just real simple framing to help teams come in and learn these things. That's the history of how we got there.

As for what a dojo is: a team comes in and works with a coach for six weeks. We can talk about the timeframe if it's interesting. In essence, they're focusing on learning and applying new skills over the course of six weeks. It's not made-up exercises. Some places do katas, and katas are great practices, but they're separated from the actual work. In the dojo, a team brings in their actual product.

We start off by talking context. How does this benefit your customer? What are your challenges? Let's talk about some ideas you might want to learn that you think would be better for your customer and better for you as a team. So they create their own learning needs, their own learning desires and outcomes, and what success means to them.

Then the coaches sit with them, and early on, we teach heavily. But we're not teaching them philosophy. We're saying, “You said this hurts. Here's an idea, here's a practice, here's how it works. Let's do it right now with your stuff and see what happens.” It's this small, iterative, continuous learning and continuous improvement that we do with teams over and over again.

Starting With the Customer

Mark Graban: What would be an example of the type of questions they would have or what they want to learn? If they're coming in with a software product, would a question be, how can we increase usage of the product among current customers? Are these business challenges, technical challenges? It depends?

Joel Tosi: It spans a spectrum. I can give you an example of a team I was working with just this week. These brilliant engineers built a beautiful platform. They built it for three years, and nobody is using it. On the business side, it's, “We spent a lot of money. It would be really good if somebody used this platform.”

If you ask them, “Who's going to use your platform?” it's, “Everybody's going to use it. It's going to solve world hunger. It's going to solve all the problems everywhere.” Okay, well, give me an example of somebody. And they couldn't give an example of somebody. So, let's talk to actual people you think this might help, and let's understand their world.

This first week, they haven't even coded yet. One of the engineers said at first, “I really need to code, I need to code.” But at the end of the week, she realized, “The worst thing I could have done was start coding on Monday, because we were very wrong about what the customers needed.” So this first week they've really learned what you could call customer empathy, or product thinking.

Next week we're going to be teaching and guiding them on how to take a small customer pain point and actually write the code against it, but do it with quality first and in a repeatable manner. So now they're going to learn better engineering practices and better operations practices. Then they're going to show it to their customer, get feedback, and learn how to incorporate that feedback into their next round of learning. So they've learned customer empathy, they're going to learn engineering, then they're going to learn feedback loops, all in the course of six or seven days together.

Why Six Weeks?

Mark Graban: I'd be curious to hear a little bit about the timeframe. You mentioned 30 days, six weeks. Is this a full-time, 40-hour-a-week activity for people in the dojo?

Joel Tosi: Why don't you hop on that, Dion?

Dion Stewart: The short answer is yes. The idea is we get people out of their normal work environment. Rewinding a couple of steps, you mentioned the Toyota dojo and references to martial arts. That's exactly the idea here. Dojo is a Japanese word that comes from martial arts and meditation halls. It's a place of practice. It's where you go to learn.

The 30-day thing, as Joel alluded to, happened by accident. Initially, the timeframes teams spent in the first dojo were shorter than that, and at a certain point a leader said, “I have this product deliverable that's due in 30 days. Can you work with my team to help them meet that deliverable?” That's how the first 30-day experience started, and it seemed to be a good length of time.

The 30 days ends up being about six calendar weeks. From a coaching perspective, the coaches are very hands-on the first two weeks, at least in terms of the Agile and process work. The second two weeks they can taper off a bit. The last two weeks, we're really looking for the team to step up and own their own process. The more technical coaching, like how do you code well, design well, test well, and how do we take these manual tests and turn them into automated tests, is usually more consistent throughout the six weeks.

The six-week period turned out, through experimentation, to be a pretty good block of time. Shorter than that and teams weren't necessarily changing the way they work. The learning wasn't sticking. They weren't adopting that continuous learning mindset. Anything longer than six weeks, and the team starts to get a little too dependent on the coaching they're receiving in the space. And there's this sense of urgency around, “We're going to come in, and for a period of time we're going to practice and focus on learning over delivery.” Anything beyond six weeks just seemed like too much, experimentally.

I wish I had a better answer, like “neurological studies have shown this is the optimal timeframe.” Coincidentally, there are books I've read about forming habits, and the timeframe seems to be similar, but that certainly wasn't our intent going in. There was no science behind this.

Mark Graban: Well, a lot of times we learn through practice. If something seems to be effective, then good, right?

Learning Over Delivery and Repetitive Practice

Dion Stewart: Yeah. That is a key component of the dojo. Looking at principles, it's learning over delivery, it's about practice, and it's about repetitive practice. It's not, “We're going to learn this technique this week, and next week it's a whole new set of techniques, and in week three…”

Traditional training approaches things that way. If you go to a course or a workshop, there's a syllabus, and usually it builds on itself, so you do foundational stuff earlier and learn more and more advanced techniques throughout the workshop. There are coding workshops where you start a code base at the beginning, and at the end of two days you've built up something with a moderate level of complexity. You've successfully done it, but mostly because you followed instructions along the way. Often, if you were asked to repeat it over the next two days by yourself, it would be really hard, because you haven't practiced. You've done each step once. You haven't done the repetitive work to ingrain it, really learn it, and form habits around working that way.

Mark Graban: I was going to ask if it's a hard sell to get six calendar weeks of time, but I think you've already answered the question. It's probably not as tough a sell because this isn't taking people off into disconnected education or training time. This is a focused work effort with an emphasis on learning by doing. Is that fair to say?

Organizational Inertia and Incentives

Joel Tosi: Yeah, that's really fair to say. I would say that when you ask a team to come in, it's not always, “Yes, obviously I want to do it.” Especially when we start up a new dojo in a new organization, the first team is usually hesitant. They might want to learn things, but they're still like, “I don't know what's going to happen.”

In a lot of organizations, people are not incentivized to be creative. It might sound harsh, but even with the team I was working with this week, one woman who wants to be a coach was very blunt. She said, “Look, it doesn't matter what this team produces. As long as they produce it on time, I'm successful.” And it's like, wow. Interesting. And it wasn't about end to end. It was just, did this team finish what they needed to finish by a date?

So sometimes we hit this organizational inertia, where we also have to convince management: this team wants to learn something. They're going to do some work, but we can't apply this undue stress of “if it's not perfect in six weeks, by the date I arbitrarily made up, it's a failure.” We also need to guide leadership through these experiences.

Mark Graban: Hearing somebody say, “It doesn't matter what we produce as long as we produce it on time,” generalizing here, that's not a very Lean mindset. It reminds me of being back at General Motors, where it was quantity over quality. I've seen that in other workplaces, where nobody would say it as directly, “It doesn't matter the quality of what we're producing as long as we hit our numbers,” but boy, it was evident in practice.

Dion Stewart: Yeah. We do run into this in the dojo, because even though teams are bringing their real-world work in, which is important, primarily to make the learning stick and make it contextual, they're still slowing down to learn. So there's still a conversation around what's the value in taking a little time to slow down and learn better ways of working, rather than just continuing to work the way you are and maybe expecting your employees to improve their skills at night or on weekends, reading books and practicing new techniques.

It can be an interesting conversation with people in leadership roles, and it gets into things I'm sure your audience understands and experiences all the time. The mindset and value system people have might very well align with bringing their teams into a dojo space, but what are the incentives in the organization, and what measurements are in place that they're also trying to work within? Does the overall system in the organization support this learning and slowing down for a period of time in order to improve and get better?

“Slowing down” might even be the wrong word, because again, it's all about productivity and output, right? But if we were to pause and reflect a little on the way we work, could quality increase dramatically, and is that an investment worth making?

Go Slow to Go Fast

Mark Graban: What you're saying reminds me of a Toyota-ism: go slow to go fast. You may intentionally say, “We're going to slow down so we can learn some things,” but the intent is to then go faster than we had been going before.

You can look at patterns around Toyota factory ramp-up rates. Toyota plants generally ramp up production much more slowly than, let's say, a typical Big Three plant that would be a lot more aggressive in trying to get to full production. But the plant that's more aggressive about getting there faster inevitably has more problems over time, and probably lower productivity over a span of years, than the factory that took longer and more intentionally ramped up to a more sustainable, more predictable throughput rate.

Dion Stewart: That's really interesting, and I wish more people in the software space were aware of that. A lot of people in software these days are aware of trying to apply Lean principles to software development, but I think they look at a running Toyota plant and say, “Okay, that's where we want to go, so on Monday morning we're going to line everyone up at the end of the pool and dive in together.”

Migrating to the cloud in the software world is a perfect example of this. What organizations that want to move into the cloud should be doing is something analogous to what you described. Let's take our time as we're first starting to get to the cloud, make sure we do it right, and ramp up. Instead, there are often these initiatives like “by X date everyone will be in the cloud,” and that only causes problems, from what we've seen so far.

A Dojo for Creating a Dojo?

Mark Graban: One other question before we talk about the book a little bit, before we have to wrap up due to timing. This question is going to seem kind of meta or recursive, but I mean it as a serious question, not just to be cute. If an organization came to you and said, “Joel, Dion, we want to create this dojo structure within our large organization. Can we set up a dojo for the purpose of creating the dojo model?”

Joel Tosi: That's interesting. Wow. I would tell you this: when organizations want to start a dojo, I was going to say we take them through a mini dojo, but we actually take them through value stream mapping the dojo and the impact they want to have. So some of the practices teams learn, we use before we start a dojo or before we tell an organization it's a good idea. You could maybe call it a mini dojo at the organizational level, to see if they're aligned. That's an interesting question. What do you think, Dion?

Dion Stewart: I think that's true. We start what a dojo experience for a team would look like with them, and it doesn't really end before we bring the first team in. That meta-level dojo experience, if you will, continues on.

One of the other things Joel and I do in these dojos is what we call “coach the coaches.” In addition to helping the teams coming through, organizations usually staff a dojo with at least some of their own employees. They might bring in consultants to help initially, but we're also working with those coaches to help them become better coaches: coaching katas, pairing with them as we work with teams, all of those kinds of things, with the idea that eventually Joel and I and other consultants can move out and the organization can sustain this themselves.

Mark Graban: Right, right.

Dion Stewart: And periodically, we'll stop and do some of the practices we do with teams with the dojo staff, for lack of a better word.

Joel Tosi: Yes.

Writing the Book

Mark Graban: So the book, again, is Creating Your Dojo: Upskill Your Organization for Digital Evolution. It's available on Amazon as a paperback and a Kindle book. Writing a book is always a big undertaking. What led to the book? What was the spark?

Joel Tosi: Five years.

Mark Graban: Five years. It is a big undertaking, yeah.

Joel Tosi: Like Dion mentioned, we were coaching for a while, and it felt like this was being impactful for organizations. At first it was, “We should share a lot of these ideas. It'll only be 15 or 20 pages, a nice little white paper.” Then we tried writing, and it became bigger and bigger and bigger.

The point of the book, ideally, is that you could read the book and do this on your own. I think Dion and I are pretty cool people, and we love to help people, but if we can't help you and the book does, and you're successful, that's really impactful for us. We think this idea of making learning what you do every day, regardless of domain, is such a powerful thing that if more people embraced it, I think we'd all be in a better spot.

Who the Book Is For

Mark Graban: Maybe I'll ask Dion: who's the target audience for the book? What industries, what levels? It talks about digital evolution. Is it geared more to people in software and technology companies, or who do you think is going to be reading this book?

Dion Stewart: Initially it's geared more toward people who have some kind of software component in the products they're creating. Knowing we were talking to you this morning, I was mulling over the question last night: could hospitals apply this kind of concept? I think there's probably something there that a more general audience could glean from this approach, setting up a separate, dedicated learning space and how you might go about doing that. But our book is a little more specifically targeted toward technology organizations.

The ideal person is probably someone in a change management role, or, we don't like using this word, in charge of transformation. We specifically chose the word “evolution” for the title as opposed to “transformation,” because transformations carry all this baggage. When is it going to be done? How much do I fund the transformation? What's it going to take to get from A to B? Whereas evolution implies an ongoing process, which we feel is more appropriate for the dojo mindset.

But anyone in a leadership role. We get calls a lot of times from people in charge of the Agile coaching group in their organizations, transformation leaders. There are people in Lean roles, Lean Six Sigma Black Belts, who are trying to improve processes and practices in their organizations. It could also be for coaches and leaders who aren't at that level in the org but want to try this in more of a grassroots way.

We know of a couple of places where people in leadership roles who were trying to help an organization learn DevOps practices have tried this approach, talking to people they know in other organizations who are doing it, with a small group of people and one or two teams, just to see if it works for them. If they show success, the idea is they can run it up the chain in their orgs and talk about building a company-wide dojo.

Mark Graban: I'm going to give that question some more thought as I read the rest of the book. Thank you for sharing a bit of the preview. I see here on Amazon that I've pre-ordered the Kindle book, and it says it'll be auto-delivered on November 19th. The paperback will be about that same timeframe, you think?

Dion Stewart: Yes. And thanks very much for pre-ordering the book. The one thing I'd say to the audience, if they hear this before the 19th, is maybe hold off until the 19th, because I think there's going to be some sale pricing on the Kindle book.

Mark Graban: Ah, okay. I'll ask you to send me a check, Dion. No, that's all right. Just buy me a drink next time we get…

Joel Tosi: I was going to say, we'll buy you a nice bourbon.

Mark Graban: Yeah, that's worth more than $9.99.

Wrapping Up

Mark Graban: As we wrap up here, I want to let listeners know, if you go to dojoandco.com, that's spelled out, dojo A-N-D-C-O dot com, you can find more information about the book and click through to their website.

I'll also mention on your behalf, and dang it, I'm going to be out of town or I would come hang out, there's going to be a workshop in Dallas December 9th and 10th on creating your own dojo. I'm sorry I won't be around to either attend or take you up on that bourbon.

Joel Tosi: There'll be more opportunities, trust me.

Mark Graban: We'll figure that out. Maybe we'll do another learning event like we did in San Antonio a little over a year ago.

Joel Tosi: Oh, definitely.

Mark Graban: That was a lot of fun. We toured Toyota, we went to Garrison Brothers Distillery. It was great collaborating with you guys on your Dojo Consortium event up in Minneapolis, too. So we'll figure something out.

Joel Tosi: I think we're all trying to help people learn, right? And learning goes across domains and boundaries.

Mark Graban: Yeah. Thank you for what you've shared. It's been great collaborating with you guys over time, and congratulations on the near launch of the book. I'll leave it to you if you've got any final thoughts or anything else you want to mention. Dion?

Dion Stewart: No, other than to say thanks. Always good talking to you, and thanks for having us on the podcast.

Mark Graban: You're very welcome. And Joel?

Joel Tosi: Same thing. Thanks for having us. Looking forward to getting that drink with you.

Mark Graban: All right. Thanks, guys.

Joel Tosi: All right. Take care. Thanks, Mark.

Creating Your Dojo: Joel Tosi and Dion Stewart on Learning That Actually Sticks — Episode #351

Streaming Player:

Questions, Topics, and Links: