Podcast: Play in new window | Download

Paul [00:00:00] Welcome, everybody. Today, we are pleased to be joined by Johanna Rothman. She’s known as the Pragmatic Manager, she provides frank advice for your problems. Read her your books, blog and other resources at jrothman.com and createadaptablelife.com. Welcome, Johanna. Welcome to the podcast.

Johanna [00:00:21] Well, thank you so much. I’ve been listening to you guys and I’m really enjoying what I’m hearing.

Paul [00:00:27] Well, thanks so much. You know, one of the things that came to mind as we were preparing for today’s conversation is that you really bring a lot to the conversation around scale that’s not often addressed. A lot of people have this concept of technology teams that are like the pop culture, you know, Silicon Valley, the Pied Piper team, a bunch of scrappy developers that create this monster, but really it’s more like [inaudible], the huge conglomerate with scrum of scrums and programs and portfolios. Managing teams at that size is something that you’ve really articulated across your repertoire and it’s something that I’ve really enjoyed digging into.

Johanna [00:01:04] Well, thank you so much. I really think that the best way you can serve people who all need to serve this greater purpose that requires many, many more people in teams is to make it so that they can see the information that they need and only that they need when they need it. And don’t create these big massive meetings. Uh, big massive meetings are horrible.

Paul [00:01:31] I think that’s two pods in a row with an anti-meeting vibe.

Johanna [00:01:35] I think so, yeah.

Paul [00:01:38] We’re detecting a theme. Well, you know, one of the other things that really resonated with me is that as we talk about these large groups of teams that need to assemble with the right information at the right time, that communities of practice are a useful thought or model to assemble knowledge around. Can you talk a little bit about what you meant when you wrote about communities of practice?

Johanna [00:01:58] Sure. So especially when you have more than one or two teams in an organization, it’s really helpful if the testers get together every so often, if the developers get together and the architects get together and the UI people, cause I’m an old old programmer, I don’t know from UI. So when they get together, they get to kind of geek out about their particular functional skills and the questions that they have and all the tricks that they have learned. Learning from other people who do similar things to what you do, but not on the same product or in the same project, can really help the entire organization share knowledge. So that’s the point of a community of practice. Is there a limit to the number of people in a community of practice? I’m sure that there is. And I often find that until we get to Dunbar’s number, which is one hundred and fifty, we can probably let the people self organize to figure out, “how do we learn together; how do we share knowledge across the organization?” And if we think about communities of practice like that, that’s probably good enough.

Sean [00:03:13] Talking about Dunbar’s number reminds me of the conversation that you and I had on the airplane when we met around motivation and how important it is to long term success of teams and projects. Like, we know motivation is this really important piece, and underlying motivation is this concept of growth, and growth comes not only when you learn, but when you’re able to share what you learn, especially amongst a team and especially in this space, because this space is so young. Like we’re learning every day.

Johanna [00:03:45] Yeah. So there’s this nice notion of symmathesy, which I believe Nora Bateson wrote about and Jessica Kerr popularized in one of her keynotes or talks. And the idea is, in a symmathesy, we learn from the people that we work with and we learn with the people that we work with. So the more we can learn together and the more we think about software, and especially agile development, the whole idea of an agile community working together in small, cross-functional teams and figuring out how to do small, safe-to-fail experiments as we proceed, all this stuff is all about learning. How can we learn together? And you don’t have to like the term symmathesy.

Paul [00:04:35] I love it.

Johanna [00:04:37] Yeah, I really love it too. But there are all kinds of things that say if we hang out with people who eat well, we will also eat well; if we hang out with people who are optimistic, we will be optimistic. I mean, all other things being equal. It’s the same thing. The more we learn together and the more we have the ability to learn together, the more capability we grow in ourselves and in our team. That’s one of the reasons I really like this whole idea of a community of practice, because that increases symmathesy in the functional skills as well as a team that learns together.

Sean [00:05:15] I love it. So it’s not about forcing it, but how do you encourage it and how do you make more of it happen? And thank you, by the way, for introducing a new word to our podcast lexicon. That’s the first time that one’s been thrown out on the Product Momentum podcast. We’ll make sure to take advantage of that in our tweets.

Johanna [00:05:30] Good, good.

Sean [00:05:32] No, but it’s really, really important as a concept of figuring out how do you create this environment where people are learning and growing and they’re excited to come to work and they’re excited about the work that they’re doing. And I think you’ve kind of hit the nail on the head in terms of why we’re doing it. Because we need that symmathesy, we need that not group think, but group growth, right?

