Showing posts with label software development. Show all posts
Showing posts with label software development. Show all posts

Sunday, August 17, 2025

Leadership in Total Quality Organizations

Introduction

How can leaders create a followership in a quality culture? Leadership for quality requires customer focus, an obsession with quality, teamwork, continuing education and training, and an emphasis on best practices and peak performance (Goetsch & Davis, p. 125). Those are end-results, however. How do we get there?

This post begins by examining the character traits of a good leader. Next, we describe a specific type of team and describe a leadership style that works for such teams. We then evaluate the different leadership styles described in Goetsch & Davis against that team. We find that only one style seems to work – and that style is rejected by aficionados of total quality management (TQM)! We conclude with a modification of this style that addresses the shortfall.


Leadership Characteristics

For a leader to lead, he must possess certain virtues that make him worth following. The leader must display self-confidence and have characteristics such as self-discipline, honesty, credibility, common sense, stamina, commitment, and steadfastness. (Goetsch & Davis, p. 128-129). These traits are a subset of the U.S. Marine Corp’s leadership traits captured by the acronym JJ DID TIE BUCKLE (justice, judgement, dependability, integrity, decisiveness, tact, initiative, endurance, bearing, unselfishness, courage, knowledge, loyalty, and enthusiasm) (Mangiameli, 2014).

A leader must act in a way that his followers will detect these traits and work with the leader in a win-win manner (Goetsch & Davis, p. 130) that ensures the customer receives quality products and services, and that quality is continually improved. This way of acting is called a leadership style.


A Particular Type of Team

The leadership style must be tailored to the individuals or team that must be led. Instead of considering which style works best to inspire a team to achieve a customer-centric and quality-focused environment, let us consider a team that is already centered on customer satisfaction and quality improvement and see how they react to various leadership styles.

Consider a team of extremely competent and aggressive software engineers. They are exceptionally productive workers, frequently sleeping under their desks, or bringing tents into the office, or working multiple 24-hour days. They have zero tolerance for bureaucracy or prevarication. Such software engineers have large egos of necessity. The best way to accommodate that factor is to keep team sizes as small as possible, and the responsibilities of the members within the teams should be non-overlapping.

Of any potential leader they would ask: “what qualifies you to be a leader?” From experience, the best type of leaders would be those who are/were software engineers. The leaders need not be top-notch engineers, but they must be good enough to be respectable.

This type of leader will be both well-grounded as well as have a long-term strategic outlook. They can communicate both short-term and long-term goals with their teams. Any explanation of “why” is either short or unnecessary – they all know why they are there. When communicating goals, the last thing a manager should do is to use the corporate-speak word “vision,” as the software engineers would suggest they adjust their medications!

This type of leader knows to set the direction and get out of the way - excellent software engineers are not led, they are unleashed.

All of this cannot be called a complete theory of leadership, but it is a rough outline of one. Does this leadership method fit into any of the leadership styles described in Goetsch & Davis?


Democratic and Participative Leadership Styles

Democratic leadership and participative leadership are similar in that both use group participation in decision-making with the goals of empowering employees and encouraging shared responsibility. Both use frequent public recognition to boost morale and encourage engagement. The main difference between them is where the decision-making authority lies.

In democratic leadership, also called consultative or consensus leadership, the leader makes the decisions only after receiving input and recommendations from team members. This can even be formalized by having the leader place multiple options up for vote and using majority rule.

With participative leadership, decision-making authority is shared more evenly across the team members. The leader may hold regular meetings to discuss ideas and build consensus through dialog.

From the standpoint of the high-performing software team, leaders using either participative or democratic leadership styles are seen as weak and feckless. Software team members would be concerned that individuals who do not have the proper technical knowledge or who aren’t “stakeholders” are somehow involved in the decision-making process.

Under democratic leadership, and to a lesser extent participative leadership, trust is very easily broken. This certainly will be the result when the leader gathers team member input after a decision has already been made. The high-performing software team will regard the efforts to elicit and provide input as wasted time, and any attempt by leaders to build consensus will be seen as really an effort to manufacture consent.

Finally, frequent public recognition for team members is seen as a “dog and pony show.” This is not to say that software should not be demonstrated; rather, software should be demonstrated to the relevant people on an as-needed basis, and without ceremony.

