Congratulations! You’re a Manager. Now What?

When we talk to new managers, we ask them, “How many of you received management training?” Fewer than 50% raise their hands.

As an industry, we don’t do a great job of grooming managers.  Sure there are exceptions—bosses who mentor and develop the people in their groups to move into management and companies with strong management development programs.  But many new managers feel like they’ve been tossed overboard to sink or swim – without the benefits of swimming lessons.  If you’re a brand new manager, or you’re thinking you might want to become a manager, what can you do to get ready for management?  Do what you’re already doing, but practice doing it like a manager.


If you’re like many of the technical people we know, you have several high-priority tasks. You know you can’t work on all of them at the same time; you have to choose which tasks to work on when.

For instance, suppose you’re responsible for designing and implementing a series of features for ProductA (Task1). In addition, you have some bug fixes to complete on ProductB (Task2), and you’re helping to refine the requirements on ProductC (Task3).

You could just work on the tasks in the order they were assigned to you, Task1, Task2, and then Task3. Or, you could simply ask your boss to tell you which order to do them in (assuming your boss understands that all your tasks cannot be #1 priority). If you want to start thinking like a manager, though, you need to understand the strategic priority of each task. Managers need to be able to understand the work their group performs, as well as the priorities within their company and department. Armed with that information, managers can plan and organize that work so that they successfully follow strategic goals.

So you have a chat with your manager. You ask her how Tasks 1, 2, & 3 fit in with the goals of the department. Your manager tells you that the company really wants to release ProductB, because they believe it will increase revenue by 10% this year. ProductC is in the feasibility stages—top management is gathering information to see if the product is worth building. Your task related to ProductC is to help refine the requirements so the architects can estimate the work. Then the business people can look at the costs and benefits and decide whether to move forward.

After you talk to your manager, you realize that the bug fixes on ProductB are the most important because the company wants to release ProductB in two months. Marketing is hoping to decide on ProductC in the next month. Your work on ProductA is not on the critical path, so it’s okay if you spend time over the next two weeks to work on ProductB and ProductC. That means Task2 is your highest priority, followed by Task3, with Task1 bringing up the rear. You were assigned tasks in a certain order, but you won’t complete them that way because the assignment order doesn’t support the strategic goals of the department.

As a techie, you looked at all the work on your plate and understood the priorities among your tasks. As a manager, you will need to look at the overall goals of the group and how each person’s work supports those goals. You may decide that some work should be phased out because it doesn’t support the long-term goals of the department.

 Plan and Organize Your Own Work

Once you know what work you need to focus on, you can break the work down into manageable chunks— small pieces that you can finish in one to two days —and think through how you will know each piece is complete. Our experience is that tasks that are bigger than one or two days have a tendency to slip.  If you feel that you can’t break a task down into one-two days, you may not understand all the components of the task yet.  Your first task may be to delve into the task just enough to understand what the main components are, so you can break it down further.

Next, estimate the work—add all the chunks together to create one estimate for the assignment. Make yourself a schedule. It doesn’t have to be fancy; it can be a sheet of paper with the days of the week across the top and the tasks you intend to accomplish in each column

Improve your estimating and scheduling by tracking how long tasks actually take, and what factors made them take more or less time than you expected. If you know why some tasks took you longer or less time, you can modify your future estimates.  The more accurate your estimate, the more valuable your estimate is to your manager. When you hone your estimating skills as a technical contributor, you’re preparing for the day you’ll need to coach a newbie to learn this skill. Some people are naturally good at planning and estimating. If you’re one of those people, work on articulating the process you use. The more you can describe the steps, the easier it will be to
teach someone else.

As a techie, you need to work with manageable chunks so that you can predict when you’ll be done with each piece, and so you have a yardstick to measure whether you’re becoming stuck or the task was bigger than anticipated. When you realize that something isn’t going as planned, you make choices… I’ll work an extra hour to finish up this task, look for another way to accomplish the work, get help from a colleague, or let the downstream person know there’s a delay.

As a manager, you’ll need the work defined in manageable chunks for similar reasons: to track progress and have warning that the schedule is slipping or part of the project is more complex than anticipated.  In many ways, the process is the same. Though as a manager, it’s more likely you’ll be talking to someone outside your team to discuss options rather than another team member.

Give Effective Feedback

In What Did You Say? The Art of Giving and Receiving Feedback, Seashore, Seashore and Weinberg define feedback as ” information about past behavior, delivered  in the present, which may influence future behavior.” Some people think that feedback is the sole province of managers.  But really, we all need to learn to give feedback effectively.  If you’re just practicing for management, you won’t have a formal responsibility to provide feedback, but you can practice your feedback skills with peers. Imagine this situation:

Jen and Kelly are cube mates who work on different schedules.  As a result, Jen is concentrating just when Kelly gets back from lunch and answers her voicemail.  On speakerphone.  With the volume up.  The beeps, prompts, and clicks of the phone system intrude no mater how deeply Jen was concentrating. By the time Kelly’s done listening, what ever Jen was concentrating on has gone out the window.

Jen tried to tell herself Kelly’s high volume voice mail habit was just a small thing and that she should overlook it.  But it kept bugging her. She noticed that her impatience with Kelly’s voice mail habit was spilling over into her other interactions with Kelly.

Finally, she decided she has to talk to Kelly about it.

Jen knows that she wants two results from her feedback: to keep a good working relationship with Kelly, and to not be interrupted by Kelly. Jen thinks of three specific occasions in the last week when Kelly used speakerphone to listen to her messages. Jen imagines that Kelly has no idea that the speakerphone is interrupting her work. If she just explains it to Kelly, Kelly can pick up the phone instead and the problem will be solved. Once Jen has worked out what she wants to say, she approaches Kelly.

“Kelly, there’s something that’s bothering me. Is this a good time to talk?”

Kelly says it is, so Jen continues.

“I have a hard time concentrating when you listen to your voice mails on speakerphone after lunch. All the beeps and prompts break my concentration. Would you please pick up the phone to listen to your voice mails so I can stay focused?”

Kelly is surprised. She had no idea that it bothered Jen when she listened to her voice mail on speakerphone. “Oh, of course I will.”

By providing specific feedback in a constructive manner, Jen accomplished her goal of maintaining her good relationship with Kelly, while ensuring fewer interruptions.

Now let’s look at a management feedback example. Managers give feedback to provide information and give choices about more effective work behavior. Here’s where management feedback is different from peer-to-peer feedback. As a manager, you’re responsible for your group meeting their goals. If a member of your team isn’t doing her work, or is doing it in a way that interferes with other people doing their work, it is your obligation to give feedback and work with the employee to address the issue.

Suppose Felicia, a member of your team has checked in code that breaks the build three times in the last four weeks.  It’s time for you to talk to Felicia about what you’ve observed, find out what’s going on, and engage Felicia in problem-solving to change the pattern.

Start by clarifying to yourself the result you want.  Then talk to Felicia about what you have observed. Stating just the facts, ma’am, not your interpretation of the facts. See if Felicia can shed some light on the pattern you’ve seen.  If she doesn’t agree with the data – doesn’t see that there’s a problem – it’s going to be hard to engage her in solving the problem.

Describe the impact of the problem.  Sometimes people simply aren’t aware of the effect their actions have on other team members.

Make a request for a change in behavior, and agree on how you’ll know the change has happened.  You and Felicia may agree that she’ll email you the results of the smoke test after she checks in code for the next three weeks.

It may seem like a small thing, but giving feedback over small situations with your peers will be a valuable experience when giving feedback becomes part  of your job. After all, if you aren’t comfortable asking a peer to pick up the handset rather than using the speakerphone, how will you react when you have to tell an employee that she can’t bring her gun to work? Or request that your star programmer wear underwear if he’s going to show up in very short running shorts? (Both true stories from Ripley’s Believe It or Not: The Management Feedback Edition. Okay, so this book doesn’t really exist, but it should!

Managing Up

Managing up is about helping your boss help you, and giving your boss the information he or she needs to make good decisions.

Consider this situation:  You’ve been receiving calls from the support desk staff for second level support.  You’ve had three calls already today.  Your main priority is getting the next release of SpellWizard out the door. You’re pretty sure that this isn’t part of your mission, and trouble-shooting and follow-up from the calls are taking up significant time.  And you’re starting to feel that the time you’re putting into support calls is jeopardizing the release date for SpellWizard.

As a technical person, you can put up with the calls, gripe to your boss, or manage up.  When you manage up, you provide information to your boss and present the situation in terms of your boss’ goals and the company's goals.

The conversation might go something like this:

“I’ve got a concern that I want to discuss with you,” you start. “I understand that it’s important to solve customer problems and the number of calls for 2nd level support we’re getting are jeopardizing the release date for SpellWizard.”

“Here are some alternatives I see to support the customer and achieve the release date.”

If you’ve done your homework, you can lay out your data:

“I’m currently getting 4 calls a day from the support group, and the average time to research a problem and provide a solution is 30 minutes.  That’s at least 2 hours a day I’m losing directly, plus re-immersion after the interruption is probably taking up another 20 minutes for each call.  That’s a total of almost 3 and a half hours a day.  Our schedule is based on having Sarah and me work on SpellWizard full time.”

Then explain the alternatives you see:

1. Do nothing:  Continue to provide 2nd level support under the radar and slip the date for releasing SpellWizard.

2. Ask your boss to negotiate some support agreement with the support manager and make 2nd level support an official part of the responsibilities of the group.

3. Ask our boss to talk to the support manager about the number of support calls and provide a series of brown-bag sessions to give the first-level support team the information they need to many of the problems they’re now calling about.

4. Refuse to take any more 2nd level support calls from the support group.

Your boss agrees you can’t just hang up on the calls from the support team, and she’s concerned about missing the SpellWizard release date. So she agrees to talk to Jill about your idea for brown bag lunches.

You’ve just given you boss information she didn’t have:  she wasn’t aware you were getting this many calls to help the 1st line support group. You’ve shown her that you thought the problem through, and you understand her concerns. And you’ve enlisted her to help you (by relieving you of unofficial 2nd line support duty) and help herself (ensuring the SpellWizard release date).  Everyone wins.

Managing up helps you help your boss with his job, but also helps your boss help you do your job better.  Managing up gives your boss data to make good decisions.  Sometimes you offer alternatives; sometimes the information is data about the tasks or the environment.  Even the best manager isn’t aware of everything that goes on… they need staff members to help them see the entire picture.

As long as you’ve got a boss, (even the CEO reports to the board!) you’ll need to manage up.

Manage Across Using Influence

Managing across is the art of influence, and influence becomes increasingly important the less technical work you perform. Even as technical contributors that are numerous circumstances where the ability to influence congruently is a big plus.

Influence isn’t about sucking up or manipulation; it’s about understanding another person’s goals and interests and presenting your goals in a way that speaks in language that 1) they’ll understand and 2) makes the connection between your goals and their goals. That’s often why people are willing to help: helping you helps them, too, if not right now, then at some time in the future.

Here’s an example of how two technical in different parts of the organization helped each other accomplish goals:

For example, Keith was a tester in one part of the organization. He needed a different point of view on some of his exploratory tests. Robin wasn’t officially a tester, but in her support capacity, she needed early access to the builds. Keith gave Robin early access to the builds because Robin helped Keith test the product differently than Keith did. Robin tested the builds so that she could learn the product more quickly. Keith achieved something he couldn’t do on his own when Robin did the additional testing for him.  Robin received value in having early access to the builds.

Practice Makes Almost Perfect

If you’re planning a move into management, practice management skills in your current role: plan and organize your own work, find ways to work through and with others, provide helpful feedback, and make decisions according to the business strategy. If you work to develop these skills, you’ll become, not a perfect manager maybe, but certainly a great one.

© 2003 Esther Derby and Johanna Rothman. This article was originally published in STQE, September/October pp32-40.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: