Recently in Know-how transfer Category

As I have promised in the previous post, I would like to share some tips on how SourceKibitzer EyeQ helps you with the problem of high attrition rates.

Basic idea is simple: identify your key programmers, and be prepared if they go away.

1. How to identify key programmers. I already can hear lots of opinions telling that it is so simple and that it is always clear who is the key developer in the team. In some cases it is true. For example, if you have 5 developers in your team and they sit in one room, it is indeed very simple to know who is the guru. But finding the key developer is getting very difficult if the team is distributed, you use outsourcing service provider, or just your team is so big that you just can't be up to date with everything.

So here comes the EyeQ team report into the game. Take a look at Team Benchmark. Pay attention to the metrics know-how and unique know-how. Those indicate the employees breath of knowledge in your project. With know-how metrics it's fairly simple to see who actually holds the critical knowledge in your software project and therefore is the key developer. All developers who have know-how higher than 5.0 should be treated as key developers. You should pray for those who have higher than 8.0. For example, in SourceKibitzer we plan to introduce following motivation rules: developers with know-how higher than 5.0 will get 25% salary increase, developers with know-how more than 8.0 will be provided with share options scheme.

2. OK, you have done a lot to keep you developers with high know-how indicator. But it is not always possible. What should you do if you have just learned that one of the best developers will leave your company in just one month. Unfortunately, you don't have too many options...you have to find programmer to replace the leaving guru. Companies deal with this problem differently, but here I wanted to show you how EyeQ alumni report can help you with that issue. First, take a look at Unique Know-How Distribution. The orange section of the graph give you the idea of how big your problem is or in other words how much unique knowledge is in hand of the developer who is going to leave your company. The higher this number, the worse your situation is. But don't give up :) and take a look at Components with Alumni Know-How section of report. Here you will find the list of all components that the soon leaving developer(s) has unique know-how in. This information can make you feel better, as now the scope of the knowledge transfer is more or less clear. Great. But EyeQ Alumni report can also help you to find the suitable employee from your team to overtake the knowledge. Take a look at Know-How Holders report section now. On the left you see the developer who is planning to leave and on the right you see the list of developers who has shared know-how with him. Those are your best candidates inside your team to replace the quiting developers.

So to conclude the post, here a short summary. It is a huge problem if your programmer decides to leave your company. SourceKibitzer EyeQ can help you to handle this problem with 1. Track know-how metrics to know you key developers; 2. Estimate the size of alumni know-how; 3. Find out risky components, that quiting developer has worked on; 4. Identify best candidates from the team to take-over the knowledge.

There are so many articles teaching you the management of software projects and teams. Lots of talks about processes,  motivation, and so on. In this post, instead, I would like to concentrate on the not so popular issue that most of companies are facing. The issue of too many programmers quiting your team every year.
 
Let's imagine...There is a company, lets call it SupaCo, which has outsourced all of its business critical software development efforts to good reputation offshore service provider - RepuSP. RepuSP has hired the team of 25 software developers constantly working for the SupaCo. Everybody is happy :) RepuSP charges 40 EUR per hour and is happy to have almost a 2 million yearly contract. SupaCo is happy to have professionals working for them and fewer problems they need to manage.

Interesting stuff starts to happen after one year. Vendor manager from SupaCo, who is responsible for relations with the service realizes the fact, that every quarter one developer quits the team. From service provider perspective it is no a big issue, as it makes only 16% attrition rate which is not too bad for the industry.

But SupaCo vendor manager tries to calculate how much the problems is worth in euros/dollars. Simple calculation gives him the following:

• SupaCo pais 40 EUR per hour for each developer (~6,400 EUR/month)
• It takes 2 months to train new developer
• 1 developer from active team should mentor the newcomer for this period of time
  

Simple formula 2 months X 2 developers X 6,400 EUR X 4 (quit developers) gives you more than 100,000 EUR per year. Not a small money even for super SupaCo...

But the training costs is not the only factor you should consider. Be also prepared for:

• Every quiting employee punches hard the good relations between SupaCo and RepuSP.
• Some know-how is not easy to transfer just by the training.
  
• There is a risk you would need to pay quiting employee to be available to answer questions.
• It could take another 3 to 6 months for new programmer to reach efficiency of previous specialist.

The formulation of the problem was the goal of this post. In one of the next posts I will try to cover some tips on fighting this issue and discuss how our product can help you. So stay tuned.

Good luck with offshoring/outsourcing/near-shoring/opensourcing/multi-sourcing
Mark