The Testing Show: New Thinking In Management

Panelists:

References:

• Johanna Rothman (LinkedIn)
• Tom Demarco & Timothy Lister – Peopleware: Productive Projects and Teams
• Modern Management Made Easy, a Three-Volume Set
• Seth Godin: Linchpin: Are You Indispensable?
• Value-Stream Mapping

Transcript:

Michael Larsen (00:00):
Hello everybody. And welcome to The Testing Show. Glad you could be with us. We are recording the show on Monday, January 25th, 2021. So, early days in the year just yet, in a year, that has been remarkable already. We will not belabor that point. We will get right into the meat of our matter and especially welcoming our guests, which is Ms. Johanna Rothman. Welcome.

Johanna Rothman (00:25):
Thank you so much. I am delighted to be here.

Speaker 1 (00:29):
And of course, Matt Heusser is our host, so I will let him do his thing.

Matthew Heusser (00:35):
Thanks, Michael. Welcome, Johanna. If you don’t know Johanna Rothman, I’m not even sure where to begin. She’s…

Johanna Rothman (00:44):
Let me, let me just interrupt you right there. There are plenty of people who do not know me. Let’s just get that out there. Plenty. Plenty of people. I am not the kind of person that when we are able to travel again, will actually say to an airline employee, “Don’t you know who I am?” No, they don’t know who I am. It’s fine (laughter).

Matthew Heusser (01:03):
Well… but I just don’t know where to begin. So I’ll tell you where I met Johanna Rothman. It was at a Better Software Conference in 2005. I took an all-day tutorial with her and she spoke about leadership and management in a way that was deeper than any that I had seen explained to me face to face prior. I’d read books. I think DeMarco and Lister’s “Peopleware” is fantastic, but when it came to people, I was actually interacting with on a daily basis. I got a lot of aphorisms and cliches and Joanna worked heavily with Jerry Weinberg when he was alive. I think you were a co-moderator of the Problem Solving Leadership Workshop and some of the best leaders I know came out of that workshop, the conference chair for the Agile conference, the big show that 2000 people show. I’m just getting started. So Johanna, what should people know about you?

Johanna Rothman (02:04):
The one thing people need to know about me is that I am all about practical ways. Pragmatic approaches, not necessarily “by the book”. If we think about how do we make things work in the organization? That’s my sweet spot.

Matthew Heusser (02:22):
You have published a number of books over the years. There’s three new ones. How to Manage Yourself, How to Manage Teams, and then How to Lead in an Innovative Organization. That’s kind of what we want to talk about today, maybe with a testing angle. And I’m going to assume a frame. I’m going to project a view of the way things should be in order for you to respond to it. Someone once said that the best way to learn something on the internet is to present an answer you know is wrong because then people will correct you. So let’s start there; management. It’s not very hard. It’s pretty easy. You figure out the work, you slice it up into small pieces. You give it to the people that work for you. And then you check every now and again to see if they’re done. If they’re not done, you figure out what their problem is. They figure out how to fix it. And if they are, you give them new work, you just keep slicing and dicing and passing around. That’s it, right? This is… what did we need a book for?

Johanna Rothman (03:18):
(laughter) Yeah, that might have worked in manufacturing at some point in the way distant past. It’s never really worked for knowledge work and it definitely does not work now. The more we want agility in the organization, the more we need to delegate problems and outcomes, not tasks. So when we change our frame from slice and dice into tasks to delegating a problem that you might not know what the solution is. You might think you know what the solution is. It’s probably not what you think. That’s the best kind of delegation. I find that still challenging and I’ve been practicing for a very long time. I am sure that many, many other people in management positions find this challenging. And often that’s because we were promoted into management because we were excellent technical contributors. And the more we excelled at technical contribution, the more we think we understand the problem to solve and the solution that that problem needs. And that means we think we can slice and dice, but this business of slicing and dicing and giving people information on the basis of the need to know, none of that actually works. Not if we want coherent solutions for our customers.

Matthew Heusser (04:52):
I noticed you recommended a subtle change in the way we even use the word. So the title of your book is how to lead and serve others and manage is in parentheses. So it’s really about leadership and service. Again, let me ask in the same way, what are you talking about, service to others? They’ve worked for me. I’m the manager. They do what I say what’s that about?

