coder to "coder+manager" sortof.. half career half social question

[Sergei Shelukhin]

Hi.
I've been recently promoted to lead a team of 4 (including me) on a project, being part manager part developer; project is internal and doesn't involve any "external" management (e.g. no clients for me and very few internal stakeholders).

The main problem is that I am responsible for the architecture and code quality and all the other developers weere just promoted from juniors - that means they have A LOT of questions on every imaginable tidbit and piece of code, what's this feature going to look like, what's the best way to do X, how do I code Y, can object Z do A using some property, etc.
I also retain ,ost of my old duties so I get some user emails and some calls.

That basically means that I can't get anything done codewise, because I don't get more than an hour of uninterrupted coding and it's very hard to get into "the flow". Given that I'm a 22yo code junkie myself, it also frustrates me a lot even though code expectations are somewhat lower for me given my other duties.

I am pondering two directions for solving this problem:
1) Make developers more independent, so that they'd at least google the most obvoius stuff.
2) Organize questioning somehow so that they'd not interrupt me every 10 minutes. We can't however, afford developers sitting there not knowing what to do because the question session is scheduled in an hour.

I dunno what to do about the first one (I'm going to make 'em come to conclusions and answer "pointing" questions starting tomorrow ) , and about the second one, I can only send a polite letter asking to group questions and defer less urgent ones (or that's the only thing I came up with).

Can anyone help me with those two things, or maybe suggest something else?

[Michael Chui]

First, I'd suggest minimizing your coding responsibilities. A manager is not a programmer, and it's cruel to ask someone to do both jobs. It sounds like you really like to code, however, so there's no reason to get rid of it entirely. But choose one to be your focus, and it sounds like it's being a manager.

Second, set up a system where you set yourself to Do Not Disturb. Let the relevant people know. If you're being interrupted physically, set up an obvious physical marker (like a red sign or a flag). If it's online, shut off your messenger and email. If it's by phone, turn it off... you get the drift.

Third, suggest that they help each other. I've never liked bureaucracies; they shouldn't need to go through you to each other. This is basically an extension of the Solution #1 you proposed, so make them more independent and interdependent.

Fourth, and this is a bit of a risk, is to permit them to get through to you "in an emergency", which is basically, "No one knows; Google is useless; I have nothing to do for the next hour." When that happens, you talk to them, sort it out, and then make the rounds to make sure no one has something pending, then go back to your job. Make sure that they actually have checked with everyone else and Google, and if that doesn't help, they should work on something else until you're free.

Fifth, make the rounds every now and then. If you deal with their questions on your schedule rather than theirs, it's easier on you.

If you're technology heavy, then you might consider setting up a simple question-queue system, though that's dangerous, since it's asking for trouble.

[Baltar]

You'll probably have to simply deal with it for a while. This shouldn't last forever though -- as they get more experience and more understanding of what's going on, they'll need to ask you fewer and fewer questions. I had a programming job once, and right when I was hired I had a lot of questions about the app I was working on. In my case I was hired to replace a programmer who was moved to another project. For the first few weeks as I was trying to figure out the architecture I had to ask him a lot of questions, but eventually I figured it all out. So you may only have to deal with this for a short time.

[Richard_Todd]

I think you maybe should change your persective a bit. Instead of looking at all the questions as interruptions, maybe you should start seeing them as your job! I don't know any details, so I'll just have to talk in generalities, and hope this helps you (or at least, someone!)

I've been a software manager for teams of 3 people all the way up to 60 people, on budgets of anywhere from $300k to $50million. I was also a promoted code-junkie, initially (writing code is still my favorite hobby). I tried it both ways, and in every case it was by far easier to just give up on the notion that you'll both code and manage.

You have a real advantage right now, if you grab it. You still remember what it was like to be a coder. Write down everything you can remember, about what made you happy on the job, and unhappy. What did you want (training? more flexible hours? someone to deflect common user questions?)? As a manager, you may start to see more and more of the reasons the things you want were so hard to get. But, you may be able to make life a lot better for your team, while you still have the right perspective. Believe me, five years of management tends to make you forget!

Being a good manager is tougher than it seems. You have to balance a lot more conflicting goals than you do when you are coding. This means, often you face situations where you will make someone mad, no matter what you do. Usually, a coder in that situation will do what makes himself look best, but a manager should really do the opposite. In the end, you will look good if your team looks good.

If you have trouble with estimating budgets and schedules, you will improve at it over time if you pay attention. There's really no way to sit down and "learn" that stuff. In my opinion, the best thing for a new manager to focus on is spotting and removing obstacles from your team's path, before your team even knows they are there. Write it on a sticky note, and make sure you read it at least once a day. "What will my team need next week/month?" Coders and managers that fight fires often get some fame for it, while the best managers often get less attention because they prevent the fires. It sucks, but in the end the results will speak for themselves.

So, instead of stealing an hour to write some code... maybe steal an hour to write some coding standards for them to follow (if they are asking a lot of questions about that stuff, or if you see that their code is all over the place). Or, making sure the room is reserved for that demo. Or finding a way to get Joe some help without making him feel threatened. Fight your superiors to allocate some money to training. You are right that, the more independent you can make you team, the easier your job will get. But, schedules and budgets sometimes mean you have to just slog through it until it happens natuarally.

(lastly, make sure a manager is actually what you want to be... if you try it for too long, it can be hard to go back in some companies... if you are good at it, anyway...)

[AndyMartin]

I'm not going to give you management advice, mainly because there are others who care more about it than I do. I just work with people to get stuff done.

So, a few tips on that:

First, you need to keep up-to-date with your people without wasting time. Every morning take 15 minutes to review what they did yesterday, what they're working on today, and anything that's impeding their progress. (Look into Scrum if you want to take this approach to an organizational level.)

Second, you need to organize your knowledge. This used to be difficult and expensive; now you can put up a Wiki. I recommend Twiki because it's hierarchical. So now you have an empty Twiki site, how do you get all that knowledge into it? Ground rules:

* Ask a question, fine. Now it's your job to document it on Twiki for others to find. This applies to all questions asked to anyone on the team.

* Documentation is a job requirement. Post a Twiki page for each task oragnized under a main page for the project/module.

As this approach gets into your mindset, you'll start to see other ways to improve it.

Good luck!
Andy

[Michael Chui]

Incidentally, this isn't a response to the original post, but it's pertinent:

Creating Passionate Users: "Success" should not mean "Management"