Have You Ever Worked in a Real Team? Jim Benson Reveals How to Build One

Wiktor Żołnowski: Welcome to Pragmatic Talks, a podcast and video series where we discuss startups, contemporary digital product development, modern technologies, and product management. This episode is brought to you by Pragmatic Coders in collaboration with Ace, the agile software development and product management conference. We believe that everyone should have equal access to knowledge about product development and entrepreneurship and also everyone should have the opportunity to apply it in pursuit of making our world a better place. Through this series, we aim to create an impact on the future world. In today’s episode, we are joined by Jim Benson. Jim started his journey as a punk rocker before becoming a renowned expert in effectiveness for individuals, teams, and organizations. He played a pivotal role in the development of the first real-time traffic tracking platform and has significantly influenced the field of digital product development. He is the creator of Personal Kanban and Lean Coffee, revolutionizing how teams visualize their work and collaborate effectively. In this episode, we have the privilege of exploring Jim’s insights on Team Dynamics and product development.

Wiktor Żołnowski: In this episode, you will learn what distinguishes a group from a True Team, how to turn individuals into a cohesive unit and overcome common obstacles, how communication should flow within a high-performing group, the impact of remote work on collaboration, and how to maintain cohesion virtually. And now ladies and gentlemen, please welcome Jim Benson. Welcome to the next episode of Pragmatic Talks. Today we are at the Ace conference where we have the pleasure to host Jim Benson. Welcome, Jim, it’s a great pleasure to have you here. I’ve been reading your first book almost a decade ago; I think it was the Personal Kanban book. But recently you released a new book that I would love to talk about today a little bit more. But before we get into the book itself, could you answer the first question I always ask our guests: Who is Jim Benson?

From punk rocker to Kanban inventor

Jim Benson: Always a dangerous question. So, Jim Benson is the inventor of Personal Kanban and part of the group that invented Kanban, I guess, Lean Coffee, and all those types of things. I got my start when I was in high school as an angry punk rocker. So I started a business being an angry punk rocker making albums and distributing music around the world, and I did that from the center of America before there was an internet. And so needless to say, we were pretty much the only punk rockers there, so we had to build a brand, you know, market awareness, and all those good things. Went on to become a civil engineer and an urban planner building freeways and subways. And then became involved in the beginning of the Intelligent Transportation Systems world, which is where you apply technology to transportation. I built the first real-time traffic websites on Earth, the first one for the Washington Department of Transportation and the second one for the San Francisco Bay Area. So if you use Google Maps or if you use Apple Maps, those are my grandkids. And when I had that company, that’s when we kind of accidentally invented Kanban and Personal Kanban, and the next thing I knew, that took over my life. So I’ve become kind of an expert in agile and lean and all things in between, and my goal is to build ways of working that make people happy.

Wiktor Żołnowski: Could you tell us a little bit more about your recent book, which is The Collaboration Equation: Strong Professionals, Strong Teams, Strong Delivery?

Jim Benson: Every successful thing I’ve ever been part of has involved collaboration, so we never work alone. And so one of the things that you and I are going to be talking about today is about building teams and that people have kind of fallen out of practice in being part of a team, but we’ve always kind of felt like we had our own work and we’ve never realized that all work is collaborative. There’s someone who’s asking for it, someone who’s delivering it, there’s some negotiation about those things. So in the Collaboration Equation, the equation itself is: individuals in teams create value. In agile, we talk a lot about the team; in lean, we talk a lot about value, and both of them talk about individuals like, “Yeah, people, whatever.” So the Collaboration Equation is saying if you don’t have a system that pays attention to the people and the team and the value, you’re going to have an incomplete system and it’s not going to work. So when you do have that, you have something that’s called the right environment, which is an environment where all people have the information and, I guess, permissions necessary to do what they need to do in order to do a good job.

Defining a true team vs. a group of people

Wiktor Żołnowski: Okay. I remember when I was starting my career in IT, and I think it was my second or third job when I joined a company and I joined a team. And actually, you know, in my previous two jobs, I was working in something that was called a team, but only after this – I think it was the third year of my career – when I joined a real team, did I feel what it means to be in a team. So could you tell us a little bit more from your perspective, from your experience, what is a team and what a team is not? How to distinguish a group of people working on something and a team that is working on something, which I’m pretty sure for some of you may sound like this is obvious, but I know many people who – I would say even that the majority of people right now in IT have never worked in a team before, so please tell us.

Jim Benson: So, I’ll give an anti-pattern and then I’ll actually talk about what I think a team is. So it’s not at all uncommon for us to go into companies that are already doing Scrum or Kanban or something like that, and then they have a board up and the board will show that there’s like a backlog of work and then the developers are working on this stuff and then the testers are working on this stuff and then there’s done. And there are always five or six stickies in the developer area and about 70 in test. And then people are like, “Oh, I hate testers,” and it’s like, well, first off, you wrote the crappy code and second of all, you refuse to test. So instantly you have not a team, you have two silos that are being shown on the Kanban. So a team is a group of people who are interested in making sure that work is completed both with quality and in a way where everybody that’s working on the work is protected. So a team is watching out for each other, they’re informed, they know what victory looks like, and they know what their plan is and then how they’ve been deviating from the plan. So a team has to be invested. The Collaboration Equation is like 380 pages of answering this question, so I could go on for a long time, but we’ll just stick with that.

How communication flows in a high-performing team

Wiktor Żołnowski: What about the communication in such a team? Yeah, like for example recently, I think it was even yesterday, I was talking with one of my colleagues and she told me that she was watching two groups of people, I’m not calling them teams, working on two different projects at the same time in one office on two sides of the office. And one of them was sitting silently; they hadn’t been talking to each other almost at all, except for, you know, a few words during the day. And the second group of people, she called them a team, were constantly talking to each other: in pairs, in a group, they were moving their chairs from one person to another, they were watching their screens, they were solving problems together. And for me, that experience, that description of her experience was that, okay, it was extremely easy to see which of those groups was a team and which most probably was not. But does it look always like that? I also remember that when I used to work as an agile coach, I’ve met a team that was a group of introverts who were not communicating verbally at all but they were awesome in non-verbal communication. I mean, the typing on the chat. And that was before COVID, so everyone was working in the office, they were sitting in one corner in silence, but the chat was, you know, hot as hell.

