It’s impossible to please everyone in an organization. If someone comes to you with a reasonable-sounding request, such as to move a tester or a developer to a project, you need to examine whether the request is actually so reasonable. Management is not about being nice to everyone all the time. Much of management is about saying no when you have to. Johanna Rothman gives you some advice.
“Sally, I need you to stop testing on this project and move over to Dan’s project.”
“Are you serious, Ben? I just got here a month ago. I just started to learn what’s going on. I finally have the trust of the team. I haven’t worked with these guys before. I found a nice, juicy bug last week and proved my value to the team. Why would you ask me to move now?”
“I need to staff Dan’s project with testers and you are my only available tester.”
“I’m not available! What are you going to do in a month? Move me back here? Heck no, I won’t go. No.”
Sally thought for a few seconds.
“Wait a minute. You’re always going on about the project portfolio. So, which project is more important? This one or Dan’s project?”
Ben tapped his pen. “Well, this one. But Dan really wants a tester, and you are so good, I wanted to put someone on his project.”
Sally brightened and said, “OK, this is easy. Just tell him you don’t have anyone. I’m your most senior tester, and I can tell you that you don’t have anyone.
“Let’s review the project portfolio and where everyone is assigned. It’s right there on the wall. Everyone is assigned for the next two months, the next four iterations. Are you managers going to change the project portfolio before then?”
Ben sighed and said, “No, we aren’t.”
“Well then, what’s the problem? You just tell Dan no. That’s not so hard, is it?”
“Well, it is. I hate to disappoint people.”
“Ah, that’s the problem,” Sally said. “You want to be a nice guy. Well, tough. You’re a manager now. You don’t get to be a nice guy all the time. You have to take a stand. You negotiate with people at the project portfolio meeting, right?”
“Yes, I do.”
“And you go back and forth and horse-trade, right? You make the tough decisions about which projects are most important, right? You decide which projects to staff and not staff, right?”
“Yes, I do.”
“And did you tell Dan at the most recent project portfolio meeting that you didn’t have any testers?”
“Yes, I did.”
“So, why is he bugging you now? Did he think you magically conjured testers out of thin air? Now, that would be a good trick.”
“Well, I think he was hoping my priorities would have changed.”
“Have they?”
“No. They follow the corporate project portfolio.”
“Well, tell Dan to go pound sand. Nicely, of course. Tell him no.”
“But he needs testers.”
“Of course he does. He has developers who will have to take the place of testers. Or he shouldn’t have started the project. But that’s not your problem. Did you explain to everyone what would happen if they started a project without testers?”
“Of course I did!”
“So Dan only has himself to blame.
“Your job as a manager is to protect us from moving around like chess pieces. You and I have had this conversation before. You know that it takes awhile for people to build solution-space domain expertise. If we get pulled off a project and put on another one, we can’t become a part of the project team. We don’t learn the product adequately. It doesn’t matter if we’re testers or developers or business analysts—if we don’t know the risks, the idiosyncrasies of the people, or the product, we can’t be successful.
“So, what are you going to do, Ben?”
“I’m going to tell Dan no. But I’m not going to tell him to pound sand—this is why I’m the manager and you’re the tester, Sally. I have a few more skills in being polite.” Ben smiled.
Sally laughed and said, “Go for it. I’ll go back to testing now and see what other evil bugs I can find.”
Managers Can’t Please Everyone
It’s impossible to please everyone in the organization. If someone comes to you with a reasonable-sounding request, such as to move a tester or a developer to a project, you need to examine whether the request is actually so reasonable.
Management is not about being nice to everyone all the time. Much of management is about saying no when you have to.
Know What Everyone Is Doing
If you don’t have a department-wide project portfolio, at the very least, create a project portfolio for your group so you can assign people to projects and keep them there for a while. How long is “a while”? I like to keep people on the same product for at least a year. It seems to take people in many organizations a good six months to understand the guts of a product. And if you have a geographically distributed team, it could take that long for a team to jell. If you’ve invested that much time in learning, you want some return on your investment.
Once you know what everyone is doing, invite other employees to see how you’ve assigned people to projects. The transparency will help reduce the number of out-of-band requests. Why? Because people can see when they can ask for changes in the project portfolio and changes in assignments.
Once you know what everyone is doing, you can assess the requests, even if those requests occur between project portfolio meetings. If you only have project portfolio meetings once a year at funding meetings, you will have to manage your project portfolio yourself for your group. In that case, keep your people on their projects for as long as possible so they develop expertise. Consider developing cross-functional, standing teams that remain past the end of a project.
Flow Projects Through Teams
Once you have standing teams, regardless of your project approach (agile, waterfall, lean, or staged delivery), you will find it even easier to manage the project portfolio and the inevitable requests if you keep teams of people together and flow the projects through cross-functional teams. Then you won’t have Ben’s problem of others requesting you assign testers to teams.
You might have a problem when testers, developers, or analysts leave and you have to hire new people, but you would have that problem eventually anyway.
Capitalize on Each Person’s Individualities
People are not chess pieces—we are not fungible. Everyone brings different strengths, capabilities, and perspectives to a project team. Instead of treating people as if they are chess pieces, treat them as the unique individuals they are and you will gain much more from your teams.
Read more of Johanna's management myth columns here:
- The Myth of 100% Utilization
- Only the 'Expert' Can Perform This Work
- We Must Treat Everyone the Same Way
- I Don't Need One-on-ones
- We Must Have an Objective Ranking System
- I Can Save Everyone
- I Am Too Valuable to Take a Vacation
- I Can Still Do Significant Technical Work
- We Have No Time for Training
- I Can Measure the Work by the Time People Spend at Work
- The Team Needs a Cheerleader!
- I Must Promote the Best Technical Person to Be a Manager
- I Must Never Admit My Mistakes
- I Must Always Have a Solution to the Problem
- I Know How Long the Work Should Take
- I Must Solve the Team’s Problem for Them
- I Can Move People Like Chess Pieces
- Management Doesn’t Look Difficult From the Outside, So It Must Be Easy
- I Can Compare Teams (and It’s Valuable to Do So)
- It’s Always Cheaper to Hire People Where the Wages Are Less Expensive
- If You’re Not Typing, You’re Not Working
- You Can Manage Any Number of People as a Manager
- People Don’t Need External Credit
- Performance Reviews Are Usefult
- It's Fine to Micromanage
- We Can Take Hiring Shortcuts
- I Can Standardize How Other People Work
- I Can Concentrate on the Run
- I Am More Valuable than Other People
- I Don’t Have to Make the Difficult Choices
- I Can Treat People as Interchangeable Resources
- We Need a Quick Fix or a Silver Bullet
- You're Empowered Because I Say You Are
- Friendly Competition Is Constructive
- You Have an Indispensable Employee
