Jim Benson at his company Modus Cooperandi combines Lean principles from manufacturing, Agile methodologies from software design, and the communications revolutions of social media, as process and tool infrastructure. Jim is best known for his seminal work, Personal Kanban.
Download PDF Transcript of Podcast
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Related Podcast: Quallaboration Podcast with Personal Kanban Founder
Transcription of Podcast
Joe Dager: Thanks everyone for joining us. This is Joe Dager, the host of Business901 Podcast. Participating in the program today is Jim Benson. Jim is the principal of “Modus Cooperandi” and the author of the upcoming book, “Personal Kanban”. His company helps individuals, teams and organizations to be more effective. Their primary weapons are increasing the level and quality of communication in an organization, a team, or even an individual. They use lean techniques, agile methodologies, and social media to achieve these goals.
And, this is what has led us to this podcast: Quallaboration. Jim, now if you can straighten that word out for me and introduce yourself and start, I’d love to hear how that melted together?
Jim Benson: Quallaboration came up one morning when a friend of mine called and said, “Would you be part of a series of lighting talks?” And I said, “Sure” And he said, “Well, they’re on quality?” And since I bring everything back to collaboration, I said, “Well, then my talk is on Quallaboration, ” And he said, “Great” and then he left. And then, I had to figure out what exactly that meant. So that’s the genesis of the word, at any rate.
Joe: Quality in communication or quality in collaboration, pretty difficult to get them two together, isn’t it?
Jim: Well, for me, what I found is that quality can be achieved by one or two methods, and they’re both equally… well, they’re both equally effective up front. The first one is a collaboration, and that’s kind of the one that I like. Its alternative is fascism. Fascism works really well for quality control, at least at the beginning. What ends up happening is, somebody who has a strong position in the company dictates a certain set of steps or procedure or a process by which the item that they’re making is created with quality, a quality object is created.
So, they say, “You do a, b, c, d and e, then you’ll end up with quality.” The teams’ starts doing that; they do a, b, c, d, and e, and they say, “Wow, this is really high quality. I love my benevolent dictator.” They go through that after a while, a, b, c, d, e, and they get quality, quality, quality, quality.
Then after a while, something in that chain stops working quite as well, so ‘d’ stops working quite as well. What ends up happening at that point is, nobody is empowered to change it. That’s why I prefer the collaborative elements of quality over the dictatorial elements of quality, because when you collaborate, people have the permission to actually change the processes by which things are created.
Joe: So you’re saying that… Well, isn’t the dictator still there?
Jim: The dictator may still be there because most companies are run in a hierarchy. But if you can instill management processes that push decision-making down to the lowest possible level, so you distribute that decision making, then you give people the ability, the authority, the capability to make decisions on their own and act on them. So you start to distinguish between leadership and control. That previous dictator now becomes a leader, and a leader is someone who sets the tone for the company, sets a vision, watches out to make sure that you’re not being chased by the IRS or the FTC ? does those things at a high level a leader is actually supposed to do, as opposed to dictating the day?to?day operations of the company.
Joe: Do you separate the two when you go to explain it to people the first time? Or did you take it and say, “Here’s what Quallaboration really is?”
Jim: In the original lightning talk what I did was I used one of our recent engagements as an example. In that example, there was a group of people in a customer services branch of a small company. They were buried in work. They were being managed as if they were all individuals. They did not have any open paths to collaborate. These guys were pretty much naturally collaborative. These were team sports kind of people. So, on the weekends they went out and played softball and baseball and football, they were used to operating as a team. But then when they got to work, they had their individual little piles of work that they needed to get done.
What I found was that, or what we found was that it was extremely easy to get them to start collaborating because they weren’t waiting for someone to force them to collaborate. They were waiting for somebody to allow them to stop not collaborating.
Joe: So if they were already collaborating, what was the problem?
Jim: The problem was the way that the company was structured, and more to the point, the way the group was structured. So that specific group, they had a goal which was to process as many trouble tickets as they could through their customer service system. They had fallen behind simply because there were too many tickets being produced, and they could not process them all. As they fell behind there became this huge backlog. They couldn’t catch up with the backlog, and the response of everybody was the obvious response. They saw this problem and they wanted to attack it and they wanted to attack it by brute force.
They wanted to process as many tickets as they possibly could. So in order to do that, they set up a competitive system where everybody was ranked by the number of tickets they processed in a given day. What ended up happening was it ended up there was no cross training, there was no communication between people in the group.
Some tickets would languish because the expertise necessary was held only by a few people. Very difficult tickets would be glanced over or could potentially be glanced over because people didn’t want to be mired down with those particular tasks. That was a highly individualistic system.
But since they were trying to solve the symptom and not a problem, it was a logical system for everybody, so nobody even saw that there was an alternative.
Joe: Then when you went in there and saw that, what was your first step? What did you try to create with them, or did you just sit down and talk to them?
Jim: What we did initially was we explored the problem that they were having. We have this huge backlog; we have this need to get rid of this backlog. How can we get rid of this backlog quickly? We started saying, “OK. Well, how are you going about it now?” “Well, we’re doing these metrics, we’re trying to process tickets faster and faster.” I said, “OK. Why are the tickets there to begin with?” That led to the answer. “OK. Do you think there are more tickets in there than should be?” That led to the answer. We started to explore and not necessarily attacking the problem head on but how can we do some end runs around it to actually get to the root cause. So, what were the root causes of that massive backlog and why was that backlog growing? Why were there people that weren’t trained?
Why were there people who were hoarding information, not even intentionally. They were just hoarding information because they didn’t have time to train anybody else.
So, we started to discuss ways, say, “OK. Well, if that metric isn’t the best metric to use, what other metrics can we use? If people aren’t being trained and we don’t have time to train them, how can we invent opportunities to train them?” The more that we talked about that, the more not only a collaborative system developed, but a collaborative system that they were actively developing themselves developed.
Joe: Did you map out the process that they had or was it more of a Kaizen event or what was the actual, I mean did you use some of the… I think of some of the lean tools, how did you start?
Jim: I would say yes to all of the above. We mapped out a value stream early on. So we did this over the course of four days. Then every time we discussed things in the preceding days, went back and revisited that value stream. Not explicitly, but we would write all over our notes around the value stream and as we did that people would find changes that they wanted to make to it. Then we would have other times where we were focusing on metrics. So we would talk about not only the metric as a number or a designation for status but also how that would impact the value stream.
Then we also talk a lot about, which I don’t think anybody there was expecting about what upset them. Customer service tends to be non?billable feature of organizations and therefore their importance is often downplayed. When that happens everybody notices it especially the people in that group.
They internalize that; it becomes part of how they feel about themselves. So they begin to feel like their concerns are going to always be the last that are dealt with in the organization, whether that’s true or not. They had a lot of valuable or vital concerns, valid concerns.
Their concerns came about because they’re trained professionals, and they knew what they were doing, and they were waiting for someone to come along and respect them and allow them to voice those concerns.
We expressly delved into not just their concerns but then how to prove their concerns in the future using the lean tools that we were giving them. So how to show in your value stream that something is slowing your team down?
Once it became clear that these tools were things that they could use after Tony, Anne and I left their office to affect positive change, the level of buy-in shot through the roof. People started coming to meetings, and this is like only on the second day. But people started coming to meetings with an agenda already in their heads. So it really didn’t matter what we wanted to talk about, they already knew what they wanted to work on, which also was a collaborative environment.
Joe: I like the way you said that: you supplied the visual aspect that maybe they didn’t have before, is that a fair assumption?
Jim: Well, not only the visual aspect but the permission to do a few key things. One is the permission to effectively complain. Previously, they felt like, “OK, I have this complaint and I’m going to go talk to somebody about it but when I do they’re just going to say that’s nice, and send me back to my desk.” Now the reason that that was happening was the person they were complaining to was sending back to their desks with, “Go back to your desk and bring me back proof.” To the complainer, that felt like they were being written off. But to the person that they were complaining to, they’re like, “I can’t, I can’t solve your problem if I don’t have a well-rounded idea of what that problem is.
The visualization helped them do that, helped them make that argument. It also allowed them to make that argument in the first place. The other thing was permission and respect to make immediate changes on the floor.
So whether it’s visualized or not, if they get together with their team and they think that something is going to make things better, their solution doesn’t greatly disrupt the operations of the company. So, for example, they could not say, “We think a hot tub in the middle of this room would make things better.” They can say, “We think that if we rearrange how we are answering phones slightly, that might make things better.”
They can do the latter then the third better permission there is to help your friends. So before, when it was every man for himself, if somebody else ran into problems or if somebody else pulled a task or a client that somebody knew something about, they’re just like, “Oh, I hope they do a good job with that.” But now, we’re actively encouraging them to stand up, walk over, sit down and actually pair with them or even just offer a small advice to move that ticket along more quickly and make sure that that trouble ticket, when it’s resolved, doesn’t come back again.
Joe: If someone was spending too long on the phone or was just struggling a little bit, they could kind of put a yellow light on, and someone would come over and help them?
Jim: There is that but then also setting policies. So if you get a call and it’s something that you don’t know anything about, you have a couple of choices. One is you can find somebody who does and then bring them onto the call with you. The second is you can transfer it to somebody else. The third is you can say, “One of us will call you back.” End the call, go on to a call you can do something about and then add that call with notation back into the call queue so that somebody can pick it up next time who does have experience.
What tends to happen otherwise is, the person will sit on the phone for a very long time trying to slog through the problem while they’re sitting on the phone for two or three hours trying to slog through this problem while there’s a large number of five or ten minute calls that have all bounced off and become tickets that somebody needs to pull in the future that they could have solved during that.
Joe: I’ve called to enough call centers that after the third call, it was like, “Why didn’t I get that guy, the first time?”
Jim: That’s right.
Joe: It would have really helped?
Jim: You’ve also been probably the person who’s called into call centers, and your problem is just really weird. As much time as you’re spending on the phone, their spending that same amount of time on the phone, so that’s not good for anybody. So, yes absolutely.
Joe: Part of your presentation that I looked at, it talked about the real need was Kaizen. Then you said, which a consultant cannot provide. There are Kaizen consultants all over the place. Could you explain that a little bit?
Jim: Yes. Kaizen is an epiphany in its truest form. So Kaizen is building a culture of continuous improvement or giving a group the skills that they need to diagnose or recognize problems, diagnose them and then come up with a potential solution and then experiment with that potential solution. You can teach people the mechanics of that. But there’s got to be a philosophical and an emotional buy into the system before it will really make any difference. I could have gone to that group and gone through a PowerPoint on Kaizen and say, “These are the elements of Kaizen and this is how you can notice a problem and here’s the Five Y’s so that you can drill down to the root cause of what’s happening. That’s all well and good.
In the end, there’s just this epiphany that people have to say, “My God, I really can have control over my work.” For me, that’s the biggest prerequisite; the other stuff is just implementation details, but that honest belief that you can actually effect your environment is key. As a consultant, I can’t give you that in a PowerPoint. As a therapist, I can come in and help people recognize that that’s a possibility and then maybe give them a few exercises that lead to that epiphany.
Joe: I think it’s very true in the fact that I’ve always seen people come in and think here we go, through another quality circle. We’re going through another thing here and then it will just be back to normal a month from now. Half of them are rolling their eyes and leaning back in their chairs. I think to get that buy-in is so important, and that’s what you’re saying. That’s really your job is to create the buy-in, the work should be by them anyway.
Jim: That’s where you have to match the presentation style to the culture of the group that you’re working with. If I go in and talk to a bunch of people from GE that work in Manhattan and come to work every day in suits. That’s very different from working with a group of guys that come to work in the middle of West Virginia in T-shirts and blue jeans every day. They intrinsically relate differently to their careers, their jobs and their ability to affect their environment. They both ideally would like the ability to affect their environment, and they both are probably very jaded in different ways.
Joe: Now, I have to ask you, did they go ahead and take all the queues and construct a Kanban board?
Jim: I always say that that engagement was probably my favorite engagement out of any I’ve ever had. Not only were they excited to get started but when Tony, Anne and I arrived, people were upset. They were very upset. But this company that they’re working for is privately held, decades old, it’s successful and they’ve had a very real hand in building this successful company. And they cared about it. One of the reasons why they were upset, probably the major reason why they were upset, was because they did care. They weren’t able to take this love and affection for their organization that they had and make good on it. What we found was that they were very excited to build collaborative systems.
Then after we left…I check in with them regularly. They developed their own terminology; they created entirely new positions in order to deal with the different tasks that we had developed. None of those tasks were job description tasks. They were roles that people cycled in and out of. The system naturally is fault?tolerant, naturally teaches people new skills and does an admirable job of reducing the backlog of work that we were initially shooting to reduce.
Joe: Have they caught up now?
Jim: No. They were way, way, way behind. They only way that they would be able to catch up is to just destroy the backlog entirely and not make good on it. But they have reduced the backlog, I think now by about 35% or 40%. There were about 2,000 things in the backlog, and they were 24 people in the group.
Joe: What did you take away from this that will help you with the next organization?
Jim: The things that we took away were … first off, I mean for me the biggest thing of this whole company, whether it was that group or their different coding groups or other groups throughout the company. They were all doing Kanban in one way, or another. There was tremendous natural innovation in the visual controls themselves. So one of the groups was tracking sentiment in real time, and they were ashamed of it, initially. So I said, “You know, we probably need to get rid of the silly things on our board.” I said, “Well, tell me what the silly things are.” They said, “Well, you know, sometimes a task is a lot of fun so we put a little smiley over it and sometimes tasks are really awful so we put a little mushroom cloud over it.”
I was like, “This is brilliant!” So we talked about ways that they could save those mushroom cloud tasks and then when they went back and did a retrospective later, they could actually discuss the tasks that were bad and the tasks that were really good. And say, “Why did these ones work really well? What was it that was causing problems with these other tasks?”
No one coached them to do that, that wasn’t in any of my writings; it wasn’t in any of David’s writing. It was just what they decided needed to be done.
Joe: Software development has Pair Programming. I see other uses of it in other fields, is this kind of a different take on Pair Programming. Have you seen that in your Quallaboration efforts?
Jim: Oh, you bet! So everything… Pairing is one of the things that I’ve taken out of programming, taken out of Agile and put everywhere I can. I found that the … because I’m so focused on Quallaboration, that Pairing is an amazing gift to long term productivity and to the quality. I find that when people come together in a conference room and they decide “You go off and do this and I’ll go off and do this and then we’ll meet in a couple of days and then we’ll figure out what to do next.” When you meet together you achieve the kind of this bubble of clarity. You understand what you’re supposed to do, and the other person understands what they’re supposed to do. But you kind of understand it in context of your conversation. It’s this really bounded rationality, this world view that you have in the conference room that starts to dissipate the moment that you leave the classroom or a conference room. So, you start working on your tasks and then and another person starts working on their tasks and maybe you’re interacting with other people or you’re writing or whatever it is that you’re doing and you run into other variables and you start making decisions. The moment that you start making decisions, you’re definition of what you’re doing and the other person’s definition starts going off in other directions.
When you do Pairing, you maintain that focus, you’ve got more of an anchor to either what was decided immediately or you have a coalmine canary that can say, “Wait! I can feel deviation happening.” Because that deviation is just a natural way of working, so when you’re doing it alone you tend not to notice. The other thing that happens in Pairing is just a natural, constant quality checking. So 100%, well, maybe 95% of the Personal Kanban book was written with Pair writing using Google docs.
Tonianne is on the one side of North America and I on the other side of North America and a live Skype line on 24/7 pretty much. We just sat there on Google docs and edited the same text all the way through the document. I’ve used it with the World Bank, with scientists working together. I’ve used it a UN project in Vietnam. I can’t say enough good things about getting two minds on something versus one.
Joe: Well, I think it is. I just think of the times I’d make a phone call at home and my wife’s on the other side of the room telling me what to say. A quality check over there and she has valid points. I think of that scenario a little bit and make fun of it, but there’s a lot to that. I mean to get that input from how you’re talking and describing it, even though they’re not listening to that other person. If they were, it would even be very beneficial. There’s just a different perspective.
You walk out of a Kaizen event; you walk out of a quality circle. You walk out of that; you go on your own and start doing a task you have a tendency to go back the way it was and what was easy for you. With that other person,, and you have accountability, that check and balance is there.
Jim: You can innovate as you’re rolling along, as you’re doing the work you can innovate. And you innovate with somebody there who again is an anchor. So they can say, “Yeah that would be a really cool innovation. We should probably alert the others that we’ve done it. ” Or, “That’s a totally illogical innovation, let’s just run with it because it doesn’t impact anybody else.” But that check and balance of keeping you in line with the rest of the organization is there. Then the other part of it is, if you’re sitting there typing and you have a lot of knowledge about biomimicry and your other person that you’re working with has a lot of knowledge about French history, you’re typing away, your worldview is informing what you’re typing.
Their worldview is informing how they perceive what you’re typing. Then you can start having conversations and blending those different backgrounds.
Joe: In part of your presentation I saw the pairing in there, but you go through all the different things that you talk about in a collaboration effort to do that, the knowledge sharing, the cross training. The strength of the whole is so much stronger… The strength of everyone together is so much stronger than individuals working on projects that you wonder why there isn’t more of that. I think of even pairing from a mechanical engineering standpoint on a cad system when people are designing things. Have you seen that done?
Jim: Yes, definitely. And my career started out as a cad designer and GIS operator. Then moved into urban planning and then beyond that into software.
Joe: I look at that knowledge sharing and cross training, what you’re doing with pairing is you’re taking all the different things of collaboration, all the things that you spell out and you’re making it immediate. You’re making it something that happens in real time.
Jim: From an efficiency and an effectiveness standpoint that’s great. In some weird ways that’s scary to a lot of people. One of the ways that’s scary to a lot of people say, for example, in the intelligence community in the CIA. They have a very set means of how you advance career-wise through the organization. Your advancement within the organization is based on your ability to create artifacts or reports that other people notice and that you can basically use as the rungs of your ladder as you’re climbing up the structure. If you start doing things like pair writing, pair programming, collaborative intelligence creation or document creation, your personal input becomes diffused.
That means that a lot of people look at that and say, “How am I going to make my mark?” You know if this is a giant finger painting how’s anybody ever going to figure out which of those smudges were by my fingers. That’s a major paradigm shift that really freaks a lot of people out, scientifically speaking.
Joe: I think very much so, I mean because I think of trying to climb the ladder it’s all about individual marks. To go to the team effort kind of waters down because they don’t promote the team, but maybe they should?
Jim: Well and what happens… and this is the complaint of any company really, is there are say in engineering. There’s a guy who goes out, gets his professional engineering certification, makes some awesome roadways or bridges and then becomes the manager of a roadway design for a company. That person can be the complete, the world’s most incredible social donut and have absolutely no management skills whatsoever. But they were promoted to a managerial position because that was the only kind of promotion they could get. Meanwhile, there might be other guys in the group who are some of the worst designers in the world, but amazing leaders that get completely overlooked. Because what’s being promoted isn’t the leadership skill, it’s a technical skill.
There is no technical skill escalation path. What would be nice is to be able to have a collaborative system where natural leaders assert themselves, or become apparent and natural doers also become apparent and everyone is rewarded based on what their actual skill set is.
Joe: Well we should be able to do that with a thumbprint somehow by now, shouldn’t we?
Jim: Marcus Buckingham has written, I don’t know, about a hundred and forty books trying to convince people to stop, stop advancing people based on things that they can’t do. I think he’s probably still got another hundred books left in him, so…
Joe: Would you go into what you find in other organizations quite often? Or is there more of a resistance to let’s say, they’re not as open-armed waiting for you to come in?
Jim: Certainly the larger the organization is, the fewer people are going to feel that they can have lasting change or impact on the organization. That can cause issues. Different organizations operate differently. So IBM or 3M have strong innovation cultures and people can have ideas and make those ideas happen. There are other organizations, especially in the financial industry where things are extremely rigidly controlled, and people feel like they have absolutely no control whatsoever. Conversely, I’ve dealt with very small companies that are controlled by one very strong personality. That personality is equated with the company, so people can’t get around that either. There needs to be a comfort level or even the assumption that a comfort level could exist where people feel that they can have, create beneficial change within their organization.
Joe: We can get quality without collaboration, I mean, you’ve proven that at the very beginning, but it’s not as lasting.
Jim: Quality by fiat requires future quality by fiat. So, you’re going to subscribe to continuous innovation and continuous improvement in a collaborative system or you’re going to subscribe to sporadic improvement and in a dictatorship or in a command and control system. So, in a command and control system, things will continue to operate on their path until the pain becomes so undeniable that you need to shift to a new improvement. The delta between what you’re doing at that point and the shift to make things better is usually very large and usually resource intensive. So it’s expensive, it’s difficult for the people to weather, it’s unenjoyable. In a collaborative system with continuous improvement, you’re constantly doing minor course corrections.
Joe: Quallaboration is really kind of a PDCA cycle with a little more emphasis on group?
Jim: Yes. But ultimately the cycle there is so tight that it’s not noticeable. So in continuous improvement, every second is a Kaizen event because Kaizen is just part of the flow. So PDCA cycle, even if it’s collaborative, still has some regimented aspects to it. Like every Friday, we’ll have a quality circle, or every Friday we will get together.
Joe: And what you’re saying with the Quallaboration, you’re looking at really trying to make it every second. What’s kind of nice about it is you’re not doing it individually, you’re doing it with a group and that’s really just a huge key here, is that constant feedback really does make it work continuously.
Jim: One of the things about the Quallaboration concept that I’m starting to really like is, especially in software you have a QA group. In my mind when you have a QA group then what they’re doing is they’re catching defects after they’ve already happened. They’re not going out and stopping defects from happening in the first place. My friend John Bach, who is kind of testing luminary, he has a system where he looks at your setup time, you have your bugs and then you have your test time. He feels that he’s creating the most value when he’s actually doing the testing. So setup is a waste and actually finding the bugs are waste. If he can go through and do a bunch of testings and find no bugs because there actually are none, that’s kind of his perfect day at the office.
One of his clients said, “How can we… we’re appreciating the work that you’re doing but how can we make your job easier? How can we lighten the burden on you?” And he said kind of glibly, “Well stop having so many bugs.”
Tat actually made them go back and invent ways to write less buggy software. Somebody had to ask them to write less buggy software. Because previously you had this testing group, and it was their job to catch it anyway. So there really was no imperative to write clean code.
In my company, in Gray Hill Solutions when we’re creating software, our testing happens simultaneously with authorship. So kind of unwittingly I was already working in a Quallaborative model. We were writing; we usually had teams of usually under five people that were writing enterprise scale software that had and continues to have extremely low defects. I think that that’s a big part of the reason why is because we make quality, to kind of steal a Ford line, but we make quality everybody’s business.
Joe: A certain part of this method that I didn’t really talk about that you’d like to add?
Jim: The one thing that I wanted to talk about just very briefly is the notion of clarity which for me is at the center of Quallaboration and at the center of personal Kanban. And what I find is that people who were previously underperforming workers or teams that were previously underperforming tend to really take off when they know what they’re supposed to be doing, how they’re supposed to be doing it, how it fits into the company and what the ramifications are for different decisions they make in building it. Once they understand how they actually fit into the framework of the company, their design decisions noticeably, measurably improve. For me, there’s a couple of easy ways to do that. The easiest way is to use a visual control that just shows everybody all the time, what is happening in the group and to a lesser extent in the company as a whole.
That gives them the context that they need to act, to make better decisions and to build a better product. I really feel like that is the thing that is most missing in teams. In every team that I’ve worked with where there’s been an issue is people were just hungry for information and got them that information in a non obtrusive way works miracles.
Joe: You clearly understand it. It’s amazing how it flows. If there is an inhibitor it’s clarity I mean, I think that would be the ideal organization or the organization that’s in perfect harmony, right?
Jim: It’s what upsets people most often. Because they know when they’re not getting the information, they need. That has a huge negative spiral because they feel disrespected; they feel like they’ve been hired to do a good job and now they can’t. So they actually feel like they’re stealing money from the company because they know they can provide more value than they are. Then they feel personally ripped off because they know that if they could do a good job they would learn more and they could do even better next time.
Joe: What’s coming up for Jim Benson? What’s going on with you right now?
Jim: Well this weekend I’m going down to Phoenix for a Scrumbian software conference where we’re basically going to discuss these issues of how to use agile methodologies out of the software field. The book comes out next month, all things, all signs being hopeful. Then in November I will be, at the beginning of November will be in Seattle at a “Health Care 3.0” summit, talking to people about Lean in healthcare. And then off to Malmo, Sweden, where I will be talking to software developers at a board of a large software conference. So a lot of plane time.
Joe: Now, how can someone get a hold of you?
Jim: Well at Our Founder on Twitter is the easiest way. And that’s Our Founder, O? U?R?F?O?U?N?D?E?R. Or the personal Kanban site, personalkanban.com has my contact information as does the most difficult to spell moduscooperandi.com.
Joe: I appreciate your time very much. I look forward to your book. I’m in great anticipation of it, I think you have seeds for another book?
Jim: There’s no shortage of potential next books. It’s a little bit scary right now.
Joe: This podcast is available in the Business901 iTunes store and also on the Business 901 podcast site. So thanks again, Jim.
Jim: OK, thank you.
Lean Sales and Marketing: Learn about using CAP-Do