Jim Benson: And so the answer, of course, is that the verbal interaction isn’t necessarily an indication of teamwork. Because those people could have been spending all their time talking to each other saying, “Where the hell is this? What’s that? What are we supposed to do? Who are you? What are we doing?” But what you do want to look at is, first of all, is work flowing? And then if you ask people – because this is always a fun game to play – you go in and people are at their standup meeting or their huddle, and you walk up to their board and you take any ticket off the board and then you just ask two or three people, “What is this ticket?” And if you get two or three different answers, then you know that no matter how much they talk, they’re not a team. Okay, so the team itself will develop its own ways of communicating and should develop its own ways of communicating based on the people that are in the group. So that group that was sitting next to each other, it’s very easy for them to talk. When they’re all on Zoom, then talking becomes scheduling meetings, actually interrupting people, blah blah blah blah blah. So the communication mechanisms of the team need to match the needs of the communications of the team. So in The Collaboration Equation, we go through this “right environment” exercise, and the main part of that is to say, “What information do people need, when do they need it, and how should they get it?” So another problem that almost every team has is like, you’ll decide something in Slack and it just floats away into the ether and no one ever knows what you decided because it’s totally gone. So when you make a decision, do people remember it, can they see it, can they see the impacts of it, and do those decisions have permanence? So a team is going to operate in a way where people stay in alignment, and sometimes that’s verbally, sometimes it’s through text, sometimes it’s through documents; it just depends on the work and the personalities involved.

The process of turning a group into a team

Wiktor Żołnowski: Oh, so how to turn a random group – not so random, but some group of people who are working on something – into a team? So what is required, how to do this? Do you have any step-by-step process to turn the group into a team?

Jim Benson: We have a specific step-by-step process to do that, and it’s flexible. But in general, what we do is we get together initially with the team and we map out their value stream, which are the steps that you take to finish your work. And in Lean, a value stream mapping exercise is all about how long does something take to get from here to here to here. We don’t care about that as much. We care about who needs to talk to who, when do they exchange information, is that information available, are people adequately trained, do they remember the decisions that were made, do you have access to your stakeholders as the human parts of it? So we will do this kind of humane, human-centric value stream mapping exercise. When we do that, this group of people who is not yet a team usually, for the first time, they’re thinking about how they work together. They’ve never actually thought about it before and they’ve certainly never mapped it out and seen how their actions impact other people. Then after that, we go through an exercise to say, “Okay, first of all, do you understand what you’re doing as a group and why?” So what is the social impact of the work that you’re doing, why do you care about the work that you’re doing, and then why do you care about each other, and then how do you want to work? So that’s kind of the culture aspect, and so we think of culture as a real thing that you can define and you can maintain. And if you don’t think of it that way, then you won’t define it and you won’t maintain it, and then you never have one. So then we have that, and then we go on and say, “Okay, what is the information you need, how do you need it, where do you need it, blah blah blah blah blah.” And then we take those three things together: how do you work, how do you want to work together, and how do you communicate. And in the end, that creates the implementation plan for their right environment, and then when they do that, they have a team that they’ve defined, they understand why they work together, how they can help each other, and how they get work done.

Applying the team-building process across an organization

Wiktor Żołnowski: So let’s assume that we have one organization but many groups of people. Are we doing this exercise – let’s call it an exercise – with each team alone? Or are there some common things? For example, culture – is it a common thing for all of the teams, or would you rather do this exercise with each team and then maybe compare it somehow? How does it work?

Jim Benson: So there are a variety of things that go along with that. So at the beginning of COVID, we were working with a company in Germany that, before COVID, everybody in their company was based in Hamburg. Immediately after COVID, they had people all over the world, so it was just almost instantly a fully distributed team. And so we did “right environment” exercises with each of the individual teams, but at the same time, we were working with, we’ll just call it, mid and upper management to help create ways to visualize work across the company as a whole. You know, if you have 15 different teams, you know when Team 1 and Team 12 are collaborating on something. Because right now, agile calls those things dependencies. There’s no such thing as dependencies; they do not exist. A dependency is merely work that you haven’t planned adequately for.

Wiktor Żołnowski: It sounds exactly like what SAFe people say about dependencies, that they are the not-well-managed backlog items that are not put together.

Jim Benson: Yeah, that your structure of your teams doesn’t match the structure of your work is essentially what it is. So what that company did was they said, “Okay, we’ve got this project that people are working on, and there are people from these three teams,” and so there was a Miro board and it specifically showed the three teams that were working on that so that when those teams did their planning, they knew that they needed to plan together. So it’s weird, but that’s about all that you need. We make this stuff out to be very complicated because we see what happens when we don’t plan ahead, and that is very complicated, but actually planning the system out is pretty easy. It’s kind of depressingly easy, given how much pain we’ve created for ourselves.

Should organizational structure follow the work?

Wiktor Żołnowski: So I think that many people who are watching this will ask the question, but, you know, the work is changing, so should the company structure follow the changes of the work and the environment as well?

