Re-Envisioning Management Through Teaming

Transcript

JOE CAHILL:

Hello everyone, thank you for joining the podcast. Today we'll be exploring the topic of re-envisioning management through teaming. We're joined here today by Johanna Rothman. 

Johanna is known as “The Pragmatic Manager,” providing frank advice to organizational leaders, managers and teams who are tackling really tough problems. She started her career as a software developer. She also worked as a project manager, program manager, people manager and consultant. 

And as a consultant and a trainer and a coach, she helps these same leaders and teams create successful teams and projects and manage the risk. So I'm really, really pleased to have her here today. We're going to explore the profile of the modern and pragmatic manager with Johanna Rothman. So welcome Johanna.

JOHANNA ROTHMAN:

Thank you so much. I am so delighted to be here.

CAHILL:

Before we get into a bunch of questions, maybe you can prime us up here and start off by sharing, you know, how your career experiences in project and program management influenced some of the insights that you're going to share with us today. 

ROTHMAN:

So, way, way back in the early part of my career, I became a project manager for a very small project. We had a mechanical piece, a hardware piece and a software piece, and my boss at the time said to me, “When will it be done?” Right, this is always the question. And I said, “I have no idea, how do I find that out?” He said, “Here's an example of a PERT chart. I want you to do a PERT chart for this project.” 

Now, back in the ‘70s, the projects were much easier. They were much smaller. I could do a PERT chart, everything was fine. And that's when I said, I really liked this part. I like knowing that I can get a picture of everything going on in the project.

And I did not control anybody in the project. What I said was, what are we going to do this week? How are we going to show our progress to our managers, to our inside sales people, to our inside marketing people. We need to show our progress. So that's what we did, we showed our progress every week. 

Now, I was not smart enough at the time to do a retrospective. I didn't even know what those were. There's a lot I did not do that, if you have an agile approach, that you would do now. But if you think about, “How can I show progress every day,” you will see that even back then we used more agile-ish approaches than we have in the interim until about, you know, 2000, 2005. So I think that the whole idea of showing progress, visualizing where we are, making small commitments, daily commitments. That's something that I've been doing for a very long time.

CAHILL:

And there's a big communication aspect in what you just said as well, keeping people tuned in. And that's often missed, but can be one of the most critical things you need to do. 

So let me talk about one of your books, your book Modern Management Made Easy. It came from detailed research and from your own personal experiences. I'd like you to share with the audience, you know, some of the highlights of that research in the book, and what you uncovered about the topic of modern management.

ROTHMAN:

So, what I realized is, we have several principles that really work for modern managers. And I find that the more we think about the principles of what works and maybe does not work, then we are much more likely to figure out how to do management in any capacity really well. 

So, the first principle is to clarify your purpose. I don't know, I mean, I've been working with projects for years and years and years as a consultant. And every so often I ask, why are you doing this project? And sometimes, the project manager looks at me and says, “I have no idea.” That's a really big deal. 

So once you understand why you're doing it, then that's a hurdle. If we can understand why, then we can use the other seven principles. Let me go through them briefly:

  • Build empathy with the people who do the work.
  • Build a safe environment. 
  • Seek outcomes and optimize for an overarching goal.
  • Encourage experiments and learning.
  • Catch people succeeding. 
  • Exercise your value-based integrity. 

So those are the principles. But if we start with why - what is the purpose - we are much more likely to get to where we want to go.

CAHILL:

Indeed, and I think some of the words we use…. Currently at PMI it’s defining the outcomes, right, which is kind of, to me, it's the same kind of an idea. So that people understand when you're done this thing, this is what's going to happen, right?  This is what, you know, impact you’ll have on stakeholders. I found that to be invaluable. 

So tell me, there's another thing of interest to me. I noticed that you point out that many managers still work independently, right? Do you have some examples of the implications of this type of behavior, and more importantly, some examples of more preferred management behaviors and how they drive value for the teams and the organizations?

ROTHMAN:

So let me start with the problems when managers work independently. And the reason they do this is because our reward systems in the organization reward for personal achievements over outcomes that require several people to achieve. 

So if you're always looking for outputs, and you get rewarded for your outputs - boy, that's really a problem! So all that MBO that cascades down, all that stuff. Even the way a lot of my current clients use OKRs, that cascade down. That does not help anybody at all. 

We see a lot about the teams - the product teams, project teams, feature teams, whatever they are, in service of a greater goal. And then we hear about the leadership team, the senior leadership team, and I have always wanted to know, what happened to all those people in the middle? They're not chopped liver. They're real people, and they need each other to actually figure out how do we deliver this thing, right? Not just in the sense of a program, but in the sense of, how do we work together for the betterment of the entire organization? And then of course there's the project portfolio team. And if they're not working together, that's a huge, huge problem. 