In summary, then, both participative and democratic leadership styles will be ineffective in leading teams of high-performing software engineers. Leaders will be seen as weak and indecisive, and trust can be easily broken. Further, confidence in the leader will be in doubt, as their ability to lead is based on things like consensus building instead of any actual talent.


Servant Leadership

Servant leadership is “a philosophy and set of practices that enriches the lives of individuals, builds better organizations, and ultimately creates a more just and caring world.” (Greenleaf, 1970).

Servant leaders use “active listening” to make their team members “feel heard and valued, fostering a culture of open communication.” They are also committed to “healing” which means “[R]ecognizing the importance of emotional and mental well-being” so as to support “both themselves and their team in a way that nurtures a healthy, balanced work environment.” (IMD, 2024)

A common criticism of servant leadership is that leaders suffer from burnout because they ignore their own well-being. Another criticism is that it may clash with certain cultures (like the culture of a high-performing software team). For that, it may be better to determine which cultures with which it does not clash.

For the software team described above, servant leadership is in many ways worse than democratic or participative leadership styles. Servant leaders are not leaders at all, with their emphasis on empathy, active listening, relationships, and caring. High-performance software teams do not need to talk about their feelings over a pint of ice cream.

Further, servant leaders do nothing to earn the respect of the team of software engineers, and in fact they actively diminish respect. Weak leaders are seen as weak individuals, and that carries the baggage of falseness. In times of crisis, they are not paragons of strength, which is what is needed in those situations.


Goal-Oriented Leadership

According to Goetsch & Davis, goal-oriented leadership – also called results-based or objective-based leadership – has leaders focus solely on the goals at hand. “Only strategies that make a definite and measurable contribution to accomplishing organizational goals are discussed. The influence of personalities and other factors unrelated to the specific goals of the organization is minimized.” (Goetsch & Davis, p. 128)

Goetsch & Davis note that team members could be so focused on specific goals that they can overlook opportunities for improvement. For this reason, total quality workplaces should reject this leadership style.

Will goal-oriented leadership necessarily devolve like that? Companies that employ high-performance software teams frequently have “lab weeks” which gives them the opportunity to work on projects outside their usual domain. This leads to developing projects that represent new revenue streams or otherwise improve company operations.

Perhaps with this modification, goal-oriented leadership would be appropriate for the type of software team described here.


Conclusion

Building a following in a TQM environment necessarily involves finding a leadership style that maximizes employee engagement and challenges them to continually improve the quality of the goods and services that employees produce.

To do this, leaders should have some level of popularity among the team he leads, while maintaining a professional distance. Leaders must have a sense of purpose, and they must demonstrate traits such as self-discipline, honesty, credibility, common sense, stamina, commitment, and steadfastness. (Goetsch & Davis, p. 128).

The leadership styles presented in Goetsch & Davis allow most of these traits to be displayed by leaders – the major exception being credibility.

There doesn’t seem to be a single leadership style that covers every type of employee or team. Some people would flourish in one style, others – like the software team described here – would find that leaders are either not worth following or even that the leaders inhibit achieving a total quality workplace. An appropriate leadership style can maximize all the qualities of a total quality workplace, and an inappropriate style will cause quality standards to fall and result in team members leaving.


References

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9th ed.). Pearson.

Greenleaf, R. (1970). The servant as leader. http://www.ediguys.net/Robert_K_Greenleaf_The_Servant_as_Leader.pdf

IMD. (2024). Understanding servant leadership and how to implement it in 9 steps. https://www.imd.org/blog/leadership/servant-leadership

Mangiameli, M. (2014, 21 October). How to apply Marine leadership traits to business. Task & Purpose. https://taskandpurpose.com/sponsored-content/14-marine-leadership-traits-apply-business/

Software Development in Total Quality Organizations

Introduction

Who is empowered in an organization to meet the needs of the internal or external customers and why? For purposes of this post, a software company will be the organization in question, and the process of developing new software will be considered.

In multi-phase processes like adding a new feature to a software product, the customers will change according to the phase, and the person most responsible for meeting customer needs will also change. We will call this person the “meeter-of-needs.”

We begin with the description of the phases involved in creating a new software feature. A table listing the customer and customer needs at each phase is presented. We conclude by describing the factors that increase overall completion time and some ways of decreasing that time.


Creating a New Software Feature