Jim Benson: I’ve gone this far without making any inflammatory statements, but here I go. Agile teams never had a structure, so we’d be changing to having one at all. So the problem was, like, Scrum Masters and Product Owners were never defined, and so no one knew what they were. Are they a team member, are they middle management, are they upper management, are they project managers, are they product owners, are they what, what are they? And so right now, people just need to build a structure at all. In most larger companies, you still have a 20th-century structure which is, you know, a super big decision maker with other levels of decision makers, and then you build a whole bunch of decision bottlenecks, and that ends up being a problem. But the roles themselves may not be as much of a problem as that communications structure that they’ve built. So it usually does help to have like one person who says, “I’m going to pay attention to these teams,” because otherwise there’s not a person to be that, you know, director of that work. And I don’t mean director like, “You will do this,” I mean director like, “You know, this work can go over here, or this can flow over here, or these people need some help over here.” Those roles are still important, but yeah, it would be really nice if work could be – if the structure of companies could match the needs of the work and the people doing the work. But there’s not a lot of models out there for them to do that effectively.

Wiktor Żołnowski: I think that it’s already starting somewhere. We had one of the previous episodes with Joe Justice about how Tesla works and how other Elon Musk companies work, and their teams are very dynamic. And right? But Elon is a dictator, so…

Jim Benson: Does it matter if the teams are dynamic?

Wiktor Żołnowski: Actually, you know, he’s, at least in the story that Joe shared with us, was said that actually the work there is managed not by Elon himself but by the AI which is prioritizing the work. So it’s even more than a dictatorship; it’s AI-driven, AI-driven management, and the AI decides which experiments people should perform. And people have time boxes of one day – which is, in their case, a 12-hour shift – where they are working on one single improvement, problem, whatever they want or have to.

Jim Benson: That does not sound preferable to me.

Wiktor Żołnowski: There are still people, there are still people who enjoy this kind of work. Maybe they have, like, you know, they value the meaningfulness of their work more than the other aspects. So I think, you know, that not everyone fits Tesla, and Tesla or other Elon’s companies are not for everyone. But there are some frameworks and patterns that could be implemented so the structure could be easily adjusted to the work that needs to be done.

Jim Benson: So, in The Collaboration Equation book, some of the larger examples that I use are actually not from software at all but from construction, and construction actually ends up being more like software than software is. So we think of construction like, “Oh, you have plans and you’re going to go build that building,” but it’s all emergent design, like more than you could ever possibly imagine. And so the projects that we worked on were all multi-billion dollar projects in New York, so skyscrapers, hospitals, schools, and things like that. And the examples that are in the book, like my favorite one, is from a hospital project in Brooklyn which was a billion-dollar project, and it had to be finished on time and on budget, which in construction is unheard of. And so what we did was we made all of the work visual. We made sure that every problem, like their motto there was that “we solve problems immediately and together.” So when an issue would show up, everyone on the project would get together and they would swarm on it, which is very unheard of in construction because in construction everybody’s like, “I am the administrator of all things concrete, I am the administrator of all things structural steel, I am the blah blah blah blah blah.” It worked so beautifully; everything was visualized, everything was human. There was no central management system, and it was important because emergent work is usually not noticed by any type of a central management system. Central management is managing the known work, and emergent work is very difficult to track and appreciate.

The power of visualizing work and acting with confidence

Wiktor Żołnowski: Yeah, I think that this is where the value of a team comes from. Like, if there is a group of people, a group of individuals who are working on something, usually they are not empowered enough to make these kinds of emerging decisions because they are afraid, because they are not empowered to do this. But when you have a team, the team is usually, you know, a group that can support each other, that people can discuss some things together, they can make a decision, they can perform this decision, put it into action, and then see the results and sometimes even report the results to the management or some upper level in the organization. Which is, in the case of a team, if it’s a real team and they are supporting each other, it’s much easier for them than for individuals.

Jim Benson: So in the book, the phrase that we use is “acting with confidence.” And so the story from that is that we had set up one of the initial Obeyas. An Obeya is a room or an online location where all of the information that a team needs lives. So there it’s usually visual. So, you know, the Kanban guy is telling you Kanban is never enough. You cannot have just a Kanban because it’s only one view of your work. And so using PowerBI alone or using Kanban alone or using Jira alone is like driving your car only by looking at the gas gauge. You don’t have enough information to actually operate your work. And so we had a room set up for the beginning of this project and a bunch of Human Resources people were in there, and they were interviewing the guy who was using this room, this work, named Kevin. And they asked Kevin, they said, “Does this improve your work-life balance?” And construction is kind of like Elon, right? It’s like 12-hour days, it’s tough on you. And he said, “I work in construction, my work-life balance isn’t going to change.” He said, “But what I’m doing here is constantly keeping all the people that work with me, whether they’re above me or at my level, informed of what I’m doing. It lets them know when they need to act and how I’m acting and what issues I’m running into.” And he said, “And that lets me work with confidence, that lets me act with confidence.” And I realized at that point, most people don’t. They don’t act with confidence because we don’t have that information. So for me, at the center of any team is: do people have enough information to act with confidence? And if they do not act with confidence, usually they do not act at all or they act… So they either act stupidly or they do not act at all, both of which are damaging. And so the more that we put time pressure on people, the more likely they are not to investigate things and the more likely they are to act with a lack of information.

Overcoming the most common obstacles

Wiktor Żołnowski: Okay, so we already talked about what the team is, more or less, and what is needed to build a team, maybe not how to do this but what is needed there. What are the most common obstacles that you’ve seen on the way to building a team, turning a group of people into a team? I think that there is a bunch of them.

Jim Benson: So, on our at our online school at Modus Institute, there’s a class called “Toxic Waste,” and it’s all the ways that we can be toxic to each other, and I think it will end up just being a class that just grows and grows and grows because we are so good at building poor systems. And so when we reduce everything back to how do you mitigate all of these different toxic problems that stop a person from acting responsibly or professionally, from a team improving, from people doing work in sequence, that most of these things are due to some outside pressure which usually comes back to fear of something. Somebody’s fear of not being able to make their numbers, somebody’s fear of people discovering they don’t know how to do their job, some people’s fear of finding people discovering that they don’t actually have a job, they just get paid to be there – and there’s a name for that, like a do-op. So there are a lot of different things in a company or in a group that are going to thwart people’s ability to get their work done. The only way that we’ve found to get around that is transparency. Do you see the work that’s coming up? Do you see the work that’s being done as the work is being done? Do you see when you need to act as you do act, which means you see something that needs to be done and then you do it? That by nature is going to change your original plan. So do we remember how our plan changed, and then are we filtering all of these decisions through an understanding of who we are as a team, why we’re here as people, how we want to upskill, all of those kind of cultural values? So weirdly enough, that’s the talk that I’m giving this afternoon is on “The Seven Elements of a Visual Control,” but what that really is is just basically like, what do you actually need to know to be a team to get your work done?

