How to fight against "job-security" employee-principle using the "Circles-of-knowledge" manager-principle

This is a great principle I learned from a great manager in one of the last jobs I had.
I`ll start describing the problem that this principle solves by a true example:

A startup company , lets call it , "the guild" has 20 good dedicated workers which build a great and complex piece of software. As "the guild"`s buisness is blooming they want to recruit 20 new employees each year.
Some of the existing employees, usually the less bright ones , fear for their job/status when the new employees arrive and think of a clever way to have "job security". They do not teach the other employees anything about the systems they are working on and remain the only one knowning how to operate these systems.
At the first year, the company still manage fine. The new employees work tend to "flow" around the old employee`s systems and the new and the old work in hamoney.
At the second year, the old employees understand that they are the only ones knowing how to operate the core systems and they demand better salary/promotion etc. The manager ask himself (and some of his workers) can anyone else knows how to do thier jobs ? as the answer is negative - they did not allow anyone to get near those core-systems , the manager promotes the non-bright people to a team-leader jobs.
At the third year , those team-leaders , continue to use the principle that helped them advance so well , on their previous jobs (the core-systems) and the new jobs: their whole new team don`t allow anyone near their code.
At the fourth year , the "job security" principle is so bad , that no team can work with another team and no new feature which needs inter-team cooperation can be done.
The employess demand a raise again , and as they are now totally irriplacable , get it.
At the fifth year , the employees are getting bored and decide to move to another company. They allow one month notice in which they will be willing to explain all the core-systems that they wrote to the new employee replacing them, but one month is never enough to pass a five years body of knowledge.
At the sixth year, things in the core-systems , which now are not maintanaced by anyone , start to break. No one knows how to fix them and the core-systems are slowly getting deprecated and finally shut down.

This is a true story which happend in various teams in the same company. I`ll bet you met at least one employee which is creating his "job-security" in every big company you worked on.

Some of you are probably running to the "comments" and going to tell me about the great software development methadologies you are working on ( like "Agile/XP") who succesfully solve this problem by making sure that no one person will ever be responsible to one component.
So let me say one thing, Agile/XP solve this problem , but creates another, even more serious one: Instead of only one person knows how to work with the core-system , Agile/XP makes sure that NO ONE will know how to work with the core-system.

Lets me describe the "circles-of-knowledge" solution (again, a young manager I worked with created and perfected it. Im only describing his idea). It can be summed by three simple principles:

1. Inner circle principle - Every big feature will have few(1-2) people which are responsible for it and have excellent knowledge on the code/bugs of the feature.
2. Outer circle principle - When coding/bug-fixing a big feature, few(1-2) other people will get tasks related to the feature which they are not in its inner-circle.
3. Make sure the circles overlaps and interwind as much as you can, creating good redundency among your employees

Usage example:
On our team there there are 5 people ,lets call them A,B,C,D and E. The team task is to develop a client-server system with 4 components, with the following man-hours percentages:
server side framework (20%) , server-side application(big feature 40%) , client-side framework(10%) , client-side application(30%).
This is an example , of work-division according to the circle-of-knowledge principle:
A: inner circle - server-side FW outer circle - server-side apps
B: inner circle - server-side Apps outer circle - server-side FW
C: inner circle - server-side Apps outer circle - client-side FW,client-side apps
D: inner cirlce - client-side FW outer-circle- server-side apps
E: inner circle - clinet-side apps outer circle - client-side FW

This is only one example , of a possible division. The important thing to note is that big features will have more than one people in the inner-circle , and few on the outer circle too and that even the smallest feature will have someone in the outer-circle which have knowledge of it.
And as there are more employees (imagine same team with 10 people) the cirlcels overlaps become clearer.



Using these priciples , it is easy to see the end result:
Redundency - you can "loose" 2 employees and still have excellent knowledge coverage of all the features. Even if your "loose" half of your team, you will still have excellent knowledge about the inner-circle features , and reasnilblee knowledge of the other featues , they covered as part of their outer circle.
Resposibility - at any given time , each employee is directly responsible for a feature of his own. . It is clear who can help in a problem. It is clear who to praise for a job well done and whoto blaim for a system defacts.
Efficency - As all the features are covered with excellent level of knowledge , it is easy to develop new code or solve bugs. There is never a "black-box" feature which all dread to touch.
But you never incrase the outer-circle to the whole team, preventing the problem of "all-need-to-know everthing but end up knowing nothing".


A final note to clear things up: The division to the circle of knowledge is being created over a period of time , meaning , don`t go and divide each two-weeks feature into 4 different people (thats the mistake agile/xp guys tend to do). Instead, make sure that over a long period of time , like 3-6 months , you slowly create this coverage. Example; The first team (inner-circle) will do the core feature on the first 2 months. In the 3rd month a small feature needs to be added - assign one guy from the inner circle and one from the outer-circle. In the 4th month another small feature is added, again , put one from the inner circle and one from the outer-circle , and so on and so on.

Using this method , is not easy at first for the manager, cause it requires a lot of premeditation of his part, but it is worth it. Who said the work of a manager is easy ...