I manage 6-7 developers offshore. This is how it works. I assign them some task. They complete the task. When I do the code review and find that this could have been done/ should have been done in some other way which is better then they do not feel comfortable. I am also a developer so I am also doing the development along with managing them. Wherever it is possible and required I give them proper direction and many a times explain the full logic. I also understand that we all make mistakes i.e. we may not code everything perfect in first attempt. but when I point it out, they feel bad. Why is it so? Is it because I have almost same years of experience as they have and I am managing them? and few developers are even more experienced than me?
I know there are lots of people here, who do the management in nice way. I would like get some tip. I want to manage my team in friendly manner.
Just do not tell them what to do but instead have a proper planning and work as a team and try to get the feeling out of them that you are leading the team. I have similiar experiences where in I managed a team of 3 people and two were more experienced than me. I found two things that did work... One is either you should prove that you are technically far far superior than your fellows... for example if the work involves doing development with Spring, then your team should beleive that you are the expert and the master than them in Spring... and once this is there, then the team automatically listens to what you say. The other way is to be friendly and maintain a good atmosphere in the team by considering yourself as one among them.
One is either you should prove that you are technically far far superior than your fellows... for example if the work involves doing development with Spring, then your team should beleive that you are the expert and the master than them in Spring... and once this is there, then the team automatically listens to what you say.
That's unlikely to work for any prolonged period of time. Managers can't possibly keep up with the technical side of things at a level of detail that's superior to the team members who do it on a daily basis. It's almost the definition of a tech job that a person knows more about the details of her work than her manager does. It may work for very small teams where team management is just a side job of one of the team members.
Ping & DNS - updated with new look and Ping home screen widget
I've managed an offshore team before and my role was largely hands off, but I was also training some of the developers in using some of the Weblogic proprietary technology (been so long I can't remember what it was called now).
Code quality was a constant issue, but a lot of it was working with the team lead to communicate problems and letting him work with developers who were less experienced. I was the expert, he was the mentor, and when need be I had to lay down the law on occasion to make sure everyone's work was up to standard.
I don't think it's about being nice and I think they might feel bad. The question is, what are they doing about it?
Offshore teams can be a tricky prospect simply because of your lack of physical presence. You really need to have someone you can trust as the lead developer who can help enforce quality and coding standards. I wouldn't worry too much about your level of experience, I have managed many people older and more experienced than myself. Part of being the boss is accepting that responsibility. You need to manage performance, be clear on what your expect, and make sure you acknowledge when a good job is being done.
Age shouldn't matter. I have more years of experience than many people my age.
Years of experience shouldn't matter. It's the quality of experience and amount of experience in what is being reviewed. if someone has 30 years of experience, I'm going to able to provide more useful Java code review comments.
Respect takes time to earn. Especially if you are remote. One question - are you being seen as a threat? People are often more responsive to code review comments if they are being provided as constructive and the reason why rather than evaluation.
You should visit them once in a while, e.g. once a month, and take them out for lunch and share who you are and give them a chance to get to know you. Basically, if you are a poor communicator, then you won't be able to lead effectively. If you cannot build respect, then your technical judgement will never be trusted by the developers.
A tricky aspect is that if they do indeed have more experience and knowledge than you, and you attempt to manage them with a "I'm in charge, my decision is the final say" strategy, they will consider you a joke and never permit you to lead them.
If you have more experience and knowledge and are unable to get them to follow your lead and direction, then you have a wrong set of developers and need to find some other replacements.
Matter of fact, if you are still doing development, then you most likely have more to learn and may be prematurely managing developers. If possible, stop your development activiites and focus solely on managing the developer instead of being a developer.
The lead dog cannot run with dogs alongside him, he must be in the front.
Henry Pinkerton wrote:Matter of fact, if you are still doing development, then you most likely have more to learn and may be prematurely managing developers. If possible, stop your development activiites and focus solely on managing the developer instead of being a developer.
It actually sounds to me like Vikas is more of a team lead than manager. A manager who has stopped developing doesn't generally do code reviews.
Joined: Aug 16, 2007
Thank you guys for your valuable inputs. I thought over the matter and I concluded few more points.
- I always copy my senior (Programme Manager) on all the emails, that includes developer appreciation as well as their mistake emails. Should I keep it between the us only?
- As I have said before, along with managing them (not like manager but Project Lead) , I also need to do the development. Because, tasks are also assigned to me . So I am always under pressure. Deadlines are there for me too. I always think that if I only had to manage or develop, I could have been more productive.
People are often more responsive to code review comments if they are being provided as constructive and the reason why rather than evaluation.
That's exactly what I do. I explain them, how my suggestion may be better than theirs. and there they get pissed off (feel bad). not all but one/two.
I want to create my picture like, even if they leave the company, then they should say "Yes, we learned something and it is worth putting into practice."