Why “just documenting it” isn’t enough

Wiktor Żołnowski: You mentioned a few times that it’s very important for the team or the team members to know how the plan changed or what we agreed to. I’ve heard from many, let’s say, naysayers or people who are saying that individuals could be as effective as teams, etc. I’ve been hearing it many times that they are saying that, “Well, it’s all about the documentation. If you are doing proper documentation, then we don’t need to communicate at all.”

Jim Benson: Do you know where the documentation lives? Do you know if it’s up to date? Do you know who updated it? Do you have access to the ability to update it? But the problem with documentation is that we move fast enough that the documentation becomes old very quickly. So I’ve gone into companies where they’ve said, “This is our group that updates Confluence.” Like, “What?” They said, “Yeah, yeah, we have these people, and when you want something updated in Confluence, you submit a request to them and then they’ll update it because they’re our documentation experts.” It’s like, “Really? Do you have swallowing experts? Like, when I want to swallow my lunch, do I contact the swallowing experts?” It’s like the whole reason that Ward Cunningham invented the freaking Wiki to begin with was so that everybody could edit it. The same thing is true for the Kanban or anything else. It’s that when you’re doing the work, you have to be able to make changes in real time to the system. So documentation is extremely important, the minimum amount of effort is very important, and an understanding that if you go into the documentation and you discover that something isn’t up to date or could use a comment, there has to be a way and an expectation – a way for you to and an expectation that you will – update that information or flag it. And that there’s also an expectation that when you need to know something, you will go look at the docs. How this is going to become easier is this is like one of the best ways that AI can be used now. Because the AI can go in and you can ask the AI questions now like, “In the past when we had to make this type of a decision, what did we do?” And then it can come up with three or four different things out of the information repository that you have. And that as you go along, you could even tell the AI, “Okay, thank you for telling me that. Number three is officially out of date.” And then it could even have a system where it could go in and it could say, “Hey, Jim says that this is out of date. Does everybody agree?” And everybody’s like, “Yeah, whatever,” and then it’s out, right? AI would be really, really, really great for solving this particular problem. But I’ll tell you just to close this off, that the biggest interruption that I find any team has is the “Where is the problem? Where is the documentation for this? Where did we make this decision? What happened here? Why is this…?” That’s a huge problem with almost every visualization. It’s why most Kanban tools don’t work, because they don’t tell you the “after” the information.

Wiktor Żołnowski: Yeah, they usually focus on the job in progress, not the job done and the decision that was made in the past. They want to focus on you running on the treadmill constantly, not, you know, what did you learn or how did you… That’s also true for Scrum. Scrum is focused on increments and new things, new stuff, not the decision that has been made in the past. So what I found useful are roadmaps, and the roadmaps into the future, but also the history that we are mapping on the roadmaps, and then we can point out the decision that was made.

Jim Benson: Yep, I officially love you now.

The unexpected impact of remote work on teamwork

Wiktor Żołnowski: I’m blessed. Teams, teamwork, visualization, communication, information. What was the impact of remote work on all of that?

Jim Benson: It got better. It got better. That was the weirdest thing; that’s what I was not expecting. Before COVID, coders especially would always be like, “I don’t care about planning, I don’t care about this, just give me the user story or whatever and I will go do it.” And then of course they would go do it, they would be uninformed, they wouldn’t know why they were building it, they’d build crap, and then we get technical debt and then we blame the testers. As soon as we got into COVID and everybody was isolated, all of a sudden they wanted to know things. “Why am I doing this? This seems weird. I don’t…” you know, blah blah blah blah blah. And so then they wanted to be involved in planning, and then instantly the Product Owners and the Scrum Masters were like, “That’s my turf. Why are you– why do you want my turf?” And it’s like, “You do realize that you were saying exactly the opposite of what agile is supposed to be, right?” So it was beautiful for highlighting kind of the tensions in those roles that were never well defined. And so the companies that we were working with finally were able to define, “This is what we want from these roles, this is how we want people to be participating in planning, and how we want people to remember what it is that we did.” And retrospectives got so much better.

The new challenge: Forming teams remotely from scratch

Wiktor Żołnowski: Yeah, people are there, said more tensions there, and if the team or the group of people is able to pull it out and, you know, talk about it and talk through it and figure out how to solve the problems, then it’s good. But how about the new teams? What about the people who, because what you mentioned, “get better,” I also saw it, especially at the beginning of the pandemic, where people were used to working in the office and then moved to working from home. And then in the first few weeks, they figured out a bunch of great ways to work together, and that was actually awesome to observe. I remember in our company, we were thinking about standardizing it somehow, but after a few tries, we decided that it doesn’t make sense because each of our teams figured out how to do this better for themselves. As you mentioned, how they work together, they figured it out and they started working it. The problem that we started seeing was not just after the pandemic started, but two years later when new teams were assembled, new people joined the company, and starting a team became much more difficult than before the pandemic. Any thoughts on that, how to start a team remotely and how to improve this collaboration from day one?