Johanna [00:05:52] Yes. Oh, that’s a really nice way of saying it, because that whole business, we don’t want yes people. Well, neither of us are yes people, and I don’t know Paul well enough, but I’m pretty sure he’s not a yes person.

Paul [00:06:07] It’s gotten me into trouble a couple times.

Johanna [00:06:09] But this whole business of, how can we explore, how can we grow together? Yeah, that’s a really big deal.

Paul [00:06:18] That’s fantastic. And you know, most of the recent things that you’ve been thinking and writing on and might even be releasing more of in the near future have been around this concept of modern management and self-management and not just in terms of incentives for teams and rewards for individuals, but just how do you create an environment where you’re fostering growth and development for those around you, for those in the community that are building the things that are being put out into the world, but also the collaboration has to come. Because one of the things that you picked up on that I’d not really thought of previous to your comment was how much rewards create a lone wolf culture. Could you talk a little bit more about that?

Johanna [00:07:02] Sure. So if you think back to what happened in school, you got graded on what you did. And the way we have organized our workplaces is that they, in my opinion, too much reflect school in that we are supposed to contribute individually and then we get rewarded individually. And if we think that we learn together as a team, we produce together as a team, how can we possibly reward people for their individual work? So let me tell you a little story. A number of years ago, I was on a team with a tech writer who was really facilitating the entire work that the team did. We would call her a product owner now, but she was, quote, just, and end of quote; this is the word she used, a tech writer. She was the heart and soul of that team. She suggested, “we should do this,” and when people could not agree, she managed to facilitate us so that we came to a conclusion, an agreement that we could all live with. I didn’t think she was just anything at all, certainly not just a tech writer. And when it came time for a bonus, the manager actually came to the team and said, “who did what? We really want to reward people for what they did.” So everybody turned and said, “she, she did all this really good stuff.” And this was not me, this was her, right. She did all this really good stuff. And she said, “no, no, no, I just managed to do the stuff that smoothed the way for everybody else.” So that was back when we really had to do something unique for her. But if I think about it now, I think it’s really important to say, could any of us have done our job without her? We actually wanted her to have more of the bonus than the rest of us got. And because we decided that, it was totally fine. But it was our decision.

Paul [00:09:08] So the team allocated their own bonus based on the collaborative output.

Johanna [00:09:13] Oh, yeah.

Paul [00:09:14] It’s an interesting concept. I’m going to leave it there. I do have a little bit of a follow question to that, which is, it seems in this case, this person, this individual, was the right person for the right job at the right time. She was uniquely talented, she had gifts of leadership and bringing things out in the people on the team that you’re describing. And the hard question now is how do you teach that? Or maybe the better question is, can it be taught?

Johanna [00:09:40] Oh, yeah. I firmly have the growth mindset, so I am sure all of this can be taught. And the question is, who recognizes the need for it? Who can do the teaching and how long does it take some of us who are slow, I’m raising my hand here for some of this, to learn? So I had to learn how to facilitate retrospectives before I could actually understand how to leave room in a meeting for people to think before they spoke. So I worked on it for years and years and years and it took me a long time. So with faster feedback, I think I would have gotten this a lot earlier. But I think a lot of it is, if we can stop with the disincentives for, literally, team-based work, then we have a lot more capability to help the team members figure out, “what do we all need to do?”

Sean [00:10:39] I love it.

Paul [00:10:40] Yeah.

Sean [00:10:40] Well, you know, at this point, with the level of people that we’re hiring, variable compensation is like an expectation. So figuring out how do you incentivize behaviors without distorting the ecosystem is it’s a challenge. And it’s something that we’re going to struggle with for many years to come.

Johanna [00:10:55] Well, I recognize that that’s what people expect and I wonder if there is a way to change their expectation to say, we have these bands of salary ranges based on our behaviors and interpersonal skills. And maybe some of them are technical skills. But to be honest, technical skills really have a half-life.

Sean [00:11:18] Right.

[00:11:18] And a lot of that half-life is very short, but we can change the people that we are, assuming that we want to and assuming that’s, I’m to say, quote, incented, and un quote. I don’t really want people to be incented to facilitate meetings if they are not interested at all in facilitating meetings.

Sean [00:11:43] Right.