Johanna Rothman (05:18):
I have found that we have adults working in our organizations. These adults are quite capable of getting themselves to work pretty much on time, fed and closed, enter into long-term contracts with either a mortgage or rental agreements. They have marriages and children. Why did we need to manage them, specifically? Why not manage the system? And that’s about leading and serving. Now there’s a bunch of stuff written about servant leadership. And I find a lot of it has religious overtones. That really turned me off. If that works for you. That’s great. I tend to separate my religious beliefs and practices from the work I do. And maybe I’m a little strange. Okay. We know I’m a little strange. That’s not the issue. I would prefer to leave religion out of the workplace. Why can I not not lead in serve people by explaining to them, what is the overarching goal? What is the purpose? Why are they here? Why are they doing the work that we need them to do? How can I create an environment that allows them to do that work in the best possible way? I create environments differently for different organizations because every organization has its own culture. But the more we think about what can I do to smooth the path for these people instead of slicing and dicing work for them and telling them what to do, giving them way too much to do in any given time. If I can say, how can I clear a space for them to do their good work? They will probably do a great job.

Michael Larsen (07:11):
So if I can step in here for just a second, I remember kind of three things that were told to me many years ago regarding what it took to be a good manager. The first thing is note the lay of the land, be the headlights. They should have a clear idea of the direction. And if they don’t necessarily have a clear idea, they know where to look. Number two, get any kind of friction off of the path. In other words, if you’ve got jerks that bog up the system, the manager’s job is to deal with the jerks, get rid of them if at all possible. And the third thing is once those two things have happened, get out of the contributors way. Now, here we are in 2021. How well does that stack up today?

Johanna Rothman (07:59):
Oh, I really liked those. Those are great. Beause that first thing is to clarify your purpose. What is the goal of this work? So that business with the jerks, there are jerks in the team. There are jerks in management. There are jerks everywhere in the organization. They might think that you are also a jerk.

Michael Larsen (08:20):
That’s a fair point. (laughter)

Johanna Rothman (08:22):
Yeah. This often occurs when people do not have the same overarching goal, the headlight business is about clarifying your purpose. There are seven principles in each of the books… well the same principles applied to the various contexts. The fourth principle is “seek outcomes and optimize for an overarching goal”. When people are jerks to each other, I often discover they do not have an overarching goal. Especially if it’s managers. Manager A says, “please go here, off to the left”. Manager B says, “Please go there, off to the right.” Manager C says, “Please go up.” Manager D says, “Please go down”. We are not all contributing to the same goal. This is so frequent. It’s just… Oh, I still find it. So irritating. Sometimes we have un-gellers in our teams that can be as a management team, as a feature or a product team. Doesn’t matter. I often discovered that we are missing this overarching goal. Now, some people are just jerks. Isolate them, fire them, send them to a competitor. Any of those things is excellent, but let’s first make sure that we understand where are our headlights going and what is the overarching goal that supports those. And then I believe that the third thing you said was get out of the way?

Michael Larsen (09:56):
Correct. Yes.

Johanna Rothman (09:58):
That’s a whole big piece of managing yourself. How can you move from being an individual contributor and expert to being the support for the team, the support for the system that the team works in, how do you get out of the middle of the work? This is a really hard thing to do.

Matthew Heusser (10:20):
I’m sitting here nodding my head, but realizing you can’t see me. If we talk about the book for a minute and how to do that, you do recommend weekly one-on-ones and you’re not a huge fan of the annual performance review. I have that, right?

