We Take a Systems Perspective
On Knowledge Discovery Efficiency
Systems
“A bad system will beat a good person every time.” —W. Edwards Deming [1]
KEDE is calculated per software developer. However, no individual software developer ever works in isolation but always interacts with others in an organization. That organization might be a software development team, a project team, or an entire company. To calculate KEDE for an organization you average the individual KEDE of its members.
Knowledge is a property of the system the knowledge worker operates in. It includes the knowledge of the developer, but also the knowledge of her teammates, the Product Owner, the documentation available, the applicable knowledge in StackOverflow etc.
Many people overestimate how much of the knowledge discovery efficiency is a function of the skills and abilities of the individual developers and underestimate how much is set by the systems they operate in.
The vast majority of problems are caused by the system within which people work, rather than by the individuals themselves. Therefore, you should maintain a non-blame focus on the system instead of the people. The starting assumptions are:
- People are doing their best
- A problem is a system problem, and if you were the other person, the same problem would still have occurred.
- There is a reason for everything, and we can work together to understand the reason for a problem[2].
When measuring KEDE you look at a software development organization as a black box. Even though KEDE is objective and scientifically based you should not rely only on it. There are cases where KEDE alone is not sufficient to understand how the knowledge discovery happens inside the organization. Very often you'd need a closer look inside the black box and take into account the white box. The white box goes beyond the numbers and gets into how the organization produced the numbers. You should try not to commit the McNamara fallacy that involves making a decision based solely on quantitative metrics and ignoring all other factors that cannot be directly measured. The fallacy refers to McNamara's quantification of success in the Vietnam war when success was measured in terms of enemy body count ignoring the feelings of the rural Vietnamese people because he could not measure it, so it must not be important.
"The first step is to measure whatever can be easily measured. This is OK as far as it goes. The second step is to disregard that which can't be easily measured or to give it an arbitrary quantitative value. This is artificial and misleading. The third step is to presume that what can't be measured easily really isn't important. This is blindness. The fourth step is to say that what can't be easily measured really doesn't exist. This is suicide".— Daniel Yankelovich [3]
You have to consider the roles each individual plays, the performance of each individual, the effects that individual has on the overall team performance, and what you might be able to do about those individuals whose performance needs to be improved.
Let's take as an example a team of software developers led by a senior developer. It is very likely that when you measure individual KEDE the senior developer has KEDE less than the team average. That is because usually team leaders spend a significant portion of their work day answering questions or making other people available to answer questions. In other words, seniors often facilitate others. A senior makes more seniors. After all, as the old saying goes, if you can't be replaced, you can't be promoted. Hence when you want to use KEDE to review the performance of the senior developer you should not use their individual KEDE only. Instead you should use the average KEDE for the team. If the team leader does a proper job then the average team KEDE should increase.
Works Cited
1. Source: February 1993 Deming Four Day seminar in Phoenix, Arizona (via the notes of Mike Stoecklein)
2. Rother, Mike, 2009. Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results. McGraw-Hill.
3. Yankelovich, D. (1972). Corporate priorities: A continuing study of the new demands on business. Yankelovich Inc., Stamford, CT.
Getting started
