views:

404

answers:

10

As a manager it is your job I think to remove obstacles so that the development team can keep going. You must also try to keep some level of respect within the team so that when you have to take a tough decision the team respects it.

Many people say you should stop coding, others say you should keep your hands in.

My question has a slight different view. Instead of me worrying whether I should be coding. What affect does me coding or not coding have on the team?

What experiences have you had? How did it work?

+3  A: 

If your team sees that you're losing touch with the technology that they're using, they will see it as a lack of interest on your part and lose respect for you.

A development manager doesn't have to be the team's greatest coder - far from it, but he must be seen as keeping current.

Galwegian
+2  A: 

I have worked with excellent dev leads who have taken an active part in code development as well as being the "people manager" for the other individual developers on the project.

It seemed to work well, but this relies on a very open and respectful relationship between the team members and lead. As the lead you have to be particularly careful not to assume that because you are senior that you are right - this will soon lead to stifling innovation and good ideas from the team.

Simon Steele
+2  A: 

As the manager of a development team, I think if you are going to make technical decisions, you need to have the respect of your team on technical issues.

I think you can only do this if you keep doing some coding. If you stop coding altogether your technical skills will deteriorate, possibly to a point where you might start making bad decisions.

I doubt anyone who is a good technical manager would advise you to stop coding completely; that sounds to me like what a 'business' person would say.

However, whether the coding is formally part of your job, or done in your own time, is a different matter.

Myself, I have always kept doing some coding, and in so far as I can tell, it has pretty much worked.

DanSingerman
+4  A: 

Pros of you coding:

  • You don't lose the sense of the real state of the codebase
  • You keep up with changes, both in architecture and in technology
  • It puts you in a better position to make decisions that have big impact on the codebase
  • You don't have to consult other developers to answer trivial question about how the current codebase works.

Cons of you coding:

  • It takes time away from other management tasks, so you probably shouldn't be doing to much of it.
Einar
I think there can be other cons - how your team members feel about your low level involvement for one. (Manager depending)
annakata
A: 

You should stop coding for the projects you manage, but keep coding in other projects.

Kai
A: 

Although you should be hands-on and up-to-date on the technical work your team is doing, managing people requires a completely different set of skills. A good technical person may not by default make a good manager. In fact, good management is not always a function of how adept you are or have been as a coder.

In my experience, the worst managers were those who were once average or below average programmers and got promoted to management level by virtue of the Peter principle.

On the other hand, I have worked with managers who did not know any coding but were excellent enablers because they understood people issues very well.

Rahul
+1  A: 

Of course you should keep coding. Just don't fall into the trap of thinking you're better at it than people who code full-time.

I can imagine that it's hard for a manager who still codes not to micromanage the team, you're still involved in day-to-day work and you've got the power to override architectural decisions your team makes. I've worked for a couple of managers who did this and usually things got better when they stopped coding.

If you trust your team enough not to do this then a coding manager can be a great asset to a team.

Mendelt
+11  A: 

Ideally I want my technical manager to balance himself between involvement in the team, and extracting himself from it. Tough ask I know.

I want him to give me control over my own problem domain - a free hand with the respect not to be looking over my shoulder - so long as I deliver on my commitments. That means I get to write my own classes, not flesh out his stubs.

I want him to have a realistic view of what is happening within the team. I need him to understand where the blocks are and why, and to know that the answer isn't taking control of anybodies keyboard, nor asking others to do so.

And fundamentally I need him to stay current in technology. This doesn't mean he has to be coding per se. Being involved and keeping fresh in methodologies and high level concerns like architecture, project management, testing tools and practices, and keeping a weather eye on future tech is probably better. What is unacceptable is that he stops learning where he is and the rest of us march to that tune forevermore.

Oh, and I also (is it too much to ask?) want him to involve me, and everyone else in the designs. I am not a mindless extension of him, I need to have creative input. Make it a discussion, not a task.

annakata
I think by you 'coding' - you're sharing in what is going on around you and showing support AS LONG as it does not interfere with your primary responsibilities and does not take control/ownership away from the developers (don't become their crutch)
meade
..but equally don't make them your slave!
annakata
A: 

Continue coding or not, you should learn to be a manager, many people think because they have the title, they have to do something all the time..

This article about creating micro managed zombies gets my point. This is not only for software development departments, I see in my company plenty of departments where the department managers have no clue what they are supposed to do as managers, they inherited the title because they are senior, but without any clue/motivation/understanding of what it is to manage people:

Managing people is not the same as managing projects or tasks.

-- And I would say: do not stop coding, if you like it, BUT never code over or code compete with people working under you...its highly destructive and counter productive.

Code instead to keep yourself up to date, or in the loop.

I had a boss once who lacked coding skills or any awareness of best practices, he would use his title to make his code stick..it took years to educate him into letting us do the coding and him the managing of the department.

Ric Tokyo
A: 

I tested on myself different approaches:

  1. Do development together with team. This approach works only if you have up to 2-3 developers. the team is small and you do not have a lot of management work (include conversations with customers)

  2. Just manage and do not code at all. It's bad approach due to you are losing your software development skills.

  3. What I do now. I do not code projects which I manage, but I check some parts of the code (together with my architect). If I see some issues I ask developers to do refactoring and improvements in the code. And I do code my personal project during free time. Not much but it's enough to keep my coding skills.

Roman Podlinov