Johanna Rothman (10:35):
(laughter) No, not a fan at all. In an Agile team, you might have a bi-weekly one-on-one. So a bunch of the listeners of this podcast might be testing managers who still support a test quote “team” end of quote. I suspect that those testers are matrixed into various projects. That means that the more you have a one-on-one with them, the more you can gather data or at least signals about whether or not their various teams are working well. And where did they have friction? So the one-on-one is a data gathering exercise. If you are not yet working in an Agile environment or you don’t need an Agile environment, that’s totally fine. A weekly one-on-one is still the best way for you to gather data about what’s going on in the various projects. However, I have yet to see any kind of a formal performance review, helpful. I have found feedback helpful all the time. I receive feedback from my clients. I received one piece of feedback from a manager once. And I tell the story in the book because I still am working on that piece of feedback. My manager said to me… I was a software developer, maybe a couple years out of school… and managed to have one performance evaluation in my first job. This was a year and a half later in my second job. My boss said to me, “you don’t quite complete everything. Joanna, you get to 95, 96, 97% of the way done that last little bit over the line, you know, do that”. I asked him, “Oh, this most recent project that I just finished a couple of weeks ago when he said, well, that one and the one before and the one before, and then what I said all year, and you’re late with my review and you made me wait for this really valuable feedback?” And I’m sure I actually said, “What kind of manager are you?”, Because I am the queen of the career limiting conversation. Okay. However, that piece of feedback means I started to create checklists for myself to make sure I actually finished the work. I now have checklists for every single thing that I do. You don’t have to like checklist. This is my thing, but checklists really helped me finish the work. That one piece of feedback has stayed with me throughout my entire career. It was really valuable feedback, but the performance review that went with it? That was useless. Performance reviews are about divvying up the little bits and pieces of the bonus money or the promotion money or any of the money in the organization. Performance reviews have nothing to do with performance. It’s all about money management. They are “Performance Theater”. Feedback really helps us understand what we can do. And reinforcing feedback is even better than change-focused feedback. I will do more of what you want if I get reinforcing feedback. I am not so able to change my inner self, but I can then create checklists. So I tend not to want to finish things. I get there. I can create a checklist to get that over the line. This is one of the reasons I’ve published so many books because I have the checklist. I love to start. I am fine in the middle. I can manage finishing the book, but that last little bit to publish it everywhere, to do all this other stuff. That’s where my checklists come in. Each of us has our own little things. Everybody is different. Everybody will have their own little foibles, but a performance management system, that’s really about managing the money for salaries or with a few promotions. That’s just nonsense.

Matthew Heusser (14:45):
I can’t say I disagree too much. I have a similar story where I got a “needs improvement”. And I said, have you told me all year? It was just one category. It didn’t matter overall. But did you ever give me any feedback all year that this was the problem?” And he was like, “No”. So how am I supposed to know that I needed improvement? And he was like, “Oh yeah, huh?” And then he moved that to “meets expectations” or whatever, but it didn’t improve the overall… I agree with your conclusions. So let me ask you, though. Let’s say you’re a test manager of a company that has to do annual reviews. It’s a Fortune 50 company. You are not the senior executive VP of VPing. You don’t get to decide if… you’re doing annual reviews. What can you do?

Johanna Rothman (15:31):
So I think it’s really important to say, “What is the purpose of the annual review?” If the purpose is to manage the salary expenses, you can do several things. One is to create a career ladder. I have found that so few organizations actually have valuable career ladders. What are the outcomes we want? How do we describe what people do? I have never seen people succeed or fail based on their technical expertise. I have seen people succeed and fail based on their interpersonal skills. So I really want to create a career ladder that accounts for all these interpersonal skills. In addition, the influence that people have across the team, across the organization, across the code, across the tests, to really understand what that is. I would also say if the purpose of the annual review is to supposedly create engagement, let’s talk about what engagement is in this organization. But if the purpose of the annual review is about the compensation system, I would strongly recommend people read and then bring to HR and senior leadership all the references I include in the various books. We have at least 25 years of data that says performance reviews often create disengagement. Performance reviews often create exactly the opposite reaction in the people rather than what we want. There’s all kinds of references I give people, but I think it’s really important to say, what is the purpose behind this activity? We are encouraging people to leave the organization because we are doing unuseful and unsafe work around how we reward people and how we are for them feedback.

Matthew Heusser (17:42):
So we can go to our next topic. We might have some disagreement and some things to learn from each other. There’s a transition that happens from contributor to manager and there are various different roles. One of them that I actually have some fondness for, but it doesn’t seem to work out very often, is the player-coach role, where you say, “I’m going to have some technical responsibilities and I’m going to manage the people”. Tell us a little bit about your assessment of that, Johanna, is that something we should strive to be, or is it something to avoid?

