Usually a team members have different skills of work (coding, communication, analyse and others). What PM can do to minimize the difference of skill in the team? Especially to grow average of skills level.
3 Answers
Usually PM doesn't have direct superior-subordinate relation with a project team so they can't just tell people to improve specific skills. What you can do is you can encourage people and try to convince them it would be good for them. After all they do grow as professionals that way, don't they?
You can also propose practices and techniques which are valuable for a project and at the same time they foster learning process among team members. Code review is something which comes to my mind in the first place. It helps to share knowledge about project itself but is also a great platform to exchange technical experience.
Having said that, you can't force people to adopt specific practices. As long as they don't see value for themselves they will either skip the practice or do it just for the sake of doing it, which basically makes it worthless.
Of course you can try to talk about the problem with functional manager(s) of discussed people. They have more power and often more authority over people so it's easier for them to convince people to adopt specific methods. Having the same background, e.g. a development manager who was once a developer, also plays its role here.
Having said that, I'm not sure you set the right goal. Personally I wouldn't try to minimize differences between people's skill sets. Actually vast majority of teams can leverage skills which are completely different. I would rather look for methods to help people to excel in their areas of competency than look for get everyone on average level with everything they do.
answered Jul 13, 2011 at 7:24
-
1+1 for areas of competency and focusing on strengths rather than weaknesses! I'm going to go into more detail on that I think...– LunivoreCommented Jul 13, 2011 at 15:37
-
I don’t like to force everyone to know most of things. I mean by ‘skill’ word the common toolbox of techniques like clean code, TDD and others. This toolbox have direct impact on the quality and time. I’m thinking about code review to apply in my environments. I will try to make code review for part of code to minimize time and cost of this activity. I like very much when I can see that team members are learning some new things. I would like to avoid situation that we are ‘professionals’ which cannot be surprised by next projects. Question is how to bust the team to make learning progress?– hsdCommented Jul 16, 2011 at 21:56
Find out what people are good at - the areas in which they are strong, rather than weak or merely average. Then encourage them to grow their strengths.
This will help them to know that you value their skill, rather than their weaknesses, and will make them feel safe. Safety helps learning!
Because they will be growing their strongest skills, others will get to see those skills in action too - so even weaker team members get stronger as a result. Weaker team members will have role-models for those skills, and will be able to act as role-models in the skills in which they are good, so confidence will grow too.
Rather than minimising the difference in skills, I would focus on maximising the overall skill of the team - which means using the strongest skills appropriately, and letting those strong people share their skills. Encourage teaching and mentoring (especially novice/expert pair-programming if you're in software). Allow the team to admit their weaknesses and use other team members to cover them. For instance, I am awful at estimating. Rather than being better at estimating, I would ask others how long it would take. Their better estimating skills make up for mine, and allow me to be free to do things I am better at.
In one project, we put up a list of skills and areas of code, languages, etc. and allowed people to write in other team members' names if they thought they were good, so that everyone knew who they could learn from if they needed help.
This also has the side-effect of letting the team bond and self-organise. Bonus!
If you would like to read more, I wrote about building experts with the Dreyfus model.
-
Thanks for the answer. Right now I'm doing the same thing as you propose. We try to organize the pair-programming . I recognized a few thing which made this method very slow: everyone is ‘professionally’ because is earning money. That means is not ease to admit for weakness points. Experience developers doesn’t like to work with the not experience developer. ‘This is not my part of code’ Do you have some additional practices to eliminate this obstacles? I don’t like the idea of assign work depend on the personal skill. I would like to give this kind of decision to the team.– hsdCommented Jul 16, 2011 at 21:27
-
I like to create an environment in which learning and mentoring is valued. For instance, I use, "What I learnt yesterday... what I hope to learn today..." in stand-ups. Create a safe space - you can run safety checks in retrospectives, etc. If senior devs don't want to mentor, ask them to help the more junior devs. Make pair-stairs and put up the "experts" board - people are more likely to help and mentor if they feel their expertise is recognised.– LunivoreCommented Jul 18, 2011 at 8:47
Training and practice with a good feedback loop can grow competencies to some degree. Each of us presents with varying limitations, motivations, and personalities so results can vary to no growth to a lot of growth in some or more areas.
But like Pawel, I question why you want to do this. All projects should have some training aspect to it, but I think a PM smartly limits its scope to training only those things necessary to do THAT project at THAT time, e.g., project's methods, processes and procedures, not a general growth in a person's skill set. They would get that as collateral damage, but that should not be a PM's goal. An operations manager would have that goal, but a PM is dealing with constrained resources, including time. It is a make or buy decision and, for projects, I think in most cases you buy it.
Your team comes with varying strengths and weaknesses. You would get more bang for your buck by simply aligning your work with the strengths of your team, allowing one team member to make up for a weakness of another.
answered Jul 13, 2011 at 10:19