Jim Benson: I’ll go back to construction because this is one of the things that’s interesting about construction: every project is a brand new team. So literally every construction project is a startup. It has new management, it has new team members, it’s building a new thing on a new site with new problems, a new owner, new funding sources, new weird. And so they would gather together and then they would have to launch. And so when we launched with a “right environment” exercise like I talked about earlier, we would get together and we would say, “Okay, here’s what we want to build, here’s how we want to work together, here’s what we need to know, here are the tools that we’re going to use.” And when you start, when you do a “right environment” exercise with an existing team, you’re building out that value stream and saying, “How have you worked in the past and how can we fix these things?” But when you’re working with a new team, you’re like, “Okay, what do you want to do? Right now you have this gift. You are a brand new team, you are just born and you can develop any way you want. How do you want to communicate? How do you want to make sure that you are protected? How do you want to protect other people? How do you want to onboard? How do you want to upskill? How do you want to…?” So one of the projects that we worked with was way out in the middle of nowhere, everybody had to commute long distances to get to work, so they wanted a dog. So they got a dog, but why? Because they wanted something to look forward to when they got to the office, you know, so they’re like, “Yay, a dog.” Basically, they want to be cared for, right? And at work, we’re really good at not caring for other people. And one of the things I noticed like during COVID was there were people who maybe 18, 20 months into COVID were still working on like a small laptop with one screen. And I would say to the company, I’d be like, “Could you please send everybody a second monitor so that their eyeballs don’t fall out?” And they’re like, “Well, that’s a lot of money.” I was like, “It’s $130 a person, and you most probably already have those monitors in the office that no one is using.” A couple of companies we had to like really lean on them to get them to just understand, “No, because they’re working from home doesn’t mean you don’t have responsibilities in caring for the people that you work with.” So the team needs to – the team should have understood from the beginning – if I’m going to visualize my work, I need a monitor to see it on. If I’m going to be working, I’m going to need to be able to be on Zoom over here and looking at the screen over here, you know, that type of thing. We don’t start off projects by saying, “What is the gear, what is the training, what is the support that you need to get that work done?” And when you start a team like that, they instantly have identity because none of them feels confused, cut off, or like they are acting without confidence.

What to do when teams won’t help themselves

Wiktor Żołnowski: You said that the team needs to do that, needs to think about it, needs to figure it out, etc. What if they are not doing this? What if they aren’t, and the reason is in the company culture, maybe in the leadership? So how do you approach the situation when you go into a company as a consultant or as a coach and you see that there are groups of people who should figure out how to do this, who are even told to, who are even trained to do this, but they are still not doing it? What are your next steps?

Jim Benson: Yeah, unfortunately, I haven’t found a lot of people who are trained to do these things because most people are trained to either do Lean or Agile, none of which are actually systems. They’re stuff to do that people are confusing as a system. And so when people say, “That’s not agile,” it’s like nothing is agile or everything is agile, whichever way you want to look at it. But at the moment, what is it that your group needs to do? So let’s just say for example that we’ve got a group of people and they are working in an environment that is not optimized for them to get their work done. So they’re having trouble making decisions, they’re overloaded with work, they’re building a lot of things and throwing it away and then building a lot of other things, they’ve got a bunch of technical debt, you know, all of these things that we typically see. The first thing is that the work needs to be made visual, and it needs to be made visual in its entirety. So not just a job board, not just a Kanban, not just Post-it notes on the wall or whatever, but are you visualizing your problems, are you visualizing your opportunities, are you visualizing your plan, are you visualizing any pivots that you’ve made and reasons why? Are you visualizing your goals and how you’re working towards those goals? Once those things are visual, then you can start having conversations within the team and with other people based on what’s on the wall. And yes, that wall can be a Miro board. But you’re doing it based on the visualization and not based on your asking for something. So when we as people show up and say, “I want this,” then you just look like a little kid wanting this, right? But if you show on the wall, “Look, we were doing this work, we’ve run into this problem, and in order to solve it we need to blah blah blah,” then that now becomes a kind of visual story with a logical story arc that people say, “I see where you’re going.” I see where you’re going, not I hear what you’re asking for, but I see where you’re going. Like if you listen to Jim Benson in an interview like this and then you say, “Oh my God, I need to do everything different tomorrow,” then you’re going to go to work and you’re going to tell people that and then they are going to punch you in the face. Don’t do that. But if you can start to show where you’re at, then you can have conversations about where you want to go. Visualization so far for me has been the only tool, and it doesn’t matter what country it’s in or what continent it’s been – Asia, Africa, Europe, wherever – everybody needs to see things. It’s a universal constant. So please find ways to visualize your work and don’t just visualize the easy stuff, and always visualize it by asking, “What’s the message that this is going to be delivering to people?” I’ll close with that by saying if you’ve tried Kanban and then people said, “This is boring,” and they don’t want to do it, it’s because Kanban is boring. It’s exciting for a little while because you haven’t seen anything before, but after a while, it’s just watching tickets flow to the right. When you get to that point, it isn’t an indication that Kanban is no longer necessary; it’s that your visualization needs to go deeper.

Wiktor Żołnowski: Unfortunately many, many teams or groups of people are not even there.

Jim Benson: If you can’t see your work, you can’t control your work, and if you can’t control your work, your work will control you, and it won’t control you in a nice way.

How leaders can support the creation of true teams

Wiktor Żołnowski: Okay, we know what to do. How could leaders support these kinds of actions? Leaders in the organization, not only on a team level, because when you are in the team it’s actually easy, you can start this on your own, and when you give an example, there is a huge chance that people will catch up and they will start doing the same. Most probably they will see the value in that. But when you’re an organizational leader, let’s say a manager or CEO of the company, how could the leader start this kind of – let’s call it – transformation, transition, or change?