Johanna Rothman (18:13):
I think it’s possible for managers who don’t manage too many people to still be a player-coach. I offer in the books, the number of people I could manage and still be a player-coach was three. I was not able to manage even four people and still be a player coach. That’s because of where my time went in the organization. And I measured my time. I actually said, how much time do I spend on one-on-ones? How much time do I spend clearing the path? That’s eliminating all the impediments, eliminating the friction, working with my colleagues at my various levels in the organization. What do I do to support my manager? So I found that for me, I could not manage more than three people and still contribute to a project. I could with up to three people. But for me, that was my limit. I have yet to see managers who are able to manage six or seven people and still do the kind of management necessary in organizations. If the team is pretty self managing, if they already understand how to offer each other feedback and coaching, they come together and discuss the problems and the various solutions. I don’t care if this is an Agile approach or not an Agile approach, but the team manages their work and their approach to the work. Then it is possible for that team to include a very strong technical leader who was also a manager. It really depends on where you spend your time as a manager. The more you need to spend time across the organization, clearing the path for your team or for the people you serve. The less time you can use as a player-coach. This is really an, it depends question. I will tell you that my top number was three. How about you, Matt? How many people are you actually able to manage and be a player-coach?

Matthew Heusser (20:28):
I’ve had some success as a lead where I don’t have HR responsibilities. I don’t have to write any reviews. I’m not really responsible for hiring, but we’ve got the ship on-course. And hopefully it’s all the same project we’re supporting and I’m working the flow of the work. Then maybe you could get to four or five, but if you talk about the true leading and serving role, then three is probably about right. And I’d say, I’m not getting much done on the technical side either.

Johanna Rothman (21:01):
And notice that you talked about working as a technical lead. In the first book, I also differentiate between what is a technical lead and what is a manager? Not that I care what your title is, but I think that technical leads do different work and they tend to have more influence over the various technical problems and solutions versus having more influence with the people and the system. It’s not a hard and fast rule. I actually said in the books, I wish I knew what a technical lead was. I don’t know. However, I find that when we focus more on the environment for the entire team, the team’s system, we need more time outside of the code or the test. We need time outside of the product itself and more time being meta on the environment.

Matthew Heusser (22:02):
Yeah. And I think that what I would say for a tech lead is that you fill in the gaps that the team needs, and that can be a variety of things. And if it’s working, there’s no problem. And if it’s not working, it doesn’t matter what the job description says. You got a problem. There’s this mismatch of the individual and the team. I think your other book is how to manage yourself. And Michael’s been more focused on that. I think he’s got some questions on that.

Michael Larsen (22:28):
I do actually. I want to set this up with… a little over 10 years ago, I read a book that fundamentally changed the way that I approached, how I looked at doing work. That’s Seth Godin’s book “Linchpin”. The subtitle of that book by the way, was make yourself indispensable. I’ve for the better part of a decade, tried my best to operate from that principle. Yet, of course, let’s talk about chapter 13 with what does indispensable mean? And I would argue because of reading through that, I would think that your suggestion and Seth’s suggestion may not necessarily be at odds with each other, but they do mean different things. It’s one thing to be indispensable, but at the same time, if you are literally indispensable, it’s almost a death sentence in your company. Does that seem like a fair statement?

Johanna Rothman (23:29):
Oh yeah. I have worked with people who were indispensable and they had great prospects for a couple of years. And then the organization started to move away, started to evolve that kind of underlying infrastructure, the way they would approach problems. And now you move from being indispensable to being the only person who knows how to do this. And you have no prospects. You cannot move because you are an expert. The more I think about experts in the organization, I like to say “never let experts work alone”. I also greatly advocate the use of a value stream map to measure your cycle time. If you are an expert and you create delays for the rest of the system, or you have an expert who was part of the team who was a quote “indispensable” end-of-quote employee, I find that that means the work often queues up behind that person. And if the work is queuing up behind that person, they are not really indispensable. They are a blocker. I would like to think that indispensable employees are people who will learn and evolve and can support the rest of the team, wherever the team needs to go. Sometimes they lead the team. Sometimes they’re part of “following in the team”, but they are part of the team because they are indispensable in their attitude as opposed to their technical skills. A lot of HR people think having indispensable employees is a very good thing. This person excels at this one small thing over here. So we want to reward them, but that just set this positive feedback loop, where they learn more and more about a smaller one smaller piece of the pie. The more narrow your expertise and the more deep it is, the less useful you are overall to the organization.

