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.
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.
Leave a comment