Jim Benson: Right, so the first thing that they can do is start by transforming themselves. So in chapter 8 of The Collaboration Equation, which is the chapter on collaborative leadership, we say that leadership is a verb; it is not a role. So anybody can exhibit leadership at any time. And what happens is when we have strong leaders or people who are in a role where they see themselves as responsible for all leadership, then that stops other people from leading and that becomes a leadership bottleneck, and people are like, “No one wants to act, no one wants to do anything.” It’s like, “No, you’ve created a system now where they’re waiting for you to act.” So the first thing that anybody who is in a role of responsibility or a position of power can do is to make sure that they divest themselves of as much decision-making requirements as possible. And you can do that by trying your best to become a team member. So when we first started going off and working with companies, you know, we always wanted to create a safe space for people by making sure that leadership wasn’t in the room, and we began to see that as a horrible anti-pattern because it meant that leadership was always going to be seen as something that shouldn’t be in the room, and that’s a problem. So we want to make sure that we have built systems that take the tension out of work between the people doing the work and the people in a position of power. Again, visualizing the work means that leadership is informed regularly and then they’re no longer coming in and judging what you’ve done because they understand in real time what’s happening. And if they want to start something, then they need to go talk to people and they need to say, “Okay, we want to sit down, we want to figure out how your work– first of all, how your work flows,” basically do the “right environment” exercise. Find out how your work flows and then after that, what you need to get that work done and to care. So what I told the people at Turner when they said, “What do I need to do as a leader?” I said, “The first thing you need to do is to give a damn. You need to care, and you need to care about a lot of things that you probably don’t care about.” It’s as simple as that or as difficult as that. This is not easy. It’s simple to say, but it’s like when they call things “soft skills,” well, that’s the hard stuff. You know, the “hard skills” of planning budgets and stuff like that, that’s just numbers in a spreadsheet. But figuring out, you know, “This person’s mom is in the hospital and this person’s kid is having trouble in school and this person is doing this and this person’s doing that,” and that directly impacts the operations of my team – that’s seriously hard stuff. There’s no “soft” in that at all. That’s the leadership part.

Identifying and changing a non-supportive company culture

Wiktor Żołnowski: But the company culture is usually more than that. So what are some indicators that the company culture is not supportive of teamwork, and how to change it? I asked the easy question followed by the hard one…

Jim Benson: So the way to spot it is just to spot where information isn’t flowing. Like literally, you can spot almost immediately in any company where the fear lies just by where the information isn’t flowing. And sometimes it takes a little bit of digging to find where that information is stuck. But wherever information is stuck, it’s always because of some political issue or some person or system that is hogging either power or resources or information or what have you, decisions. And so the more of those you find, the more that you know that the knot of that project or that company is difficult to solve. But sometimes it is the CEO and you just have to recognize that. So lean is always like, “Look at the system, not the people.” Well, the people are symbiotic with the system, so you should be looking at the people. You should be looking at the people to say, “Where are you uncomfortable?” and then you know that’s where the problems are lying. And then you should say, “Where are you personally causing discomfort?” and then you also know how the system is structured. So we recently worked with a company that had C-level staff that were actively working to undermine the actions of everybody in the company. And after a while, we had to leave because that company was specifically set up not to allow positive change to happen. That doesn’t happen very often, it happens a lot less often than one would think, but it can happen. The other thing that I will note is that culture – there is no company culture that doesn’t have subcultures. So, you know, like in the late ’70s and early ’80s, we had the United States, and then the United States had kind of like the Bruce Springsteen culture, and then they had kind of the punk rock culture, and then we had the new wave culture, and then we had the heavy metal culture, and then we had the reggae culture. There are a lot of subcultures out there. And so every team can be a relatively healthy subculture in a larger culture. But your goal when you’re building your system in your team is to say, “Okay, we understand that this is our zone of control, this is our sphere of influence, and this is what we cannot change.” And so that sphere of influence is where your translation layer is, this is where your XML is, right? And then your sphere, your actual zone of control is where you can actually write your own processes, set your own culture, and those bubbles are always larger than we think they are. So don’t be afraid to define your own ways of working within your company. Just recognize that, you know, at any moment somebody could blow you out of the water.

Teamwork, autonomy, and the zone of control

Wiktor Żołnowski: I think just getting back to what you said before, that the problem of not knowing where the borders are of this autonomy sphere, not knowing that came from this lack of empowerment and lack of this supportive environment in the team and this thing that you call acting with confidence. Like if people are not acting with confidence, they will never test the borders, so they will never figure out what they can actually change within this.

Jim Benson: So that’s the beauty of a team. So if you have a real team, your team has a zone of control and sphere of influence equal to the sum total of all of the zones of control or spheres of influence of the people in the team. If you don’t have an active team, your zone of control is you. So that might be a good way for you to specifically know if you’re part of a team: if you feel like your zone of control is just what you can get done and not what the team can get done.

Wiktor Żołnowski: Quite a nice test for everyone to check if they know what their team’s zone of control is and what their zone of control is.

Jim Benson: I’m sorry if we just massively depressed a whole lot of people.

Wiktor Żołnowski: Even when I was preparing notes for this episode, I wrote down that teamwork is like teenage sex. Like everyone is talking about it, but not necessarily everyone knows how to do it and not necessarily everyone was there.

Jim Benson: So one of the things that I’ll note about that is that I kind of use The Police as a test, right? So The Police is a band. “We’re definitely The Police,” and every Police song is obviously a song by The Police. Like none of their songs sound like anything other than a song by the three of them, regardless of how much they were fighting at the time. When they went off and did other things, their music sounded entirely different, right? So Andy Summers and Robert Fripp – entirely different than The Police. Sting working with all the people on “Dream of the Blue Turtles” sounds exactly like The Police, even the songs that were covers of Police songs. And so when you go off and you build a team, the team develops its own language, its own patterns, its own systems. And so this is why one process can’t be used for everybody, because we’re unique and our collaborations are unique, and that’s a beautiful thing. And the reason that it’s hard to set up a team is because we don’t value that enough. We think that we’re just coding, and that’s not the case.

From DIY punk rock to “do it together”

Wiktor Żołnowski: Your whole history, tell us more about it. Like, how does it work for you and how did it come to be that you are here right now, not on the stage – you are on the stage. But without the guitar.

