views:

367

answers:

19

I've spent several years in software development, using many different languages/technologies. To be clear, I have 10 years of software development experience myself. Now as I want to advance in my career, it seems most companies that I would want to work for desire a very specialized technical pedigree - even for a manager/director level position.

I currently manage a team of 8-10 J2EE developers, but I only became involved in J2EE within the last year. My project management track record is solid, and continues to be even with the change in technology this year.

So my question: why is it so important to potential employers that I myself have 5-7+ years experience hands-on with J2EE if I'm going to be managing people that already have those skills? Shouldn't my project management/supervisory abilities take precedence?

+3  A: 

Not in the least.

Actually, in some cases, I've seen managers that know a little of what their teams work with. When it came time for decisions, the manager thought they knew better than the team when in reality the manager would have been better served by listening to the team's suggestions...

Justin Niessner
As the saying goes "A little knowledge is a dangerous thing" -- whatever level of knowledge the manager has in the specialist area, s/he should also have enough knowledge in the round to know what he doesn't know and be confident enough to defer appropriately to specialists in their individual areas of expertise.
Steve Gilham
+3  A: 

I've found it quite useful, bordering on essential, for my project management to have enough technical skills to understand what I'm doing. I'm not saying that you, specifically, don't, but it's certainty not enough to have general project management/supervisory skills.

It's management's job to understand the entire project, and be on the lookout for schedule problems, requirement misunderstandings, etc. It's hard to do that without understanding the underlying design.

As well, some organizations just have a tradition of technical management, and non-technical folks have a problem gaining the respect of their people.

Michael Petrotta
A: 

The short answer is: if you want to have the respect of the people you manage - YES. If you want to understand the challenges, the things that hold them up, or how to communicate issues to your superiors - YES.

Traveling Tech Guy
+1  A: 

I think it's important for a tech lead/manager to be able to look at an employee's code and determine if its obviously lazy or low-quality work product. While I don't think you need to be the most talented developer, you do need to be able to understand and quantify what your team is doing. Someone with a non-technical background would have a difficult time doing this with a development team.

Still, requiring 7+ years with the technology at hand sounds excessive. But, then again, I'm not a VP or HR monkey.

David Lively
+1  A: 

More than likely, it is due to mentorship and respect.

As a manager you are expected, at some level, to be able to teach your subordinates. Without a good knowledge of what you are managing, it makes this difficult.

Also, your subordinates may lose respect for you if they see that the person leading them is not at or above their technical level. They expect that the person to whom they report is better than they are.

At the director/VP level, this becomes less important as you no longer have technical people reporting directly to you.

Russ Bradberry
+2  A: 

Often, it's easier to not have the same techie skills as your team: it can take you away from your "manager" role as you're tempted to dabble.

Having some techie skills though is useful: but not necessarily those that would allow you to do a team member's job.

However, it does depend on the exact role and the organisation etc.

gbn
A: 

The only reason I can think of:

"Hey boss, due to the complexities of this technology, it will take the whole week to finish this."

How do you know that the project is really easy and should take a day or two?


With that said, I don't think that it is essential, though it certainly cannot hurt. I have had managers who had little to no technical background at all, and they were great. They knew how to manage a software team, even though they were never developers or the like.

geowa4
+10  A: 

Is it necessary to be an expert in 'X'? No.

Is it necessary to be familiar with 'X'? Helps but not necessary.

Is it necessary to at least understand software development and have some experience doing it? I say yes.

I don't believe knowing a particular technology is a requirement. As long as you have a good understanding of software development at a level not dependent on the technology and have some management skill, you're good. That is not to say that knowing the technology in use isn't beneficial. That just means you're better able to understand the team sooner. Since you already have years of development and management experience, I'm sure you can learn enough about any technology to help guide the team.

Corin
A: 

It depends on how the employer defines "manage." In a well-run, progressive company you'd be right- your job would be to run around moving things out of the way while your team gets things done. In most real-life companies, it often falls to the team managers to make technical decisions and break up wizard fights between team members. I'd argue that this makes the job more of a technical and administrative lead, but that's the way it often works.

Dave Swersky
A: 

I think its important to ask: "What is the role of a Project Manager"?

Is it:

  1. To Grade and Judge the teams code like some College Professor?
  2. To keep a careful eye on the team so they don't "fuck up"
  3. To teach the team members how to code
  4. To be able to write a Book Report on the project
  5. To stay out of the way and make sure the team has everything they need to do the job

If this list looks like a bit of a straw-man then I'm probably conveying the concept fully.

The job of a Project Manager is to take care of all the annoying little things, like whiny upper management, like make sure we don't loose contact with the server, like replacing my chair when it accidentally breaks so I can get right back to coding. Its to deal with all the things that need to happen so your development team can develop.

So my answer would be: No, you don't have to be an expert. In fact, if you're an expert, its better for the company to have you as a developer than a manager.

But hey, don't take my word for it, let Joel Spolsky tell you what he thinks. http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html

tzenes
+8  A: 

A lot of these answers seem to be conflating "Manager" with "Technical Lead."

For any given project, there should indeed be at least one person in a position of authority who's a bona-fide expert on the technology involved. But that doesn't necessarily need to be the project manager -- in fact, I think you can make a pretty good case on a lot of projects that it shouldn't be the manager. That's the role of the tech lead. The manager should be busy elsewhere.

Best manager I ever had a good high-level understanding of the technology we were working on (Java and J2EE). He couldn't make production-worthy code with it, but that wasn't his job -- his job was keeping all the big-picture design decisions on track and preventing the technical team from having to deal with any levels of management above him. His job was basically to create an environment where we could do our jobs. The fact that he himself couldn't have done our jobs himself didn't stop him from doing his actual job exceptionally well.

So I'd say you're right. You need to understand the tech your team is using, but if an employer is demanding that level of expertise, the role they're trying to fill isn't what I'd think of as a manager at all.

BlairHippo
I agree - there is definitely a distinction between Technical Lead/Sr. MTS/Sr. Developer and "Manager". I've been a Technical Lead for several years already...
AJ
+1  A: 

A good manager should be able to:

  • Reward talent
  • Spot poor workers
  • Fight for their team
  • Weigh requirements versus resources
  • Delegate effectively
  • Assign tasks

And they do this by relying on the subject-knowledge of the rest of the team, and balancing that against their own expertise in managing people. Bullshit detection will rely on personality judgments and past experience than knowledge of code but it can be done.

To be honest though, people that can manage well without technical expertise are extremely rare. I've been in this business for 25 years, and I can count the ones I've known on one hand. I can count the ones I've worked for on three fingers. :)

clintp
A: 

If it is a technical manager who makes decisions which framework to use then being the best expert in a team is essential I think.

If it is a manager who makes decisions which features to include in the system and how it should look as a final product without telling you how, I am starting to think that not being expert in the technical department actually helps a lot.

When I am deciding on adding some feature as a programmer my biggest concern is how hard it would be to implement, no matter how hard I try to look at it from user's perspective. Not knowing about technical difficulties opens your mind in a way and you have completely different vision and priorities, which is more close to the customers/end users I think.

serg
A: 

If the potential employers are expecting you to be both a project and an administrative manager then there may be something to be said for having battle scars to show that you really do know your stuff and aren't the new kid on the block, in a sense.

If part of the position is mentoring junior developers, then doesn't it make sense to expect someone to have enough experience to use that for justifying positions? Kind of like a parent or older relative scolding a child for doing something and they know better because they are older. Yes, this is a petty childish view but there are some people in the world that really do want that kind of leverage that others may see as smoke and mirrors. How formalized and mature is the company in its policies and practices? If the company is a young startup, then the idea is that you'd bring some experience and have a few, "We shouldn't do X," moments based on your previous history. Even a big company may be finding that point of maturing and thus want someone with some maturity or experience or seasoning or whatever you want to call the person that survived various development projects for some time.

