How to specialize on a team?

Question

I have a team of three developers and all three are talented and smart but it has worked out that the professional development of the team is driven by the projects and not any major guiding force. Most major growth is started and encouraged by me (systems head) when it comes to specific technologies.

I know they are willing (and really want) to learn new things and grow. How should I go about structuring specific specializations or skills-based development among the team? Do we just pick things that interest us related to our strategic goals as a company/team or is there something more formal than that we should be following?

Have you been on a team that did this? If so, did it work? What were the pitfalls?

Answer 1

Depending on the size of your organization specialization can be easier or more difficult to obtain.

In a large organization the team lead / manager should be identifying areas of expertise for the team and accepting and or creating projects that fit within that realm.

Additionally the lead/manager should be chartering educational opportunities including courses, training material, and conferences that relate to the specialization. Later down the road as knowledge is developed through iterative project completion and maitenance the extent of contribution through specialized knowledge should expand.

Ideally as this knowledge is reaffirmed the team may start to charter initiatives that align but are not neccessarily run by the organization they are a part of. Once this starts to occur the influence and recoginition for the speicialized knowledge may extend even outside of the company the team is a part of into standards bodies etc.

In the long run specialization comes from the ability for a team to focus and be protected from tasks that do not align with their specialization. This is often not possible in a very small company when an individual needs to get the job done; however in those cases the team IS the company, and everyone in the company is part of the team so the same priciniples apply.

Best of luck.

Answer 2

Specialization is defiantly about interest, but what you need to keep in mind is that interest can fade away.

So what i can recommend you is to take it slowly.

You need to keep in mind also that a team of 3 developers that can do anything at a medium level can be better than a team of 3 developers that can only do one thing well.

But since your starting ground is a diverse team, then you should be good in the long run.

An example of how this could be bad. If one of the guy knows a lot about Flash, and he suddenly gets sick. Then what are the PHP/C#/etc developers supposed to do. But since your team is diverse to begin with, that C# coder could have had a background in Flash and could help you out.

Answer 3

This is really two questions:

1. How to guide the development of the team to anticiapte future development needs
2. How to encourage personal development of the team members

For #1, you look into your crystal ball and see the technologies, tools, techniques, and knowledge that your team will need in the future (short and long-term) and plan to acquire/provide the education needed.

For #2, you provide encouragement and some 'personal development time' to the team to pursue the things that they are interested in.

There's really nothing wrong with the development of the team being driven by the projects attacked, that is arguably the norm - but you are wise to try to anticipate this development and organize and guide it!

Answer 4

If they are talented and interested in learning, I could work in the opposite direction. I am leading a team of 5 people, and as in your case our work is project driven. I try to keep all team focused on the project needs, and whenever we can get to use a not well known (for us, that is) technology the person that is most interested gets to try it, get it to work and later explain the pros and cons to the rest.

Of course, everyone will not have the same amount of expertise as the person working out the problem, but the good thing is that a person interested in a technology will learn it better and faster by themselves than someone with a lesser interest. And later on, once they do know it they will sell it to the team better than any docs. This sessions usually end up in discussions about limitations or possible uses of the technology that the first adopter did not consider and a following iteration. This sessions are quite informal and usually short.

Usually at this point there will already be a couple of people interested, the first adopter and whoever came with the new possibility or limitation. More often than not, at this point everyone is interested in knowing about the outcome of the experiments/investigation.

While this clearly takes some time out of the pure project development, the cost is usually small compared with the advantage of spreading the knowledge among the team.

In Spain, development is a field where people switches jobs quite often, companies do not pay too well and the only way of minimizing the turnover is keeping the interest of people in what they do. At the end, you know that your people will quit at some point and shared knowledge reduces the cost of leaves.

As a final note, that works for me mostly because of the team. You need enthusiasts in what they do. At least two to startup discussions. Then the rest will probably get in the mood and follow up. But that is not something that can be pushed from above. It can be encouraged, but it has to happen in the team.