Paul [00:11:44] So that’s sort of the proverbial salesperson who excels in their role at sales and gets promoted to the position of sales manager then ends up failing. So I think there’s a lesson in there for creating a path for growth, not on rails, that is intrinsic to a title or a function, but is more natural path that people want to and are able to grow in organically. Like that example you said before, it’s the right person for the right job at the right time.

Johanna [00:12:14] Yeah. And she really believed in the purpose of the product. So I think that this gets back to, how do we help people see where we are headed and why? Right, if we first start with the why, then we have a lot more possibility, I think, of having people do the right thing or the more right thing than they might have done otherwise.

Sean [00:12:37] This goes back to the conversation we had about setting up the right measurement system for products, right?

Johanna [00:12:44] Yeah.

Sean [00:12:44] I want to switch back because there’s something lingering about meetings. We started going on a path with meetings and then we switched to incentives. So you’ve written, I don’t even know how many books; I think I’d have to spend a year reading just to catch up. I read a few of them.

Johanna [00:12:59] Thank you, thank you.

Sean [00:13:00] Really pre-Agile you’ve been writing about pragmatic project management like pre- Agile taking over as the dominant methodology and framework in our space.

Johanna [00:13:08] Yeah, Manage It was my first project management book and I had used concepts of rolling wave planning and inch pebbles and making sure that you had a team that could do the work, not individuals who didn’t work together. Yeah. So a lot of my writing, even back in the 90s before the Agile Manifesto, was about cross-functional teams who could deliver something on a regular basis.

Sean [00:13:35] Cool. So on the topic of meetings, you had some pretty strong opinions about, you know, not having meetings where there’s a hundred people in the room and not really getting anything done and Agile and Scrum have disciplined us into sort of shorter, more focused, more structured, purpose-focused meetings. So one things we struggle with is, how do you know what people to involve or to not let be involved in a meeting or in a task in a project, so to speak. You know, Agile aside, or even software development projects aside, you have this thing that you need to accomplish and you need a group of people to get it done. We know that the best results typically occur when people are aligned, confident, and committed to the goals that they set out together, right. So this concept of self-organization is really important. And there’s models that have floated up. I’ve seen recently RACI and a few different versions of that sort of, “here’s a matrix, here’s a bunch of people, sign up for the pieces and parts that you want to be accountable for and responsible for,” and, you know, all that stuff. Have you found any structural things like that, in the course of your very huge career building software products, that has worked well?

Johanna [00:14:41] So I think that any of them can work well. And the way I tend to do it is not so much with framework of some sort, but to get the team in a room. And often the managers assign the functional team members to this cross-functional project team or product team, right. So we can even go there because I think that a lot of organizations work that way. So I really want to meet people where they are and what I have said to people is, “this is our goal, our purpose, our, not task in the sense of small individual task, but for these people, we will solve these problems and we will use software to do it.” And when we start to frame it like that and the team creates its own product or project vision and the team creates its own release criteria, now the team knows what they want to deliver, as a big picture, this is not the details, and the release criteria actually tell you when you’re done. Now you can say, “are we missing anybody? Do we have too many people?” I have to say, I almost never see a team with too many people. I often see in very large organizations several enterprise architects who would be really helpful if they helped the teams experiment as opposed to hand down an architecture. And I often see a lot of, especially with this notion of scrum, we have a scrum master and then a chief scrum master and then an uber scrum master. What the heck does that even mean? I don’t understand what those terms mean. If a scrum master is supposed to facilitate a cross-functional team, why would you have a chief or an uber where you create hierarchy? That just makes no sense to me at all. So I really like some kind of an effort, and when you are doing programs, this takes a lot of work to decide how you will split, and I tend to say let’s split on feature sets, which is not always the right thing, because sometimes you do need a platform, the platform is sort of the feature set, but if you think about, how can we separate on feature sets so that all the feature set for email makes sense for the email team or teams, and then they can go about figuring out how to be a part of this product, but also do their own work in releasable chunks, possibly as projects.

Sean [00:17:19] I agree.

Paul [00:17:19] Close to home there.

Sean [00:17:21] Yeah. The world seems to have a predilection towards creating more layers and middle management and it often gets less done.