Jim Benson: So first off, like my most meaningful collaborations have almost always been doing something that is artistic, and that includes writing Personal Kanban with Tonianne. It includes making these classes right now with Modus Institute with Carl Scotland or Dave Prior. Is that when we work with other people, we build this beautiful bond. And what I noticed in 1984 when I was running around Denver trying to be a professional punk rocker was that I had two options for my future. One was heroin addiction and the other was being absurdly wealthy, and one had a very high likelihood and the other didn’t. And so I was like, “Okay, urban planning.” So but the way that that’s informed me is that when we were– the punk rock world had this DIY mentality. Everything was “do it yourself.” You know, make your own records, do this, do that, corporations suck, blah blah blah blah blah.

Wiktor Żołnowski: Even assemble your own amplifiers.

Jim Benson: Exactly, yeah, build your own fuzz boxes and the whole bit. And but what I came to realize over time was DIY never happened. It was always DIT: do it together. So me, Dave, John, Corey, Simon – when we were doing our band stuff, it was always together; there were no solo albums. So this month hopefully, but maybe next month, John from that list of people and I are going to come out with our first album in 40 years. And we are– it’s a– and like most angry punk rockers, I now do ambient music. So it’s ambient, and John plays a Chapman Stick, so it’s an ambient and stick album. So you don’t get any more pretentious than that. This all informs what I do in the– from a very, from the very beginning, there were always things to learn and there were always more things to invent. And when we give up our ability to define how we relate to the people that are in our band, then we just end up a cover band. We end up playing other people’s music. So people right now are running around, you know, playing a whole lot of Ken Schwaber music, or they’re running around playing a whole lot of Dean Leffingwell music, or they’re running around playing a whole lot of Dave Anderson or Jim Benson music, but people aren’t playing enough of their own music. And that’s what I want to see for the balance of my career, which you all got to hurry because the gray is showing up. But that’s what I want. I want more people to come out with their own Management Systems and recognize that the management system is nothing more than how you relate to the people that you work with. And if you care about them and you care about yourself, you’ll care about that.

Wiktor Żołnowski: I think this is an awesome analogy to everything. Like, you know, there are the same notes, there are the same scales that people can use, but they can, based on that, create something new and some more innovative stuff and implement it and use it, and other people maybe will like it or not, but they will do this for themselves in the first place.

Jim Benson: No, 100%. And that’s why sampling has been so interesting. So if you sample an entire album, that’s called plagiarism, but if you take a little bit of this song and pop it into that song, it’s being inspired by a riff or a piece of music, and then it’s repurposing it to fit into a new piece of art.

Beyond Tuckman’s model: The stages of a team

Wiktor Żołnowski: Okay, let’s get back to the teams, but also to the bands. You mentioned The Police and how they were fighting each other all the time. So, like, most people who are watching it are most probably aware of the Tuckman model of a team (norming, forming, storming, performing). It’s already been proven wrong; like, there is not a cycle, but there are stages. But what about your perspective on teamwork, on teams? Do you also see some kind of states or stages that teams are in when they are forming or when they are working together?

Jim Benson: Yeah, so forming is the easiest one because it is the most universal. So then you can have like forming, confusion, exploding, poisoned, in the ER. That could be forming, getting excited, going crazy, completely losing track, becoming disillusioned, blaming the problems on everybody else. But ultimately what I see is this: teams get together and they’re made up of people who actually want to get work done, and then we don’t take the time to figure out how to get that work done, and then it doesn’t, and then the team falls apart. So it could be that you run into straight-up personality conflicts like this Sting versus Stewart Copeland legendary personality conflict, and that’s a thing. That’s what humans do. You know, some people get married and some people get divorced, right? So we can’t expect that we’re going to follow some sort of magic pattern and every team is going to work well together. When I was in the early– or all the way through the ’90s, I was part of the NAMES Project AIDS Memorial Quilt. I managed a big part of the quilt from when it fit in a small basketball court all the way up until it was 50 square miles of quilt. And by the time I left, I was so burnt out that everyone hated me. Like if I would have left in ’94, they would have built, you know, big statues in my honor. But I didn’t. I waited until like 2000 to leave, and by then everybody literally hated me because I was a dick. So we have to recognize at certain points that sometimes our team’s structure needs to change based on different changes in the system. So it’s just like, you know, you start a startup, you need a certain type of team, and then after the product actually becomes something that’s going to go to market, you need a different kind of team. So understand the team composition. So we can switch from bands to like League of Legends. So from bands to video games, team comp. If you’re running a certain type of a strategy to win a certain type of collaborative online video game, you want different folks to be involved with different capabilities. So those things can change. So, you know, you can’t necessarily blame Stewart Copeland for being Stewart Copeland or Gordon Sumner for being Gordon Sumner.

Wiktor Żołnowski: Was that an answer? Yes? You want to ask it again and maybe I’ll answer in a different… Yes, yes, that was answering the different stages of a team and different conditions that the teams are or should be. So yeah. So what about the culture fit? What about the recruitment to the team? What’s the impact of recruiting new people to the team and how to design this process?

Jim Benson: Well, that’s a huge challenge, and it’s a huge challenge because when you define the type of person you want, then you tend to go out and you hire either that person or someone who looks like that person, and then you miss the weird person that could have made things a lot better. When William Rowden and I had Grey Hill Solutions, we would hire people by having them come in, we would go to coffee with them, and then we would ask them, “Tell us a story of an incredibly horrible thing that happened to you and how you got out of it.” You know, “What was your favorite work experience?” or something like that. And so what we would be looking for is: does this person know how to creatively solve problems? We didn’t care if they could use, you know, if they were .NET certified or anything like that. You know, we cared about, “Can you solve a problem?” And what we found was we ended up hiring really weird people who could do really amazing things and they didn’t fit any kind of model at all. So we had like one guy who was like super Asperger’s named Ed, and he was so awesome, he was so awesome; our company never could have continued without him. We had Alan who was super shy but super good at problem-solving. It was amazing; like, we were seriously like a bunch of Muppets. Like none of us looked alike, we were so bizarrely different, and it was because we hired based on that and not based on – oh, this is going to really piss people off – not based on product-market fit. So I would really caution people when you’re going to look for folks, look for folks who, you know, who match your needs. If you need a marketing person, don’t get someone who can just solve problems because then you’re hosed. But hire a marketing person, but make their ability to tell a story like a hallmark of why they’re hired, because they’re the ones who can explain things, who have dealt with something in their lives and aren’t just a certification or set of certifications.

