4

I've become a project manager in my company and here is what I've experienced till now:

At first, I was trying to keep in shape technically with other developers of the team (about 15 developers) and read as much as I could so that I would know almost everything going on in the project, from architecture, up to syntax consistency.

However, soon I realized that it's almost impossible for you to know everything. Therefore it's natural that you fall back in the technical race. Imagine how much work it requires for you to learn Ext JS, Angular JS, BRE, WCF, Enterprise Library for logging, Asterisk, etc. etc. all at the same time. Thus it seems to me that this is not the correct path.

I think the formula is: The more people you have to manage, the less technical knowledge you can possess.

However, there are problems in not knowing what's going on inside your team technically:

  1. You might not understand and detect bottlenecks just the way you would do when you were developing
  2. You might not decide which technology is better at performance and productivity
  3. In case of a technical dispute in team, you might not be able to help
  4. The more distance you get from code, the less you might understand developer's stress, pressures, and feelings (this is a big concern for me)
  5. You might not be able to forecast and predict the time necessary to get a task done
  6. You loose your passion when a developer talks with enthusiasm about a problem that has been solved, because you don't understand like 40 percent of what he talks about, and the less you know about something, the more boring it might become for you
  7. Developers would find it harder to explain something to you and they need to speak less technically
  8. Bad developers (rare but existing) might misuse your lesser technical knowledge and cause all sort of problems
  9. ...

This phenomenon probably occurs in any career and profession. However, since the world of development and computer in general is moving forward with more speed (comparing to say, car industry), thus in a short period of time like 6 months you feel that you've fallen back. Version after version, feature after feature, library after library, you got the idea.

I saw these questions, and they contain good suggestions.

How can I maintain my technical skills after becoming a project manager?
How much should my project manager know?
How much should my project manager know?
Should a manager (or CEO) in an IT company have an IT background to perform in the organization?
How can I convince management to deal with technical debt?

However, they're based more on personal experience and advises, which is of course good, but might not help that much.

Do we have a book, or a well-thought and researched essay on this subject, on how to manage a team of software developers, with lesser technical knowledge than team members? What points should I take into account to lead effectively and make the whole team achieve success?

Community
  • 1
Saeed Neamati
  • 18,142
  • 23
  • 87
  • 125
  • 5
    Don't try to be better at what they do, be better at what they don't do: set the environment, the standards, the culture of the team and put your money where your mouth is. If you want quality, be prepared to let them spend the time needed to achieve it. Insulate the team from disruptions and stick up for them wrt the rest of the organisation. If you want to guard against having a bad developer on the team, set goals, find good metrics (as opposed to easily gameable and not giving you what you are seeking metrics), and let the team figure out how to achieve those goals. In other words: manage. – Marjan Venema Aug 24 '13 at 16:44
  • I lol'ed at "Bad developers (rare but existing)" – Master Morality Aug 25 '13 at 14:19
  • 1
    Another question for the list of good suggestions: [how does a non-technical manager add value to a self-motivated team of software developers](http://programmers.stackexchange.com/questions/206182/how-does-a-non-technical-manager-add-value-to-team-of-self-motivated-software-de) – MarkJ Sep 09 '13 at 13:05
  • 1
    I love your thought process on how to be a better leader and not a better boss. I don't have anything to help answer your question but just know that your actions towards your subordinates not only affect their work but also their life. Bad bosses often affect a person's outlook on their field. People often hate their job field because of their bosses. Don't ever make a person say, "I hate being a programmer" because of a single person that made them think that way. – cYn Sep 09 '13 at 16:36
  • 1
    My best managers have always been the ones who had less technical knowledge and knew it. The worst are the ones that believed they had the technical knowledge and used that fallacy. Either you are a manager or a techy, make your choice. Those who try to be both end up doing a lousy job in both areas. If you know how to manage then the only remaining hurdle is to pick out the people you can trust. Rely on their knowledge for technical issues and on you for management issues. Learn where the 2 areas overlap and weigh which area should be given higher priority on each particular issue. – Dunk Sep 09 '13 at 20:47

1 Answers1

12

Some quick thoughts.

  • Be a leader, not a boss. Dont tell people what to do, and how to do it, instead give your team members problems to solve, challenges to own, and most importantly responsibility.
  • Dont hide behind a schedule. Talk to your team, sit down with them and ask them how they're going and what frustrations / issues they have. Understand what it is your team is doing.
  • Trust your team, ask them for information before making decisions that effect them.
  • Before "saber rattling" and changing how the team's working to "your" way, as often newly promoted people do. Take time to observe what works and what doesn't, and slowly fix the actual problems rather than imposing "your way".
  • Be steady, dont lose your cool, or your temper. There's always a solution, often one you never considered but someone on your team has. You succeed and fail as a team, not individuals.
  • Never take credit for things your team does, its not about you. Your job is to make them look good, and by proxy, their success will influence how people see you as a manager.

and finally

  • The temptation is often there for newly promoted people to do all the work for the team. You have a team for a reason, they want to help you. Use them, let them help you, let them take responsibility for things. delegate. Accept that you will not actually get any "work" done, but the things you will do instead are far more valuable to the team overall.
Matt D
  • 1,035
  • 6
  • 10