Home > Articles > Programming

  • Print
  • + Share This
This chapter is from the book

The Management Challenge

An effective software leader is more concerned with the work environment, attitudes, and behaviors of his developers than with meeting his own manager’s expectations. A manager works for the people he supervises, not the reverse. His responsibility is to enable them to reach their peak potential as software engineers, while achieving the objectives of the customers, the project, the organization, and the company. If the team leader spends a lot of time working on committees and activities at the behest of senior management, little energy remains to address the day-to-day needs of the people in his group. Such neglect can lead to festering problems that never get solved, stagnation of the software processes used in the group, low morale, and high staff turnover.

The effective leader has a vision of how software engineering should be performed in his domain, and he has outlined a path to evolve from the current state to the realization of that vision. Since every work environment is different, the leader must assess how best to implement the steps leading to process improvement in his organization. Skill is required to pull all team members into the evolution process and to keep the right amount of gentle but steady pressure on everyone to grow and improve. All activities must strike a balance between doing and improving, since the project work has to get done. A good leader will strive for perfection, but will settle for excellence.

Building a quality-oriented software engineering culture is hard work. During construction, the culture is easily undermined by actions that are inconsistent with the words. Unless the manager exhibits consistent, congruent behavior, he will have zero credibility with the development staff. A group oriented toward good software engineering may regress back to the individual performance level unless the immediate supervisor reinforces the quality culture in everything he says and does.

In his autobiography, Air Force General Chuck Yeager related his experiences when he became the commander of a squadron of jet fighter pilots a few years after he broke the sound barrier as a test pilot [Yeager, 1985]. His comments on leadership can be applied to software engineering management and culture as well as to military command:

  • To win their confidence, I had to perform up to expectations. Once they saw I was really good, they would follow my leadership—not just obey orders—because I had proved that I knew what I was talking about. . . . I had high performance standards and because the men respected me, they stretched to reach them. . . .
  • All of us enjoyed being in a good squadron that was becoming even better.

It is not enough for a manager to be involved with efforts to improve the software engineering practices in his group: He must be committed to the changes. To understand the difference, consider a manned space flight. The people in Mission Control are involved in the flight, but the astronauts are committed. Managers and development staff share accountability for improving the effectiveness of the team. You will know you have been successful in your efforts to drive a cultural change if you see sustainable changes in the way work is done in your group. When you reach this stage, the team members have internalized the new behaviors. They are applied as a matter of course on future projects without the need for continual management reminders.

Table 1.3 lists fourteen software engineering principles that formed the foundation for constructive cultural changes in several software groups at Kodak. The rest of this book describes how each of these principles led us to select specific development practices to improve our software processes, work products, and team interactions. If you agree with our philosophy, make similar practices a part of your team’s software engineering culture. If you do not agree with all of the cultural ideas presented here, decide what you do believe, and help your group evolve from a bunch of programmers to a team of software engineers. Create a clear and attainable vision, set a promising direction, and establish high standards, and most people will follow. This is one difference between being a manager and being a leader.

Table 1.3. Software Engineering Cultural Principles.

  1. Never let your boss or your customer talk you into doing a bad job.
  2. People need to feel the work they do is appreciated.
  3. Ongoing education is every team member's responsibility.
  4. Customer involvement is the most critical factor in software quality.
  5. Your greatest challenge is sharing the vision of the final product with the customer.
  6. Continual improvement of your software development process is both possible and essential.
  7. Written software development procedures can help build a shared culture of best practices.
  8. Quality is the top priority; long-term productivity is a natural consequence of high quality.
  9. Strive to have a peer, rather than a customer, find a defect.
  10. A key to software quality is to iterate many times on all development steps except coding: Do this once.
  11. Managing bug reports and change requests is essential to controlling quality and maintenance.
  12. If you measure what you do, you can learn to do it better.
  13. Do what makes sense; don't resort to dogma.
  14. You can't change everything at once. Identify those changes that will yield the greatest benefits, and begin to implement them next Monday.
  • + Share This
  • 🔖 Save To Your Account