| || |
Deming\'s 7th point
“7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.”
A supervisor should not just watch the production line and give commands to the workers, this is very embarrassing and may be insulting also. Instead if there is any problem then a supervisor should get into the line and help workers to solve the problem (by coming to their level) (Here comes importance of training). This will help to keep working atmosphere healthy.
“Supervision of management is in need of overhaul, as well as supervision of production workers.” Does this mean, existing supervision structure is not proper and we have to improve it? While doing supervision the workers, supervisors shall supervise them selves for improvement.
Re: Deming\'s 7th point
Perhaps this is one area where, at least in my experience, software development has differed from other areas.
I typically see that software teams, at least in the engineering component, arranged in groups such that there is a position denoted as lead, not as manager. Typically the lead is a more senior programmer, and is directly charged with mentoring of the other team members.
In other situations I've seen the team manager play a very constructive external team role. Their position was not so much as to manage members of the team, but to facilitate the fulfillment of team needs as a whole -- often forming an isolation layer between the dedicated team and the business environment in which they operate.
Perhaps this style of management is more resultant from a shift in style, as advocated by Deming. Perhaps this style of team dynamic is helping facilitate that shift in style. I think the influence is likely bidirectional, and perhaps the software industry has somehow managed to escape the throes of dictatorial management...
...alas, only if we consider the whole, certainly more than a number of instances invalidate this claim.
Re: Deming\'s 7th point
It is hard to really get the feel for this point at a visceral level unless you study history and realize that Deming, in the entirety of his point, was issuing a bold contradiction to traditional management theory, particularly management-by-numbers. The key here is on "leadership" and it is important because, like Jonar Nader, Deming was one who advocated that a leader is not necessarily one who engages in leadership. I will quote Nader and his ideas on this in relation to Deming:
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>
"Leaders are pathmakers - those who cut a new path, with or without the help of others; for their own sake or for the sake of others; for monetary gain or otherwise; for adventure or duty; in misery or delirium. When a leader cuts new paths, most often the outcome is tangible. On the other hand, leadership defines the framework (the condition under which paths are carved); and most often this is intangible.)"
(The above comes from Nader's book How to Lost Friends & Infuriate People: Leadership in the Networked World.)
Leadership is the "why" to the leader's "what". And this is important because as you have been going through Deming's points, you have been seeing on emphasis on getting a certain type of mentality throughout the organization geared for improvement and improvement initiatives always have to be justified with the answer to various "why's". "Why should we do this?" "Why will this help us?"
Also, Deming's emphasis on leadership (which, by the way, falls directly into Point 8 about managing without fear) involves another transformation, just as I said in previous posts Deming advocated business and management transformation. Here the tranformation is in the role of the strict manager and supervisor (a somewhat vague term) as a type of mentor. Remember his previous points indicate that management plays a central role in the establishment of a quality regime and the whole aim of leadership, in Deming's view, is to carve the path (or provide the framework, in Nader's words) to help people look for opportunities for improvement and to craft better systems that provide prodcuts and services.
Another crucial point is that leadership is not just supervising. In fact, it is not supervising at all in the sense that this might fall to a leader. One part of this is that management should not just be acting as a judge of the individual performance of various people and come up with arbitrary ranking schemes for that. A manager exhibiting leadership should, according to Deming, devote his or her efforts to cultivating each person as an individual so that all people, working in teams, can perform to their greatest potential and, at the same time, in a manner consistent with the organization's overall aim of being efficient and competitive.
I would say that, in Deming's terms, leadership can be broken down by bullet-points. Leadership means:
<LI> Knowing the work one manages.
<LI> Knowing common causes and specail causes of 'quality problems'.
<LI> Removing the barriers that prevent staff from taking pride in their work and doing a quality job.
<LI> Establishing accurate and consistent performance measures.
<LI> Knowing how their team's processes fit into the goals of the organization.
<LI> Knowing how their team's processes fit within the upstream and downstream processes.
<LI> Knowing that one-half of any staff will perform 'below the average' of a group.
<LI> Building trust and providing help without the emphasis on judging.
<LI> Leveraging the skills of all staff.[/list]
All of this means facilitating leadership and a leadership mentality within the organization. This ties back into all his points so far (and a few to come). It also pays to consider that management by numbers (which strict leadership practices do not advocate) does nothing more than maintain the status quo on what are essentially arbitrary numbers of performance and this tends to have the effect of decreasing productivity and increasing costs as a result of non-quality processes.
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by AmitK:
“Supervision of management is in need of overhaul, as well as supervision of production workers.” Does this mean, existing supervision structure is not proper and we have to improve it? While doing supervision the workers, supervisors shall supervise them selves for improvement.<HR></BLOCKQUOTE>
The whole point was that Deming wanted to show that in order for his management and business transformation ideas to work, there had to be a transformation of what "supervision" meant and how that applied to the concept of leadership. Deming felt that management's goal was to lead process improvement, not to just supervise workers and achieve quotas. In fact, Deming had pointed out that focusing on quotas and productivity numbers at the expense of other more viable measures, was a major cause of many quality problems. The emphasis as Deming ssaw it was on speed and productivity and his point was that quality suffered. Hmmm. Does that not sound quite familiar to problems we have today with product development?
Re: Deming\'s 7th point
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by mortoray:
I typically see that software teams, at least in the engineering component, arranged in groups such that there is a position denoted as lead, not as manager. Typically the lead is a more senior programmer, and is directly charged with mentoring of the other team members.<HR></BLOCKQUOTE>
In software industry clashes (due to improper communication) between programmer and lead to disasters because only that programmer knows what he/ she had written.
Chances of such tye of clashes are more in softwar industry than any other industry.
Re: Deming\'s 7th point
I think that AmitK is not mistaken to assume that the software industry appears to produce more clashes within teams than other industries. While certainly there are endless anecdotes of clashes in other fields, I feel certain that there were, may still be, more clashes in software development.
This does not dispute my argument about a more open team structure.
Many businesses have opened on the premise of developing software. For many years, and to many people now still, software appears as an easy field to enter, and programmers can be picked up anywhere. A great number of businesses exist in the form oblivous of structure -- ignoring the titles that were assigned on the business cards.
A team without a leader will have clashes, and they will likely be fatal to the company.
A team with a genuine leader will have clashes, but those will be resolved without dealing a major blow to the company. If only one individual understands a particular set of code, it should be easy to argue that no such mentoring system existed, and that the leader wasn't really leading, since they were unaware of what they were leading.
I always draw a distinction between development organizations and chaotic programming teams. There is a fundamental line between these two. While the first may start out extremely disorganized, over time they may grow into a mature organization. The latter have no chance of maturing, but if lucky they will grow, but then eventually have to dismantle most of the team as the chaos becomes overwhelming.