Fog Creek Software
Discussion Board

New app dev manager transition plan

I'm on the verge of accepting a new job as the manager of a software development group on the West Coast. (I hope you'll forgive me for staying anonymous.). I've managed groups of this size before and I've made this transition before, but it's never been as smooth as I'd have liked. I'll be taking over a medium sized group (15+) that hasn't had any effective leadership in a while.

My question is: As a developer, what would you like to see your new boss do upon arrival ?

(And no, I won't be able to bestow huge raises or provide Aeron chairs and 42" plasma screens for everyone. Ditto on the massages. I might be able to spring for some munchies.)

Your thoughts will be most welcome.

Tuesday, July 6, 2004

Interview each developer separately.

Say that you're here to help me.

Exchange "what can I do to help you" and "my door is always open" information.

Get management consensus on how your arrival affects the chain of command. For example, you said "that hasn't had any effective leadership in a while" ... perhaps that means that before your arrival, developers reported to (needed to please) several people? But now that you're here, are you truly The One, to whom they can now look for their marching orders?

Christopher Wells
Tuesday, July 6, 2004

I agree with Christopher. Very good points.

When I have a new boss, I like to know how "technical" he is and if he can appreciate my work. I've had bosses who didn't know that implementing a client-server architecture is longer than changing the background color of an HTML page ( Iceberg Syndrome article by Joel ). So you might want to reassure your troops there.

Eric V.
Tuesday, July 6, 2004

Find out what the biggest legitimate obstacle to your team's productivity is, and remove it immediately.  Make it clear that you are their advocate, and you will do well.
Tuesday, July 6, 2004

I think the first thing you want to do is establish that you're an approachable manager.  I like the idea of introducing yourself and spending 30 mins/one hour with each member of the team.  But there's a lot more you can do than just that.  Keep candies in your office.  Walk the hallways.  Etc.

In the long run, 15 people sounds like a lot of people to manage ... you may want to break it up into four or five groups to work together.  Try to seed each one with a mix of developers, from new hires to seasoned hands.

Tuesday, July 6, 2004

Perform Joel and/or survival tests:

A productive team is a happy team.

Tuesday, July 6, 2004

Good advice. During your chats with your charges, find out what they are working on and talk knowledgably, showing an understanding of the technical merits of their work. if you do not understand it technically, have them explain it to you and thank them for doing so.

Dennis Atkins
Tuesday, July 6, 2004

Great ideas. Thanks to everyone who responded.

As it happens, I've been in IT for over 20 years. While I no longer claim to be an expert programmer (I've grown out of touch with the tools) I've kept up with the technologies and methodologies.

From my programmer days, I remember how much I resented being sent to work for a non-technical manager. I'm trying to put myself in the other guy's shoes and determine how I would like to be treated were our positions reversed.

I hope that the discussion continues.

Perhaps we can branch off on a tangent: What NOT to do .


Tuesday, July 6, 2004

Somethings *not* to do (and I have seen them done)

- Diss the old manager in front of the developers
- Demand documentation for everything in sight and if not available complain about how you cannot "hit the ground running"
- Overpromise on deliverables without consulting the developers to show top mgmt that you are different.
- Take your developers to the obligatory lunch and then spend all the time bragging about yourself and the past jobs
-  Reallocate developer responsibilities before understanding properly what each one is doing
- Lie about your technical is easily seen through by good developers and earns you nothing but disrespect later

Code Monkey
Tuesday, July 6, 2004

You probably know this already, annon, but don't be the new guy that comes in and wants to change everything.

Tuesday, July 6, 2004

"Find out what the biggest legitimate obstacle to your team's productivity is, and remove it immediately"

This includes things like whiteboards, printers, etc.

Be visible, but not obtrusive. Pay attention to what's going on, ask questions, learn the lay of the land.

Trust, but verify.

Learn to ask "why?" - try to get to the root of policies, esp. those that cause your team problems. Often policies grow stale and crufty and get corrupted over time. It's worth your time to dig into the why's of policies like that happen.