Wiktor Żołnowski: Does that make sense? Why not? If it works, if it works, yeah. If you provide examples that that was working for you, then that… I also remember that the team that I mentioned at the very beginning, one of the first real teams I was working with, was actually very diverse as well. There were people who were, you know, like also an Asperger’s guy who was, you know, also in everything what he was doing, like an expert; another guy who was like a true born leader; another guy who was just a funny guy who was, you know, cheering us up and, you know, always had something funny to say, and that was improving the morale; and a few other people who were totally different from each other. And actually, with most of them, I’m still in touch, I still have contact and good relations, and some of them are my best friends. So that worked really well. I think that’s another lagging indicator of a good team: the length of time that you stay attached to the folks.

The role of technology and AI in supporting teamwork

Wiktor Żołnowski: So with those people, we are spending vacations together, we are meeting each other pretty often despite that we are living in different countries right now even, so that survived the proof of time. You already mentioned about AI and how AI could support teamwork right now. What about technology at all, including AI, in terms of supporting company culture creation or shaping the company culture and also shaping teamwork and helping teams to work together? Any thought on that?

Jim Benson: Oh yeah, and a very opinionated, snarky thought on that. So I’m going to try and avoid those. What I will say is that should anybody be listening who has massive access to a VC bankroll, I have fully designed what the future of business management should look like for a new online product. But from what we have now, I don’t believe that any team can exist without a good information repository, without some ability to visualize at the very least the flow of work if not a full-on Obeya, like I talked about. And that our biggest problem right now is that we have too many tools that have all been partially deployed. So almost every group that I go into has two or three ways to chat. They have two or three places that they’re storing documents. They have two or three places where they’re making or storing decisions. They’re probably using both Mural and Miro. And so what happens is people lose information. So the information infrastructure is so diffused that people don’t know that it’s causing its own operational confusion. Like we talked about before, current systems do not come with any set of expectations about who is going to update them or how they’re going to be used. They expect the user to figure those things out, and absolutely no one is trained in building overall communication systems for a team. So what I would love to see people do with their technology, which is of course again part of the “right environment” exercise, is to sit down and figure out what you need to know, where it should go, and then make an agreement that you’re going to stick to that. And then if you don’t, there’s an expectation that somebody will raise a hand and say, “We have now broken our own rules and we need to go back and look at how we’re sharing data.” I’m not saying anybody should over-document, I’m not saying you should over-track things. But the more questions you ask, the more it indicates that you’re not using a tool appropriately to store or distribute that information for you. The last thing that I note is John, the guy I’m doing the album with, he’s also working on a couple of AI projects with me. And one of the things that we did is we use an LMS for our online school. And so the first thing that he did was he went out and got all of their documentation online or otherwise, dumped it into an LLM, and created a bot just for us to ask so that we never had to ask their support people anything. So we’re underutilizing our knowledge bases right now when we could very easily build these microbots just to help us, you know, ask in real language questions and get information back.

Wiktor Żołnowski: Pretty smart, I would say, and right now, even basic. Like, you know, it’s something that almost every organization that has any kind of documentation, any kind of knowledge base, could do the same pretty easily.

Jim Benson: They could. But like the other day, with T-Mobile, I had a question for T-Mobile because I used to have global data roaming and they took that away. So my question was basically, “How do I get global data roaming for this trip that I’m going on?” And I had to call because their bot was just like, you know, “Can I drive you to sales? Can I drive you to this?” It’s like, no. And I actually got annoyed. I was like, “You’re T-Mobile, you should be able to have a T-Bot, and T-Bot should be able to answer any question that I have about any phone at any time.”

Wiktor Żołnowski: Well, their bot is still like 2020, not younger. Okay, so the last question. So where to find you, where to find more information about you, where to find your books, and where to find your new album?

Conclusion and where to find Jim Benson

Jim Benson: Yeah, that’s right. So, me, I’m most easily found – I’m Jim Benson, very easy name, painfully boring name – on LinkedIn. So if you just go to LinkedIn, type in Jim Benson, I’m going to be your first Jim Benson more than likely. Our online school is at Modus Institute (modusinstitute.com). And there we teach all about visualization, visual management, basically the stuff that comes after agile or the stuff that comes after lean or, if you want to think of it a different way, comes before it – the things you need to make agile or lean work. And The Collaboration Equation is the most recent book. The new album is going to be called, we think, “Pivots,” and it should be on Spotify by, we’ll just say, August 1.

Wiktor Żołnowski: I think that this video will be released somewhere around the beginning of August as well. So I will put the link to the album in this.

Jim Benson: They’ll be Jim Benson and John Vonner.

Wiktor Żołnowski: And awesome, awesome, “most pretentious album ever.” Perfect. Okay, thank you, Jim, for joining us today. That was a great morning on Thursday, the first day of the Ace conference. I cannot wait to see your keynote today in the afternoon. So thank you very much, and thank you to all of you for watching this episode and listening to it on Spotify and Apple Podcast, and don’t forget to subscribe to our YouTube channel as well.

Wiktor Żołnowski: Thank you. Pragmatic Talks is delivered to you by Pragmatic Coders, the first choice software development partners for startup founders. Be sure to catch all new episodes, subscribe to our YouTube, Spotify, or Apple Podcast channels, and if you are thinking about building your own startup or struggling with product development, contact us and find out what we can do together.