So, that's why I really want managers to work as teams, because otherwise you get zero-sum games inside the organization. Well, that doesn't help you succeed in the greater organization, right? And we need zero-sum games outside the organization, right? Some companies will win. Some will lose. But inside the organization, we need win-win. Boy, we have really not done that as, as an industry, for way too long.

CAHILL:

Can you give me an example so that people can understand what it looks like?

ROTHMAN:

Sure. So, I have a client that I've been working with for several years on their project portfolio process. They thought that they needed to do a whole bunch of financial-based assessment of any given project. 

And they did need an order of magnitude, right? Is this a three-month/one-team project? Is this 100 teams, couple of years, I mean, and what's in between? Right, so they didn't need a gross estimate of how many people and about how long that was necessary. 

However, because of the reward system, the managers had a really hard time getting on the same page. How do we collaborate to decide what their project portfolio was? And these are smart people, right? They're not trying to be bad people. 

So I went and worked with the HR people and I said, “The more you insist on managers having their own… their projects in the project portfolio, the less anybody will collaborate.” And I had five projects as examples, right? These five projects did not get funded, and are the basis of how you need to move to the next generation of work. 

When the HR person heard that she got this look on her face and said “oh my god,” right? So, once they change that, they were able to change how managers could work together. Now, these people had, some of them, 10 and 20 years of experience in this one organization where they had worked one way. It took them a long time to work another way.

CAHILL:

So, okay, it makes me think about agility, right? You're talking about ways of working. So let's shift gears a little bit, talk a little bit about culture and organization structures. Both those two things, the culture and org structures, they often interfere with the people aspects of micromanagement. 

Can you talk us through some of the blockers that you see and how they can limit some of the changes we have already talked about?

ROTHMAN:

So one of the big things is, how do we organize our people, right? In the past we've had a development manager and a testing manager, right, director level, VP level, whatever. But we have the development silo, the testing silo, the UI silo, the any other silo you have, and we ask people to work in cross-functional teams. 

So, good for the cross-functional teams, and even if we ask managers to work as cross-functional managers, I'm not sure that that's enough. In fact, I've seen that it's not enough. So, this notion of silo-based focus - that's really a problem in management. 

CAHILL:

Indeed. Do you see that the manager should be giving that visibility to their team upstream and downstream from where they work, right? Once people understand that, at least in my experience, I think they can see the bigger picture. Maybe some people are expert at that, but if they get a good sense of it, they often do a much better job and collaborate better. That's my experience.

ROTHMAN:

Well, and so this is an interesting alternative. What if the manager pulled out of being in the middle of the work, right? That's, first of all, very scary for managers of any stripe, right? If you pull out from being in the middle of the work, how will you know what's going on? That's the first question.

And your rewards are based on your achievement. So you're supposed to deliver this thing, even though it's not you who is delivering it. So, this is why the reward system is all intermingled with all of this.

CAHILL:

So this actually, this is in the wheelhouse of your key insight on the difference between being responsible to a team versus being responsible for a team, right?

ROTHMAN:

So think about those two prepositions, right? ‘Responsible for a team’ means the team reports to you, the team tells you what's going on. That's actually good stuff, right? That's fine. You, however, are going to take that information and you will filter it, because that's what people do, and report it out to the other people and up to your managers, and you're probably pretty good at that. 

However, if you think about turning this sideways or upside down - what if you're ‘responsible to a team’? That ‘responsible to a team’ stops at their achievements. You are then responsible to help them find the environment that they need, right? Do they need more equipment, do they need access to other people? 

You might be responsible to them to help them formulate how to create a project dashboard, and probably a briefer explanation of what they're doing and when, to other people outside the project and outside the various levels. 

So ‘responsible to a team’ is much more about servant leadership than ‘responsible for a team’. Now, can you be a servant leader and be ‘responsible for’? Yes. However, I think if you are more likely to think about ‘responsible to,’ that will change your behaviors.

CAHILL:

It's a small distinction in language, but there's a big difference in what people actually do with that mindset, right? 

ROTHMAN:

Yeah.

CAHILL:

It's a game changer. So in terms of that mindset, right, the preferable mindset to be ‘responsible to the team’, how does that actually impact the team? What’s the team start doing differently when you flip the switch on that as a manager?

ROTHMAN:

So the team is much more responsible, because you're there to support them. But you're not there to do anything on their behalf. So I find that we talk a lot about self-organizing teams in Agile conversations, and I see very, very few self-organizing teams. 

When a manager of any stripe is responsible to a team, the team can actually create its own self organization. Now the team is really free to estimate the way they need to... They figure out how to show their progress on a regular basis - as I said before, I hope every single day, and if not, at least once a week.