Consider the situation where a new feature is to be introduced into an established software product. Assume the software product primarily has external users (customers). The steps to accomplish implementing a new feature can be organized into the following phases: feature definition phase, development phase, testing phase, deployment phase, and post-deployment phase. Here, “deployment phase” means making the new feature available to external users.

The feature definition phase starts when someone has an idea for a new feature. This idea usually does not come from external customers but rather from internal personnel (subject matter experts (SMEs), developers, QA testers, or managers). This phase is usually short, taking just long enough for functionality to be specified. Developers are the ones who will find exceptional situations (called “corner cases”) and will work with SMEs to determine how the feature should behave in the corner cases. For minor features, no cost estimates are needed. The developer will provide an extremely rough estimate for time needed to implement the feature. Note: there is no reliable way of accurately determining this length of time.

In the development phase, the developer writes code that implements the new feature. This phase also includes something called “local testing,” which is where the developer tests his code on his own computer or on a computer called a “development server.” A good software developer will test not only the expected use cases but also the corner cases. If necessary, he will also do performance measurements, to determine how fast the new software runs and whether it consumes an unnecessarily large amount of memory. If problems are found, the developer will fix them.

Larger software companies, where bureaucracy is deemed acceptable, will then perform a code review, which involves other developers reviewing the code and providing feedback to the original developer. Automated testing scripts in the form of “unit tests” may have to be written by the developer. This usually requires the delivery time estimate to be tripled.

Next, the code will be deployed on what is called a “QA server.” This is the server on which the QA tester or staff will perform their own tests. If any problems are found, QA would describe the problem directly to the developer, who must then fix the bugs. The QA phase restarts. The act of deploying the new software is performed by a “dev-ops” person, which is a title for system administrator.

Finally, the code is deployed to the “production server” by the dev-ops engineer so that external customers can use the feature. Sometimes, the feature is released to only a subset of all customers, called “super users,” and they will use the feature before it is released for widespread use. If any bugs are found, they are reported though customer support, and QA will formalize these as bug reports. The developer will fix them, and the code will then be re-tested.


Table of Customers and Meeter-of-Needs

Phase End-of-Phase Deliverable Involved People Meeter-of-Needa Customer
Feature Definition Feature specification All relevant people (manager, devs, SME, QA) Manager Developer
Development Functional software running on QA server Developer and dev-ops engineer Developer and dev-ops engineer QA
Testing Go/no-go decision plus bug-reports if no-go QA, developer, and maybe dev-ops engineer QA Dev-ops engineer (go) or developer (no-go)
Deployment Software running on production server Dev-ops engineer Dev-ops engineer External customers (end users)
Post-Deployment Bug reports End users, customer support, QA QA Developer

Conclusion

As shown with the use of multiple quality checks, as well as the opportunities to improve software quality, companies following this process are certainly focused on meeting customer needs and continual improvement (Goetsch & Davis, 2021). The “process” described here is part of what is sometimes called “cowboy programming” (Siqueria, 2023). This has been shown to work even in large software companies, at least among high-performing software teams (West, 2007). Cowboy programmers are often dismissed by other types of developers, which cowboys refer to as “stodgy dilettantes.”

The Herd Quitter by C. M. Russell, 1897

In low-bureaucracy companies, this entire process from conception to widespread release will take two or three days. Otherwise, the process could take weeks or months. Sources for this delay include reliance on so-called “agile methodology” (Martin, 2008), the presence of irrelevant people in the process, absolute requirements for unit test scripts, and incorrect feature definition. Also adding to the time are situations when developers who fix bugs are different from the original developer.

One way of minimizing the time is for developers and QA testers to work closely together, especially during the testing phase. In that way, bug reports can be communicated directly to the individual responsible for fixing them. Another way to minimize the overall time is for developers to get involved in the feature development phase. This eliminates the need for the developer to get repeated clarification from SMEs. To minimize completion time in general, minimize the number of people involved – include only needed personnel, but no fewer.


References

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9th ed.). Pearson.

Martin, R. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Pearson.

Siqueria, S. (2023, 5 June). Cowboy coding style. https://dev.to/sarahcssiqueira/cowboy-coding-style-3d9l

West, M. (2007, 3 January). What is cowboy programming? https://cowboyprogramming.com/2007/01/03/what-is-cowboy-programming/