Forums

After John posted the link to "Who's got the Monkey", I started thinking that it's difficult to differentiate between the kind of support you need to give your directs, and not letting yourself become subordinate to them.

In the "New Manager" 'cast, the first 90 days was described as the time a new manager should "Carry The Water".

Is there a way to keep from becoming a subordinate AND carry the water for your team?

If that dichotomy is just a facet of the first 90 days, how does one gracefully shed that role after the 90th day?

HMac's picture

Greg: I just checked over the show notes of "The First Rule for New Managers" and the only refrence to water-carrying I saw is to remember that your directs will be responsible for carrying YOUR water in the future (and therefore it's important to focus on building strong relationships). I didn't see any reference to carrying THEIR water...

akinsgre's picture

Thanks HMac!

Note to self: Must listen better!

I could have sworn that recommendation was in the 'cast.

HMac's picture

I'm hardly the best listener, and I still think I heard more of a reference to the term than what I saw in the show notes. Someone else (jhack? AManagerTool?) might chime in with a more complete take on it.

But I think the larger point is not to confuse "supporting" your staff with "doing their work for them."

If you ever get the chance to hear tapes of the Bill Oncken Jr. present "The Manager and The Monkey" jump at it. I have listened to some cassette recordings that must be 30 years old, of Bill presenting a program called "Managing Management Time" - it's pure gold.

His son, Bill Oncken III, has taken up the family business, and co-wrote "One Minute Manager Meets the Monkey" with Ken Blanchard.

-Hugh

jhack's picture

Hugh,

You heard it same as me: "carrying the water" means supporting them, not doing their work. In particular, Mark and Mike were pointing out that if you want them to undertake new initiatives for you, you need to prove that you trust them and have sincerely listened to them. They won't carry your water if you haven't earned their trust.

If your predecessor took on tasks him/herself and the team has been turned into little nested dolls, then you may need to get into coaching &or training pretty quickly.

John

akinsgre's picture

OK, I realize I misunderstood the advice.

Now, I'm going to be moving to a team where I'm to be doing development work with 50% of my time, and managing during the other 50%.

I'm afraid that I'll do the same thing I'm doing currently and focus too much on that work, and not enough on the 50% management.

How do you all make sure that you put time limits on the amount of time you spend on that type of work?

HMac's picture

Great question Greg -
I'm sure you're going to get some great answers - here's my whack at it:

Remember that 50/50 is a desired average, and not a daily goal. There are going to be periods that naturally tip you one way or the other.

That said, the first tool that came to my mind after reading your question is the CALENDAR. It can be incredibly powerful - simply because people tend to do what's on their calendar. Think about your own experience: to some degree, you probably build your "work" in around certain standing meetings or other blocks in your calendar.

[i](SIDEBAR - MY OPINION): Effective managers manage from their calendar and tasks; ineffective managers manage from their Inboxes!).[/i]

The most obvious example of managing with your calender is your standing O3's. You put 'em on the calendar, and when the time comes, you dial the phone or show up.

One personal note: I've never been a big fan of blocking my calendar with tasks that I do all by myself. I've never found it to be very effective to block two hours for a project, for writing, for research, etc. But that's just my experience - your mileage may differ.