With that change in mindset, they are much more likely to take on responsibility for themselves, not be helpless. That totally changes how the team works. And in my experience, it's a really positive thing for how the team works.

CAHILL:

So if you're advising a project or program manager how to, like, take this on, how would you suggest that they approach this reframing? Because if it was an easy thing to do, we would all finish this podcast and snap our fingers and it'd be done. What kind of advice would you give to people to start heading in that direction?

ROTHMAN:

You will need to start at several levels. First, with the team - start slowly, and say, what is the first thing I should delegate to the team, or that I can delegate to the team that I have been doing up until now? 

What is it that I can do? Which decisions can they make all by themselves without me, where they just tell me the result of those decisions? So often, that's about estimating, that's about lab space, it's about capital equipment. 

Now, do have an unlimited budget? No, you do not. So you will have to say, I see what you want. Let me go work that issue. Right? So you work those issues on behalf of the team. But that's… it's all about being responsible to the team. 

Now, the next piece is, what do you do about your rewards? If you are still being rewarded on ‘you deliver this project or program’, you will have to start the conversation with your manager and HR to talk about how do I get rewarded for my support of this project or program instead of my deliverable, right? 

You cannot possibly deliver any project or program by yourself. Why would anybody try and reward you for that? It's what we have right now. So you need to start conversations with HR and your managers and talk about the outcomes that they really want, as opposed to the outputs, right? 

And if you say to them, “My job is to serve the people I work with, so that they become more capable,” then it cannot be my achievement, it has to be their achievement. So it's several conversations about agility, several conversations about what we reward, what we can discuss, who gets to make the decisions… 

It's a slow and steady set of conversations, and you might not get there in the first three to six months. But the more you have these conversations, and the more you start with small wins in the team, the more likely you will be successful over the long term.

CAHILL:

So let me flip the previous question onto the team member side. So you're in a team, you're listening to this podcast, you're like, “Man, I really wish my manager would know something about this.” Outside of having them listen to the podcast - maybe you do do that - but how do you influence them to start shifting their mindset?

ROTHMAN:

I'm not that big on mindset, and much, much bigger on action. So I like to say to managers, right, if I'm a team member, I would like to say, how do you feel about our experiments and learning, right? Do you, like, do you want to encourage more experimentation and more learning faster, or is that going to make you kind of nervous? 

I would actually use those words, because if the manager is honest, the manager will be nervous. So that's where I would say, if the manager says, “You know, Johanna, I gotta deliver this thing, and I feel like I'm under a ton of pressure. So, I'm not happy about experimentation and learning.”

I will say, “Okay, let's make sure we agree on the overarching goal. What's that overarching goal and what's the purpose of the project?” And then, as a team member, I would say that to the team. The manager is very nervous. Let's figure out how to do something every single day to build trust with that manager, and trust with the other people outside our management purview. 

The more frequently you deliver something and people can see it, the more trust you build with them. Back in the old days of project management, I talked about inch pebbles, one- to two-day tasks that were either done or not done. In software, I'm a huge fan of at least the nightly build, and being able for anybody to see the build the next day and work with it. 

So, what would it take for us to get to that point where we can do something every single day, and show it. If anybody comes by, if anybody asks a question, “Where are you with this?”, we can show them the build, we can show them a demo. That's an oblique way of getting to experimentation and learning, but I find that oblique ways are often what we need. 

We… as much as I would like to forge on, make the straight approach, we're talking about changing people, right? People don't like to be changed, they like to choose change. So, how do we make it easy for them to choose change? 

The way I see it is, we extend by our actions, we make it easy for them to say, “Oh, yeah, Johanna, you were not so stupid after all.” Fine, well, we'll do that more this experimentation, because I can see that you're delivering something every single day.

CAHILL:

It's the art of the nudge in many ways, right, these inch pebbles. I like it. I love the concept. 

So let's jump into the next-gen managers, right? It's always the most important topic of, you know, any of these conversations, of who's coming up in the organization, you know, they're the future, and we have to pave the way for them. So what differences, if any, are you seeing in younger professionals, you know this next gen, as they move into their, like, first management role, you know? Difference between person moving into their first management role versus people that have been managers for some time.

ROTHMAN:

I often see two kinds of managers right now in the organization. People who want to do a really good job for the benefit of the entire organization. And some people who want to do a good job for themselves. 

We see a lot of the ‘good job for themselves’, based on the reward system, right? If we look at the wins equation, that a person's behavior is a function of their performance in the environment, the environment asks them to work in zero-sum games, fine. That's what they do. 

However, most of the managers, even the ones with 20 or 30 years of management experience, I see them as wanting to do a good job for the organization, and for the people that they serve, right? So I most often meet managers who have their hearts in the right places. 

The interesting thing about some of the younger managers coming in, is that because they have grown up, essentially, in some form of agile practice, they have a whole lot more interest in doing right, not just by the organization, but for the customers. They bring the customer mindset in, and this is not to say that the more seasoned managers never do that. They have, and it's so different from what they were rewarded for for, you know, 15 or 20 of their 20 to 30 year careers, right? So they're still transitioning. 

But when we think about doing right by the customers, we then start to think about who are our customers. Are they just the people who use the product? Are they people affected by the product? What about the greater community in which we live, or the greater infrastructure or the greater environment, right? If you're doing some kind of a social network, how does that affect the culture of the world, right?

So that's when we have to start thinking about who are our customers, and when we start thinking about that, we might make different decisions. So, I'm not sure that I see a real difference in younger professionals, except that they have grown up with thinking about the greater outcomes of what the organization can and should do. 

Well, let me just take something from the current events. We see a whole lot of ransomware and security attacks on all kinds of different companies. If we are not thinking about the people we do not want to use our systems, we will leave holes in our security. This is a huge problem. We cannot just think about who we want to use the product. But how does this product affect the general external culture, and do we as a company have a requirement to think about who we do not want as users of the system. 

So I don't see this as so much a younger professional or an older professional thing. It's more, I think, it's more of the experience of using… of growing up using technology versus not using technology from the time you were, you know, two or three.

CAHILL:

Yeah, this whole notion that you're bringing up about the broader view of stakeholders for one and then I guess the additional stakeholders, you know, you don't want to be involved with is quite interesting. That last part particularly. 

And I think you see it really, as you're saying, in this generation that's coming up. They are focused on bigger things, they are focused on things outside of the world at large, social good and so forth, and we certainly recognize that here PMI. 

So, one last thing on this young professional question. Would you distinguish any, you know, any key lessons learned, and distinguish them specifically for young professionals, from the work that you've done. Maybe there's one or two things that they specifically, the young professionals, should focus on. What would you, what would you say to them? 

ROTHMAN:

Oh, I think that for young professionals, patience. I think that all of us have to have the right balance of patience and impatience. Patience with people who have not really thought about things the way you have up until now, and impatience to change some of the internal structures that keep the system in place. 

So I've talked a lot about the reward system. The reward system makes me crazy, in too many organizations, because it rewards individual achievement as opposed to what we can do as teams.

And I don't have all the answers, I really don't. I have suppositions for what career ladders we could have. I need to write a series of blog posts about different ways to think about compensation. But the more we reinforce single achievement, the worse our internal culture gets. 

So how can we change some of that reward based thinking sooner? I'm impatient about that. And that will help bring us along to think about the people we want and do not want it as users, and as a broader version of stakeholders, and how do we think about the purpose for our organization, and what's our overarching goal. 

So, I want to extend empathy to the people in the organization. So I really think it's a combination of empathy and short-term gains/long-term thinking. And really, really thinking about how we can we bring people along, rather than irritate them too fast.

CAHILL:

I get it, I think that's quite good advice for all of us quite frankly. 

I do have one last thing for you, Johanna. I know that you served as the vice chair for the Agile Alliance PMI team that produced the Agile Practice Guide a couple of years back. As you reflect back on that experience, how do you view the impacts of that work on our community. 

ROTHMAN:

So, I am totally thrilled with the impact of that work. It was a lot of work, we had to work fast. Which was fine. And because we're a very distributed team, it was challenging in many respects. However, the people on the team gave their all. And let me just say that Mike Griffiths, the chair of that team, was outstanding as the chair. He really helped us come together as a team. 

And the outcomes of that… People have gotten in touch with me and they said, a couple of them have said, “I'm a little surprised to see that you were part of this.” I say, “I don't know why.” I've been writing for ProjectManagement.com, which is now part of PMI, for years and years and years. Maybe a decade by now, I mean, a long time. And I really believe in projects.

And then some of them have said, “I did not think that this was useful until I saw your name affiliated with it, and I picked it up, and I got a lot out of it.” And I thought, “Oh wow!” If that's the only thing I had to do with it, that would be great. But I found that I learned through doing it, and I enjoyed all of the work I did with everybody on that first team, it was great.

CAHILL:

That's fantastic, thank you for your service on that. I'm glad it was a rewarding experience and certainly the outcomes for the community were substantial. I want to just thank you very much for your time here today, and most specifically for your insights. 

You know, we learned a ton, I can tell you myself, and then the audience here. We learned about the modern manager, you know, we learned about the next generation of managers that we just talked about. We learned about, you know, the mindset of overcoming big blockers in organizations. You gave me this concept of inch pebbles which I think is fantastic. I just love the language of it and what it means.

I look forward to seeing you soon. I think we're getting into those periods of time here where we actually might be able to see each other soon, so thank you again. Take care.