Johanna [00:17:29] The books that I’m writing, I’m not sure I’m actually going to say this in the Modern Management Made Easy books, but we have way too many managers who are trying to direct the work of people and their mental places. There’s a reason for this, and the reason if we want to use an Agile approach, no longer exists. On the other hand, we have a dearth of really fine product owners, people who want to shepherd the business value of their product through all the various teams and through the product lifecycle. So I think that there is a difference between a product manager, especially for a very large program. Right, there’s this large program. A telephone is a large program, and all of the applications in it are possibly programs themselves and we need a product owner to shepherd the entire telephone or the operating system, we need a product owner for all the various applications, we need them to work together, and if we have those people, we probably don’t need as many managers directing the work of the people. And this means we have to change the entire culture of the organization. What did managers get rewarded on? What did managers actually do? How did managers work through other people? I have not yet written the product owner book; yeah, that’s coming. And this Modern Management Made Easy book, I think it’s so hard for managers to see, “where do I fit and how do I help the people I serve?” And that’s really the piece there. I think if we had more product owners, especially in large efforts, and fewer managers, we would be much better off.

Paul [00:19:18] That is a fantastic summary of my life every day. I’m a senior product manager and I have, at any given point, two or three product owners that I’m working with on teams for backlogs and roadmaps and vision, and the situation that you just described is exactly the struggle that we, and I’d imagine many of our listeners are product owners leading their teams and trying to find tactics and strategies for going through the day-to-day of getting that vision into reality. One question, this is a little bit more tactical, but just to bring it back down to earth for a moment. One of the questions that was raised when we were chatting earlier was this notion of getting away from releases and MVPs as distinct from one another. What I mean by that is, we think about an MVP, and it’s such a overloaded term nowadays, as the set of features that has to go out or is bundled together either mentally or physically or technically, and moving more towards, especially in large teams, this notion of internal releases and what I took from that was in exactly the situation you’re talking about, you have empowered product owners and you are watching them shepherd division through the business and make life better for the people who we’re building this technology for it. But they need to have chunks. You need to have a plan and get something out the door and not everything needs to go out to the world when it goes out the door. It can go just to us, and we can prioritize things, I think more effectively, when you stop thinking about everything as, “is it MVP?” Then it’s not on the roadmap, but you can have an internal release and you can have the feature that we’re building that ends up becoming part of the release but it’s just going out…I’ve heard the term “it’s going out dark” or “it’s going out…” You know, there’s some dev ops terms that create more structure around it, but that tactical notion of putting a roadmap together, not from a user perspective, which is obviously our end goal, but tactically from a release management perspective, it really helps to think about those two things as separate but complementary from one another.

Johanna [00:21:25] So I really like to think about feature flags so that you can talk about what’s done and not released to customers, but what’s done internally. I started to use this approach, and I’m sure that the term feature flag predates me. I’m sure that I am not the person who came up with it. Somebody else came up with that term. I used it back at Symbolics on my very first large program where we could release internally to ourselves every single day; we had specific monthly deliverables that everybody would agree to, and this was back when we shipped on tape. I know, I know. We were not going to ship tapes anywhere, but we brought customers in and we said, “what do you think of this?” And that was even before the beta. So we managed to get some feedback while we were working and if we had not been able to actually release to ourselves on a regular basis, we would not have been able to show anybody anything. So this business of, yeah, I mean, literally cycle time is from the time you started until the time you release it to a customer, or you release it to whatever done means, but I think it’s really important to say I’m a huge fan of cycle time and lead time. We might not be able to actually release everything to a customer when we want to, but if we release it internally to ourselves, now we can see our progress.

Sean [00:23:02] It’s becoming an important part of everything we do to be able to say that we’re done, right. Because I think that’s a big part of motivation, too that we don’t talk about enough. Like when when the team can proudly say, “we finished that,” and move on to the next thing… I mean, we’ve adopted this concept of the definition of done and being very purposeful about being done, and what does done mean? I love in your books you talk a lot about quality and what the definition of done is. So I’d like to hear about that a little bit.

Johanna [00:23:27] So when I was writing Create Your Successful Agile Project, Create Your Successful Agile Project actually arose because I was delivering a bunch of Agile workshops and people said, “I really don’t need a certification, but I really need to see, how can we make Agile work for us? We have a distributed team; we have these kinds of products; we always have to do support, not just new feature development; how do we take a product approach?” So I delivered these workshops for several years and I thought, I should write the book that goes with it. And in the workshops, people would talk about done, and then they would say, “done done” and “done done” and “done done done.” And I finally said, “look, as far as I’m concerned, done is a binary definition so you are either done or you’re not done.” I do this for the smallest possible task or the smallest possible story. I really like something being done every single day. You’ve read my writings so you know I’m a huge fan of inch pebbles, something that is done or not done every single day. And if you always have the product in a done form, then releasing it becomes a business decision. So I want to be able to release it any time; I might not want to have my customers incur the cost of updating now and updating later, but if it’s done inside, now we can see what’s going on.