So, my advice: Get as many of your "manager" tasks as you can onto your calendar (and onto others' calendars).

-Hugh

jhack's picture

It's incredibly difficult to be a software(?) developer 50%. You'll either assign yourself the easy stuff (so that it actually gets done) or the hard stuff (in which case you'll find yourself in the critical path, and you'll fall back to development rather than managing - because the managing can wait but the code is due tomorrow).

That's some catch, that Catch-22...

[quote="akinsgre"]How do you all make sure that you put time limits on the amount of time you spend on that type of work? [/quote]

Don't do development. Oversee design. Organize the work. Coach. Delegate. Your team can do it: if you have 5 team members, that's only 10% extra from each one to cover your 50%. If you manage effectively, you'll get much more than 10% extra out of them.

Every sales manager faces the same problem: they were promoted because they were great at sales, better than any of their directs. So now they have to choose: sell harder to cover their team's 'weaknesses,' or coach the team to greatness.

John

MsSunshine's picture

BLUF: All managers have distractions. Figure out what is important. Do things that only you can do. Delegate the rest. Coach so there are less things only you can do. Plan on having corporate initiatives take some of your time - because it will whether you plan for it or not.

I had the role you had only a little worse split. We were supposed to be 80% developer and 20% manager. When I became 100% management, I had a delusion it was "easier" now. But in reality, I've found that it's the same. I have two notes on my wall behind my phone.

1. What is the best use of my time - right now. Do it.
2. What things can only I do.

I do block out every Friday morning from meetings to analyze my outstanding tasks for the next week and plan for delegating/coaching/feedback/followup at my 03's. I find I have to block it out or my week gets fragmented into hour blocks here and there which make it hard to focus. That doesn't mean that I don't occasionally put something in there but it means most people see it filled and find another time!

I do put major tasks on my calendar. I have 14 reports. I personally find it easier to get into a mindset about doing something like career planning for all of my developers in bigger chunks than here and there when I have a spare moment.

Question #2 makes me think about delegating more. What I found as a developer was that I needed to delegate more of the "fun" stuff. Yes, they didn't do it exactly how I would have. Yes, it may have taken them longer. But they learned to be more self sufficient. Sometimes there way was just as good even though it was different.

You cannot save all of the juicy, hard work or design work for yourself. It doesn't grow your team. You become the bottleneck. You may think you have the time but then some corporate initiative or other task that only you can do will come along. Then you slow down progress. Think about picking up some of the grunt work tasks instead. Your team will love you for taking your share of the garbage work instead of picking all the good jobs for yourself.

HMac's picture

Hey everyone on this thread:

You should really re-read the two immediately prior posts (by jhack and msSunshine). Solid gold advice - you two are great!

-Hugh

akinsgre's picture

[quote="jhack"]It's incredibly difficult to be a software(?) developer 50%. You'll either assign yourself the easy stuff (so that it actually gets done) or the hard stuff (in which case you'll find yourself in the critical path, and you'll fall back to development rather than managing - because the managing can wait but the code is due tomorrow).
[/quote]

That's what I've been feeling, but am not sure how it's going to work.

I think I'll have to do some work (I only have two directs so distributing the work isn't as easy.

I don't want to get in the position that I don't have time to manage because I'm holding up the rest of the development team

akinsgre's picture

[quote="akinsgre"]

I think I'll have to do some work (I only have two directs so distributing the work isn't as easy.

I don't want to get in the position that I don't have time to manage because I'm holding up the rest of the development team[/quote]

I wanted to clarify this. Rereading my note, I realized that "thinking I'll have to do SOME work" is a stupid thing to say.

What I mean is that I fully expect to do some coding in this position.

In the position I'm leaving, I made the mistake of getting myself on the critical path.

I became the "Configuration Manager" so during releases I was one of the busiest person's on the team, and found that it was hard to make time for O3s because of the time constraints we were under.

Also, I found that it was easy for me to be the scapegoat for my team in why they didn't meet some targets. In effect, my role is the "gate" for product getting out the door and I wasn't able to keep that up and do an effective job managing.

I got in that position because I thought I could get the basic framework completed and delegate to the rest of the team. However, the rest of the team was busy and didn't appear willing to take on this extra work I was creating for them.

So I see a couple problems in what I did.

- Trying to create new processes created extra work for them, and I was the relief valve for the extra work.
- Accepting the ownership for key aspects of development allowed them to keep the monkey on my back

Now, however, I am having trouble seeing how I can do some of the work my directs should be doing without taking ownership.

jhack's picture

[quote="akinsgre"] ...I am having trouble seeing how I can do some of the work my directs should be doing ...[/quote]
Why would you do "work my directs should be doing?"

If it's simply that there is more work than your directs have time for, do the really easy stuff. Do the stuff they would hand off to a summer intern. Do things that have a really clear end point and known scope (ie, document one part of the system, write one test case, order the pizza, etc).

Plan for this. Make sure you hold them to their deliverables and time commitments. Don't let them shed work onto you.

Be ruthless in refusing to do their work.

John

asteriskrntt1's picture

This is a beautiful thread. People should print it up and look at it every morning. Smart smart stuff. Nice contributions everyone!

*RNTT

jhack's picture

Technical people often get promoted for their technical skills. The path is often first some sort of "technical lead" role, then a formal management role.

Coaching and delegation are the only ways to go beyond being a technical lead. Directs must grow and the best become the new leads. It's easy (in the short run) to continue as a tech lead after becoming manager. That must be resisted.

If management was easy, Manager-Tools wouldn't exist.

John

ramiska's picture

This is why I joined the forum. Thanks to akinsgre for posting the question and all of you for the sage words.