About Johanna Rothman

Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.

How Many People Can You Manage as a Manager?

In my first management role, I “managed” one person.  My managee didn’t need much management. He guided me into how to manage him more than I managed him. He saved me from making too many mistakes. It was great practice for me.

Later in my management career, I managed a “team” of 15 testers. They were not a team. They were a group. I’m not sure why my management insisted on referring to them as a team, but my managers did. My role was to match-make testers with projects.

I didn’t think of my role as allocating people to projects, because I kept people on projects long-term. I didn’t fall for the management myth that I could move people like they were chess pieces. That’s why I thought of my role as match-making. I managed the project portfolio for the test group, so I could match-make.

What else did I do with this group?

  • Conducted one-on-ones with everyone. Some one-on-ones were weekly, some biweekly. But I had a private conversation with each person at least every two weeks. I did career development with each person every two weeks at these one-on-ones.
  • Conducted a weekly meeting where everyone in the test group would learn something. This was a community of practice meeting. Sometimes it was about technical practices. Sometimes it was about tools. Sometimes it was about project management techniques. The group decided what they wanted to learn. I greased the skids and facilitated their learning. People took turns presenting something. Yes, I did too. Sometimes, we invited other people across the company to present. We had a long list of things to learn.
  • I made sure everyone knew what everyone else was doing. But not with a serial status meeting. Gah. I took people’s email status to me, collated it, and emailed it to everyone. If anyone was interested, they could read it. If not, they could trash it. The idea was that since they were all working on different projects, they might discover things each other might want to know. I knew I was no longer technical enough. I could not solve their problems for them. I could facilitate their problem solving, if necessary. I provided information. They could follow up.
  • I made sure that the right people were invited to the right meetings. This was more difficult than it sounds. I did not want to go to all the meetings. But I was invited. I had to get uninvited, make sure the right testers were invited, get off the email list, and make sure the testers were on the list.

I’m sure there was more, but that’s what I remember now.

I recently met a smart CTO of a company with about 100 engineers. He said he wanted a flat organization. Makes sense to me. Then he said this, “Every engineering manager should be able to manage about 15-20 engineers, and the projects that they work on, too.”

Oh, boy. You will notice that I was not managing projects in my list above. I was hiring like mad, in addition to the above management responsibilities, and I was full. I could not do any more. If you’d asked Mark, I bet he would have said I was past full. I did all my phone screens after dinner. When I needed to, I also wrote reports after dinner. I had no time during the day.

Could I have done any useful project management? No. Could I have managed any more people? No. Certainly not up to 20.  Why? Because I needed time to meet with everyone, some people each week.

Why could I manage 14 people? Because I was an experienced manager by this time. I’d been practicing. First with one person. Then with three or four. Then seven, eight. When I had nine people in my group, I realized I had to move to biweekly one-on-ones for some people. I asked the people who were more senior if they minded. No, it was okay. But if they were more junior and needed coaching? It would have been a disaster.

And that is the topic of this month’s management myth: You Can Manage Any Number of People as a Manager. If you don’t care how well you manage, you cannot manage any number of people and do a great job.  It’s the same principle as code or projects. If you don’t care how good the code is, you can write as much as you want. If it doesn’t have to work, it doesn’t matter. If you don’t care how good your project management is, you can manage as many as you want.

I’m not talking about micromanagement. I’m talking about providing coaching if the other person wants it, a learning environment for the people, a place for people to learn, a trusting relationship with each person every week. That’s it. I expected the people in my group to spend the rest of their time learning on their own and being responsible.

But because we were hiring, and because I had responsibilities across the organization, we were all busy. If I hadn’t made time for our one-on-ones, I could have gone for weeks, not seeing people. That would have been Wrong.

If you are managing more than nine people as a manager, rethink what you can do. If you are not having one-on-ones every week or every other week, what else are you doing?

Management is not about micromanagement. It’s about creating an environment in which everyone can do their best work. If you are too busy to do that, are you really managing?

Go read Management Myth 23: You Can Manage Any Number of People as a Manager.
 

Related Whitepaper:

The Principles Of Project Management

Learn how you can deliver projects on time and on budget, again and again.

Every project you manage will be unique. Scope, budgets, team dynamics, and timeframes will differ. As a project manager, the most important factor in achieving project success will be your understanding of The Principles Of Project Management. This book will show you that project management isn't rocket science.

Get it Now!  

Leave a Reply


5 + = fourteen



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books