Managing developers who've been self managing

Question

The background:

So, I'm starting a new role in a month or so managing a development/support/test team of about 12 in a software house.

While there is a Director of Technology in place he's not been involved with the team day to day for some while (it's a small company and he's involved in a lot of other things, strategy, pre-sales consultancy and is out of the office a lot) so the team has effectively been self managing for some time.

From what I understand they've doing most of the basics right (automated build, source control, bug tracking all in place, hitting release schedules though by the sound of things there's a fair bit of overtime contributing) but there are going to be things which need improving.

There are senior developers in place each of whom look after one area and three or so staff and apparently they (or at least some of them) have said they want a manager - and didn't want the job themselves. According to the Director of Technology there are no significant issues there but they have growth plans and feel that it's time to have someone in there.

I've run development teams before, read peopleware, been a developer for a decade, know the joel test and know what a working team looks like and what it should be doing.

My concern is that as this that the first few weeks are key to whether any of that will actually matter - get off to the wrong start and it doesn't matter how good you are, it's going to be an uphill battle. Do too little and you're seen as ineffective, do too much and you're seen as meddling.

So, to make this a solid question (or two):

1) What one or two things should I absolutely do in the first fortnight?

2) What one or two things should I absolutely not do in the first fortnight?

Thanks in advance (and apologies if it's too subjective).

Answer 1

1. Listen more than you talk.

2. See point #1.

Answer 2

My best advice is to establish a comaradarie with the team. They aren't used to having a manager so you will need to go in gently and perhaps take everyone to lunch, all of the usual stuff. Obviously, you will probably be making several changes, just your existence in this role will be a big change for them, so you will want to make the transition easy for them without impacting their productivity or morale too much.

Answer 3

Spend your time getting to know them and getting their ideas. Everyone has their own ideas on what can make things better, so they'll see you as an opportunity to get them into action.

Listen to what people say, and be gentle. If you're careful you can put things across as suggestions and get people to agree, rather than imposing new rules and expecting people to start working to them.

You need to be a salesman - tell people what improvements you're suggesting, and crucially what benefit it is to them. It's give and take - if you implement ideas the team have had, you're more likely to be able to get away with implementing necessary changes that they don't necessarily really want, or have been putting off.

Answer 4

That the senior guys asked for a manager suggests there's something they want but aren't getting.

That they don't want to do it themselves suggests they think doing that will be a pain in the arse*.

What people want from managers is the stuff they need to do their jobs; they'll want you to advocate for them with the Director of Technology, get them the resources they need, possibly tell the DT and the CEO some hard and unpleasant truths about resources, timelines, and deadlines.

They'll want you to do these things without getting in their way. Whether or not they need new processes, don't try to introduce changes to how they do their work until you've gained their trust and they see that you're loyal to your team whilst* at the same time loyal to whomever you report to. They're self-managing now, and they didn't ask for a manager because they think their development style is lacking.

(Even if it may be -- though one senior guy may issues with another senior guy. Which brings up another point: if that's the case, you'll be asked to take sides or judge whose approach is "better", or at least referee. This can be pure poison, as you'll be asked to make decisions before you have sufficient data. So avoid getting drawn into that until you know enough to figure out each players' strengths and weaknesses, and to come to objective decisions.)

So your first goal is to prove that you're their advocate, a lobbyist for them with upper management.

* Since you wrote "fortnight" I assume you speak that stuff they call "English" in Commonmwealth countries, not real Amur'cun. Yee-haw! :)

Answer 5

You've been employed by the Director so he's your main "customer". I'd spend some time with him to work out what he wants from you, what he considers needs fixing, what he feels would be a sucessful first 6 months for you. At the same time you need to ask these questions of your new reports. Your job will be to keep both parties happy, but rememeber who your boss is.

As for your new reports they're probably going to want you to act as a "sheild" from upper management. The best thing you can do it let them get on with their work and protect them from unneeded distractions from upper management. Let them do what they do best.

Your biggest "don't do" for the first 2 weeks is "change stuff for the hell of it". Don't come in and try to make your mark by changing processes or tools just because they're processes or tools that you've used before. See what they're doing, spot the places where there are inefficiencies, and then, over time, EVOLVE their process to be better.

Answer 6

Spend more time with the people who work for you than who you work for. That group will make or break you. They need to believe that you are their advocate and are helping them.

Do lots of listening. Don't presume to understand anything; you know as well as anyone how software evolves and it's easy to take an overly-simplistic view of things as an outsider. In the first fortnight I wouldn't take ANY action unless the building is on fire.

As you act, at least early on, make sure it is consistent with the views of the team whenever possible. If you come across as knowing more than them or knowing what's better for them than they do, you have lost them. It will be very hard to regain that respect if you lose it.

Lastly, don't get involved in the details unless you need to. Have a good delineation between the types of tasks that ARE part of your job vs. those that aren't.

Answer 7

I would ask a lot of questions to the team. Find out what they like, what their issues are as a team and see if you can provide any help

Answer 8

The company where I work (as a developer) is in a very similar position to the one you describe, and we are also bringing in a lead developer very soon.

We are also a small company, and growing.

When I started working here several years ago, we had no processes. We were using a shared folder instead of source control, we had no build-server, no testers. We just wrote the code, did some ad-hoc testing, then emailed the binaries straight to the customer.

We have improved a lot since then, but a lot of it is just sort of cobbled together, because none of us had any experience with this stuff.

So, what I hope our new guy does in the first fortnight is just learn our current processes. I hope that he doesn't want to make too many changes, too early.

I am hoping for gradual but steady improvement in our processes. We will need time to get used to any changes, and we are quite busy at the moment, so learning will be slower than usual.

I am also hoping for good explanations of why we should make each change - what it will get us. I want to learn how to do this stuff properly.

I suspect many small software companies end up in this position, outgrowing their ad-hoc development practises and starting to really need proper source control, automated builds, and all that stuff.

Answer 9

I'd try to keep an open mind until you have spoken to everyone on the team and your director. They are bound to have a slightly different view on the current situation and the fact that the team have asked for a manager would suggest that there is some tension between them and the director.

It is also probably a good idea to try and express your general philosophy on running a department to your reports so that they can get an idea as to what you stand for in general and what to expect from you before you get down to actually doing the job.

I would suggest that you avoid trying to do too much in the first few weeks. Even though your team has asked for a manager they may not like it to much if you come in and immediately start changing the systems and processes that they have put in place before you have really had a chance to see them working. Though obviously ignore this if there are things that need correcting immediately to avert potential disaster!

Answer 10

Ask them what they want you to do. They would not have asked for a manager unless they see a need for one, find out why.