When programmers become software project managers
The day you expected, and perhaps feared, finally came: you were promoted from the ranks of engineers to the position of software project leader or team leader. This may be the career path you have chosen, or you may be reluctant to give it a try. In either case, you may lack education in engineering disciplines, people management, and leadership.
This requires more leadership and management (they're not the same thing), rather than simply fighting the boss like Dilbert. As you consider new goals, consider the list of activity plans below. It's impossible to catch every highlight at once. But this advice note can help you focus on activities that can improve your and your team's performance.
establish priorities
As a manager, the first and foremost thing you need to do is to consciously establish priorities. While you're still stuck in the heavy lifting of software development, you need a new set of responsibilities. Too many novice managers can't resist the lure of technology and get caught up in this type of activity, which results in the rest of the project team not getting help from the manager when they want it.
Effective leaders know that their first priority is to serve other team members. These services include training and mentoring, resolving problems and conflicts, providing resources, establishing project goals and priorities, and providing appropriate technical guidance. Make it clear to each team member that you can always help them. I find it very rewarding to position myself as working for the people I supervise, not the other way around. Among the things you do, you should have the priority of non-maskable interrupts for team members to ask you to help them.
The second most important thing is to keep your customers happy. As a manager, there is no direct ability to satisfy customers because you no longer do it as an individual providing products and services. Instead, you must create an environment that allows your team members to best meet customer needs. Managers provide powerful methods to effectively improve customer satisfaction.
The third most important thing is to work on your project. Because maybe there are many other technical projects, or requests from other managers, such as working on a steering committee. When these conflict with the two high-level ones, be prepared to quit.
Obviously, keeping other managers happy is the least of your priorities. In a well-organized organization, other managers will be thrilled if you are successful in more than three major segments. We're not all lucky enough to work in a good environment, but be sure to do your best to work on the tasks that are at the top of your to-do list. Focus on helping your team members effectively, happily, and as much as you can, and don't focus on making your boss happy.
Analyze your skills gap
Unless you are ready for your new position, you will feel some gaps relative to your current leadership and management skills. A strong technical background may have been a factor in your selection for a leadership role, but to do well, you need more skills. Be realistic about your strengths and weaknesses in other people's comments and projects, and then close the gaps.
Software people aren't known for their satisfying interpersonal skills. You will want to enhance your experience dealing with relationships: conflict resolution, persuasion, and indoctrination. You also have to deal with things like hiring, firing, negotiating schedules, and critiquing someone's performance in your office to make you cry.
I found it very good to start my management career with a listening skills class. We often feel very comfortable with our own technical agenda as individual proposers actively submitting our own technical agenda to the group. Effective management requires more cooperation and a receptive interpersonal approach. Take the time to learn how (and when) to subtly channel your natural judgment. Listening skills classes provide a communication mechanism that I have found useful in many situations.
Then, go to the other side of the podium and improve your speaking skills. If you're really uncomfortable speaking in public, taking Dale Carnegie's class can help. You will find that the experience gained through such training, as well as the improved communication skills you gain, can help you better adapt to your future work.
As the project lead, it is your responsibility to adjust the work of others in order to plan and track the project, and to take corrective action when a project rollback is required. Take a training course in project management and read some books and articles on project and risk management. Participate in the Project Management Society and read its monthly magazine - PM Network. SEI's Software Capability Maturity Model provides many useful recommendations for software project planning and project tracking. The ability to establish priorities, control effective meetings, and communicate clearly will have a substantial impact on your performance as a manager.
Defining "Quality"
Almost everyone takes quality seriously and wants to produce high-quality products. However, there is no uniform definition of what quality means in software. There is a heated debate between the traditional view of software quality and the view of "good enough" software. To help the group succeed, spend some time discussing the meaning of quality with your team members and customers.
The two camps often do not have the same definitions in thought, and can easily work on different purposes. A manager who is concerned with the delivery schedule will be impatient with an engineer who wants to check every line of code normally; a customer who thinks reliability is very important will not be satisfied with a product with features that are seldom used but with lots of bugs; a A good GUI may be annoying to users who have memorized how to use the previous version of the product effectively.
To better understand customer perceptions of software quality, at Kodak, my group once invited our customers and their managers to discuss this topic in an open forum. This forum is very meaningful, those who use our products have their own understanding, and through discussions, we can know which of our ideas for quality development is inconsistent with them. Knowing the difference allows you to focus on the best interests of the customer, not the developer's best interests.
Traditional descriptions of software quality include conforming to specifications, meeting customer requirements, and having code and documentation free of defects. The buzzword "six-sigma quality" establishes a very high scale for monitoring the frequency and density of failures. But it doesn't apply to quality metrics like fast product delivery, availability, adequate feature set, delivery meaning for a price paid. For the products we manufacture and buy, we are always keen to cover as many of these quality characteristics as possible, however, compromises are always necessary.
During the requirements phase of a project, we developed a list of ten quality attributes, such as efficiency, synergy, correctness, and ease of learning, which we felt were the most important to users. We asked a representative group of client key figures to evaluate each attribute on a scale of 1 to 5. Once we decide which properties are the most important, we can design and achieve those goals. You are in luck if you have no trouble understanding what quality means to your customer and designing to achieve the quality attribute, and the customer is satisfied with the quality attribute.
Among the many quality statements of concern, I have heard one: "The customer is back, but the product is not". Work with your customers and developers to define appropriate quality goals for each product. Once decided, give a clear top priority for achieving quality goals. Lead by example and hold your own work to high quality standards. Adopt this motto: "Strive for perfection and be content with excellence."
Commend achievement
Recognizing and rewarding your team members' achievements is a very important means of motivating them. Unless you already have a recognition process in your group, this should be one of your most important things. Recognition includes both token items (certificates, travel awards) as well as practical items (movie tickets, restaurant gift certificates, redemption awards). When giving a giveaway, say something kind: "Thank you for your help" or "Congratulations on the achievement." Spend very little thought and money on recognition and rewards, and you can get a lot of friendship and future cooperation. People outside the development group, including customer representatives and support staff who have contributed to the success of the project, can also be recognized.
Discuss with your group members about ways to recognize and reward them that interest them. Make recognition of achievements, large and small, a standard part of group culture. Give implicit praise to each team member for showing a heartfelt interest in the work they do, and do your part to remove all obstacles to their combat effectiveness. Recognition is a way to show team members and others outside the group - you need to know and thank them for their contributions to the success of the group.
learn from the past
It is possible that some of the projects your group has undertaken in the past have not been completely successful. Even on successful projects, we can often think that something we can do better next time. As you move into a new leadership role, take the time to understand why early projects failed and plan to avoid making the same mistakes. With software development, it is very difficult for every manager to spend time dealing with every possible error that may occur, and learning from past successes and failures is a successful start.
Start with a project your team has undertaken in the past that has not been reviewed and evaluated, regardless of its success or failure, and conduct a post-project retrospective (sometimes called a post-mortem analysis). Your goal is not to determine responsibility, but to do better in future projects. In this way, you can understand what has been done well and what should be done better. At the current major milestones of each project, through brainstorming or fair organizers, in the same way, the leadership team brainstorms it.
Also, learn the best guidelines for understanding the existing software industry. A good place to start is Part III of Steve McConnell's Jolt Award-winning work: Rapid Development (Rapid Development, Microsoft Press, 1996), which describes 27 best practices. Also avoid the 36 common software development mistakes that McConnell describes. Your team members may oppose the new way of working, but your role as a leader is to ensure that the team consistently uses the best available methods, processes and tools. Actively promote information sharing among team members so that local single best practices become part of each developer's toolbox.
Establish improvement goals
Once you've established a review of past projects and established what quality means to the group, you need to establish goals for short-term and long-term improvement. The goal is to be as quantifiable as possible, so you'll want to break it down into simple phases that indicate whether you've taken the proper process to move toward the goal.
For example, if you decide that the project is frequently delayed due to unstable demand, you can establish a goal of improving demand stability by 50% within 6 months. Such a goal requires you to know exactly how many changes to your weekly or monthly requirements, know where they come from, and take action to control those changes. This may require you to change the way you communicate with those who submit requirements changes.
Your goals and phases are part of a software process improvement program that you want to keep in order. As the last refuge of an uncreative bureaucracy, it is in vogue to despise "process." Despite the fact that every group can find ways to improve its work. Of course, if you're always working the way you already work, don't expect that you'll get better results than before.
There are two strong reasons for improving the process: correcting problems and preventing problems. Make sure your improvement efforts revolve around known or predictable issues that may threaten the success of the project. Lead your group to identify the strengths and weaknesses of the methods currently being used, as well as the risks to the project.
My group convened a "two-stage brainstorming" exercise to identify stumbling blocks in the process of improving software productivity and quality. During the first meeting, participants write their thoughts on the topic of the meeting on a note, one thought at a time. Organizers collect and group their ideas written on a note. In the end, we'll have a dozen major categories and record them on a flipchart.
For the second meeting, the same participants wrote out ideas for addressing these obstacles on sticky notes and posted them in the appropriate location on the flipchart. Further refinement, and a few detailed activities, can be part of our efforts to remove obstacles and help team members achieve software quality and productivity goals.
Establish measurable and attainable goals so you can focus on making improvements. Make goals clearly prioritized and monitor the process periodically. Remember that your purpose is to improve the technical and business success of your projects and companies, don't settle for the details of expectations mentioned in some process improvement books. Think of improvement efforts as mini-projects with distributable, resourced, planned, and accountable little projects. Otherwise, process improvement activities will always be a lower priority than enticing technical work.
slow start
This article offers many suggestions to help you, a new software manager, lead your group to great success. Strive to keep your head clear in the face of the new day-to-day stress of work. You have also played a very important role in shaping the culture and habits of software development groups for a long time. You don't have to do it all at once, you can start by choosing the ones that are most relevant to the environment.
As a software manager, you have more responsibilities than just getting projects done on time and on budget. You'll also: lead technical people into a cohesive team; create an environment for collaborative team work; encourage and reward the hands-on application of senior software engineers; balance the needs of customers, the company, team members, and yourself.
It's a big mission, good luck.