Paul [00:25:00] So I’ve thoroughly enjoyed talking to you today, Joanna. I really took a lot away from our notes and chatting together, but I think the theme that I’ve heard running throughout is that, even though you’ve written a library about software, software is not the end in and of itself. It’s just a means. It’s the material that we use to improve the world and grow our teams together.

Sean [00:25:23] If I can extend that a little bit, we’ve independently stumbled on the importance of the motivation of the teams that are building the products and being connected to the work that they’re doing, and, you know, celebrating and being acknowledged and all the things that go along with keeping people super pumped. We know the best products are built by the most motivated teams. It’s like a key factor in the lifecycle. And reading your work, it’s obvious to me that you share that ethic.

Johanna [00:25:50] Absolutely. And the more diverse the team is, the better the product will be also.

Sean [00:25:56] No doubt.

Paul [00:25:57] Here here.

Sean [00:25:58] So we can keep going for days, I think. But we have an obligation to staying consistent with our podcast here. So we generally summarize the podcast by asking you a question about what you’re currently reading and what you would recommend outside, of course, of your own books.

Johanna [00:26:16] I was not quite prepared for that. Because I’m writing the Modern Management Made Easy books, I’m actually reading all kinds of management books. If I look at my Kindle app, I have 66 books in the collection called management. Most of those will be referenced at some point in the books. So I think that there’s a lot about performance and beyond budgeting. There’s a lot about flow and the human side of management. And I really do need to tell this little story on myself. I must have been twenty-nine or thirty and my husband was reading a book called The Human Side of Project Management and I sneered at it. I said, “who would need the human side of project management?” He said to me, “you do, you yourself, you need this.” And I said, “awh.” And then, of course, I started to read other stuff, and I realized, “yeah, I really do.” So there’s all kinds of stuff like that. I think almost anything by Bob Sutton, the two or three things I’m looking at right now are Scaling Up Excellence, because there’s no point in scaling anything unless it’s already excellent.

Sean [00:27:31] Amen.

Johanna [00:27:31] Yeah, if you try and scale up stuff that does not work, you will have more stuff that does not work. And The Asshole Survival Guide, not because people are mean to be jerks, but I find that people too often are, especially people in senior management positions, and they don’t mean to be, so if I can offer some suggestions to the managers who might want to influence, those couple of books are really, I think on the top of my list right now.

Paul [00:28:03] Excellent. Well, that’s definitely encouraged me to go forth and be a symmathesist.

Sean [00:28:07] There you go. I want to close up by thinking Delta Airlines for serendipitously introducing us.

Johanna [00:28:15] You were saying very nice things to an employee, and I did not let you just not talk to me about that because I so rarely see reinforcing feedback where people are doing the right thing and you pay attention to it. So I was very excited to hear that while I was next to you. So thank you for letting me kind of not let you get away with not talking to me.

Sean [00:28:38] Yeah, I was on a conference call when you sat down next to me on the plane and then when it ended, I was knee deep in this book, and you just pestered me until I spoke to you. And who knew I was sitting next to a national treasure in the Agile software management space.

Johanna [00:28:54] Well, thank you. And I wish I was a national treasure, but yeah, I’m just a person. Yeah.

Sean [00:28:59] And I think you were coming back from a consulting gig with a very large, well-known, multinational search company, which we won’t name, right.

Johanna [00:29:04] Yes, they are one of my clients. Yes.

Sean [00:29:08] So it was fun getting to know you and thank you so much for agreeing to come on the podcast. Is there anything else that you want to share or promote, like maybe your upcoming books or speaking engagements coming up?

Johanna [00:29:20] So the Modern Management Made Easy, and we are recording this in the middle of December… as for speaking engagements, I think I will be at OOP in Munich in February, so that’s my first one in 2020.

Sean [00:29:35] Great. And you were gracious enough to give Paul and I advance copies of the book, and I highly recommend it. When it comes out I’ll excited to to see them. Thank you.

Johanna [00:29:44] Thank you.

Paul [00:29:45] Cheers.