Matthew Heusser (25:44):
Yeah, that’s… I can’t emphasize that enough. So let’s say you’re a test manager and you’re a virtual test manager. You’ve got Agile teams, your testers are embedded. You’ve got six different testers. So you pretty much have one tester on each team. And they know that system really well. That’s not good, right? You just told me that’s bad.

Johanna Rothman (26:05):
So I think it’s good for a year or two. And then I think it’s time to shake things up. I also have another guideline, which is whenever the developers change on a team, change the testers. If the developers think they can change every six months, absolutely change the tester. And I would actually ask, do you actually need a tester on every single project? Is it worthwhile saying, “Which projects are more important and which projects are less important?” And then saying, “I’m not going to staff these other three projects instead of clearly staffing testing for all six projects. I want to staff my testers on the three most important projects. Not every project is as useful and as valuable as all the others.” Why would you not assign people based on the value of the project? This is where you are clearing the decks. You are releasing the friction for the team. You are defining the purpose. You are saying, “Our headlights go here,” to use Mike’s idea of the headlights. If you have a project that just to staff, because there’s an extra team of developers, you don’t have to set that project. The people there will figure out how to test the product or the organization will recreate the project portfolio so nobody is on that project. And a couple of teams are on the three most important projects. This is where all the projects are unique and all provide different value. And I often discover that we are not thinking about the project portfolio in ways that actually make sense for the future of the organization. You might think this is a test manager problem. It’s a signal of a larger organizational problem. This is where the test manager with a question like, “Is this the most important project we’re working on? Should I staff this project at all?” You can use exactly the same questions for the project portfolio as you use for the testing project portfolio. And then you can lead and support the testers as a way to say, “Which of the three projects are most important. Should I ask all six testers did me on this one project?” That’s a useful question. You might not say, “no”, you might say “yes”. And I don’t know, this is all about what’s most valuable in the organization. This is why test managers have this really interesting job. They have to take the larger perspective of, “What is it that we are trying to do as a company. How can I support that purpose as a company?” And then even if I quote “only” end of quote, have six testers and there are six projects, how do I make sure I have the right people on the right project? It’s not so much which people have, which technical skills, because if you keep a tester on a project with developers long enough, they will develop enough skills in that particular product. But if we are not thinking about which are the most important projects, we will miss the boat entirely.

Matthew Heusser (29:34):
Thank you.

Michael Larsen (29:35):
Okay. So I actually think this would be a good time for us to maybe call it a wrap on this. I know that we could talk about this all day long, but of course everybody’s got things they need to do. And you know, we tend to try to keep the conversations tight and focused to a certain length of time. But Joanna, if anybody has questions, how can they reach you? How can they learn more?

Speaker 2 (29:56):
So everything is on jrothman.com. J R O T H M A N.com. Yes. When I got my domain name, it was fine to have a first initial and the last name and the books are all there. I’m offering more online workshops starting in Q1 and probably more throughout the year. I intend to create workshops for these books. I have not yet created them nor publicize them. That’s next on my list on Twitter: @JohannaRothman, I’m on LinkedIn, Johanna Rothman. Where else am I? I’m sure I’m several other places. I encourage people to link with me on LinkedIn to check out the books on my website and anything else I do and just get in touch. I’m always happy to have a conversation.

Michael Larsen (30:48):
All right. Fantastic. Well, Joanna, we want to again say thank you so very much for joining us and to everybody who’s been listening. Thank you for participating in this episode of The Testing Show and we will talk again soon. Take care everybody.

Matthew Heusser (31:03):
Bye.

Johanna Rothman (31:04):
Bye.