Tuesday, July 6, 2004

"Often policies grow stale and crufty and get corrupted over time. "

I call that Beauracratic Barnacles. 

They just slow 'the ship down, they hurt, and they're difficult to remove.

Mr. Analogy
Tuesday, July 6, 2004

Don't come in and say you're going to change everything... even if everything needs changing (and even if you're going to change everything).  Even if things suck many people are scared by change and many people will assume change means lots of stupid policies which don't help them get their work done.

Definately talk to each developer alone and ask them what they need, what's going well and what's not.

Tuesday, July 6, 2004

I had some good bosses but "Ed" stood out. He was on his way up the (huge) organization. Taking on the group I was in was a stepping stone for him. He'd had a variety of jobs already from grunt programmer on up. We were skeptical and somewhat resentful that this guy was surely going to pass us by.

He won us over within a week. Four things stood out: He displayed no ego. He saw the value to us of getting decisions made. He went to bat for us when we needed something. He worked harder and probably more productively than any of us.

He called a group meeting of all the leads (about 10 people) in his first week so he could find out what was going on. We each whined, cried, moaned, etc. about our respective projects. He stood all day asking questions and taking notes on a flip chart. He sprung for dinner and we went home. He stayed at work and copied all the flip charts into notes he could deal with. Within a week he knew more than our previous boss and was working to help us get our jobs done.

For us, that determination, stamina, and modesty he demonstated in that first week was breathtaking. Of course Ed has continued up the ladder and deservedly so. Did I mention that he was one of the nicest folks I've ever met.

Tuesday, July 6, 2004

Personally, I have worked in 2 jobs that had low morale and were overall caustic.  Primarily politics and culture were to blame for low job satisfaction at both.  Those two elements are extremely difficult to change and take a great deal of time.

Had you walked into either of those environments as my boss, I would have hoped that you:

1.  Didn't make any promises.
Firstly, you won't win any credibility with me.  I have been here longer that you and I know the lay of the land.  If the problems were so easy to fix, it would have been worked out long ago.  Everyone on the team likely recognizes that  the problem is likely higher up the food chain.  *You* can't fix that.  It will take time.

2.  Take the group out to lunch.
My last boss probably didn't.  It won't gain you anything long term, but who doesn't like to be appreciated once in a while?  Pick my morale up, even just for a bit.  Its a discreet way of saying that things are going to be done a little differently from now on.

3.  Like everyone else mentioned, talk to me.
Meet with everyone to get their perspective on how things are going.  This one's so obvious, I am not sure why I am suggesting it.


Good freakin' luck!
Tuesday, July 6, 2004

Hookers, hookers, hookers!

Tuesday, July 6, 2004

While the hookers might be nice for some...

Let you developers shine by interviewing them one by one.  Make it clear to them that they're *not* re-interviewing for their job, but instead you're gathering feedback.

Once you've gone through this, have lunch delivered to the office and try to throw out the issues that you're going to deal with immediately.  Treat the issues as bugs to the development process with a priority, severity, etc.

And always know that your success is dependent on the team's success.

Wednesday, July 7, 2004

When you are talking to them one on one find out when their birthday is, if they have a signifigant other and about their kids etc. Then make a note of their birthday, their wives/husbands birthday if possible. If you have the power to do so a day before the birthday if it falls on the week send them home early to spend time with their family or get gifts together etc. (It also might be a good idea to see if they like/dislike their birthday being public knowledge where they work, personally I hate happy birthday banners at work.) It also is good information to have so you know that when a deadline is hitting at the same time you can go to that person and make sure they will be able to spend some amount of time with their family and not all of it behind a desk. If you have a lot of single people working for you find some ways to encourage them getting out of the office.

Wednesday, July 7, 2004

Walk around with a notepad at all times.  Anytime someone has a request/concern/comment write it down.  Just writing down people's requests shows that you are paying attention and puts you on a pedestal.  When you actually act on the problems (that you now remember because you wrote them down) you become a god.

Wednesday, July 7, 2004

*  Recent Topics

*  Fog Creek Home