I could also see some places wanting to raise their standards with the intention of taking advantage of the current economic situation. In a way it is sad that there are such practices but I could picture various recruiting firms or small companies upping what they are expecting from applicants.

Just a few different ideas on why some may see the desire of wanting someone with the experience in "X" to manage people doing "X." I say want instead of need or believe is necessary because it seems so often that the job requirements are for a mythical ideal candidate that while there may be a few people on the planet with all those skills, they likely aren't going to be applying for those jobs so the company either has to compromise to get someone or leave the position vacant until a suitable person is found to take the spot.

JB King
A: 

I think it depends on the expertise of your team and size of company. If your team has more than two experts and have a good track record then you can rely on them more and provide more of a managerial/motivational role. If they are less senior or you only have one expert then the company needs to rely on you to make proper design/architecture/technology choices in the case your expert leaves.

Having the real world experience does also gain the respect of your team which helps you manage more effectively, as silly as it may be, it's true.

Snives
A: 

My short answer is "no", but I want to touch on two things that I think are happening in the companies' hiring policy.

The first is the qualification inflation problem. It's pretty common practise for people to blow their experience and skillset out of proportion in their resumes - Bob has two years' solid experience in J2ME and claims to have 5, those kind of things. A tactic that HR people have used to combat this is to over-inflate the requirements of a job, so when they say they want 5 years they really only mean 2. It's a practise which is propagated by dishonesty, and it's annoying for people who try to keep to honest truths in their advertising, but it happens. Besides, on the off-chance that someone who actually has 5 years' experience turns up, it can't hurt, right?

The second thing at play is likely to happen at larger, older companies: An industrial-era view of organization which dictates that "higher-ups" must be more qualified than, and generally superior to, their subordinate staff. Places that operate like this are likely to be locked into other old-fashioned practices that make them unappealing as well.

So if you're a good PM but don't have experience in X, while I don't think it's necessary to have experience in X, I would definitely avoid working for people who think you need it.

Brandel Zachernuk
A: 

Short answer would be Not Necessarily. You got to be good at People Skills and that is what is really needed.

Rachel
A: 

First off, I would like to say that I strongly agree with BlairHippo and a few other people who have already expressed themselves. I will try to elaborate or else emphasize (by quotes,) without repeating too much of what has already been mentioned.

BlairHippo said: "He couldn't make production-worthy code with it, but that wasn't his job -- his job was keeping all the big-picture design decisions on track and preventing the technical team from having to deal with any levels of management above him."

I would say that it depends a lot on the hierarchy of the company and what the position in question entails. Some like to combine the role of technical lead and manager into one, in which case I believe one needs to have both strong technical and management qualities. People of both qualities are extremely rare, which is why, in my opinion, it usually makes more sense to separate these two roles as much as possible.

Corin said: "That is not to say that knowing the technology in use isn't beneficial. That just means you're better able to understand the team sooner."

For your team members to "accept" you as their manager, your assigned responsibilities should not exceed your qualifications. You need a certain amount of people and communication skills to effectively handle responsibilities such as; representing your team in a production circle (which might consist of a lot of specialized teams), organizing meetings, initializing conversations, helping out with practical problems around the office, "shielding" your team from unnecessary interruptions etc. Basically, doing all the things you don't want to do as a programmer.

tzenez said: "The job of a Project Manager is to take care of all the annoying little things, like whiny upper management, like make sure we don't loose contact with the server, like replacing my chair when it accidentally breaks so I can get right back to coding. Its to deal with all the things that need to happen so your development team can develop."

Leif
A: 

A manager's main skills are soft rather than hard, so I would not expect a manager to be an expert in the technologies they are involved with. However, they do need to understand the principles so they can help and assist the team. Managers need to continually develop their knowledge of both soft and hard skills so they are expected to be familiar with a wide variety of technologies.

A manager who is an expert in a technology may be tempted to over manager the team or become to involved (to the detriment of their managerial responsibilities) too deeply in technical matters. This will not be helpful to either the manager or the team.

Ray