Practice5.Coaching and Team Development

Practice 5. Coaching and Team Development

Coaching and team development are important for continual refinement to help the team achieve the best possible results while collaborating together and with customers. Coaching is an interpersonal skill that helps people provide each other with real-time feedback so they can do their work more effectively. Real-time feedback is important for continual refinement because it ensures problems are dealt with as quickly as possible. Team development (understanding the business and professional development) are equally important because the more the team understands the business and has current skills, the better it will be at both anticipating and initiating changes in its ecosystem.

Coaching

Coaching is an important interpersonal skill for every member of the team. Coaching is essentially providing individuals (people who work for you, people you report to, and people you work with), teams, and customers the real-time feedback they need to become more effective and continually improve. Coaching helps minimize friction and negative tensions while helping people work better together and focus on the desired result.

Understanding the Business

Understanding your company's business is an important element of sustainable development. The knowledge gained through this understanding is vital in anticipating and understanding changes to the ecosystem your project is dependent on. While some would argue that software developers should focus on writing code, I believe that this too often results in undesirable side effects, such as:

• Team members who don't understand what is valuable to their customers and why, even when told. This is often because they do not understand how the customers use the product and hence what is important to them.

• People who cannot listen to customers and understand what they are really asking for. Understanding what the customer is trying to do is critical because users most often ask for alterations to their current workflow only, when perhaps the problem is the workflow itself.

• People who don't understand what provides value to customers. Sometimes, work that provides value to customers is mundane, but it must be done.

• People who don't understand the economics of their business. How does your company make its money? Sometimes, customers ask for major features. If you always listen to your customers, then they will get everything for free. Your company needs to stay in business, though, and it may be more desirable to sell the customer a new product or add on to an existing product.

• In companies with multiple products, especially where there is overlapping functionality, it is common for people on each team to want to add all features their customers ask for to their product when in fact only one of the products may need it. Also, where multiple products serve the needs of a single customer or market segment, there may be detrimental competition between the product teams; these teams need a major wake-up call to realize that the competition they need to be concerned with is outside their company!

• People who don't understand the economics of their markets. Too many technically brilliant products are conceived to address what may be a sexy or obvious opportunity, which unfortunately is not viable economically due to a small target market or unrealistic pricing. Other problems may be misunderstanding the technical sophistication of users and building a solution that is too complex or too simple for them. Or, developers may not understand the economic reality of their customers where, for example, end-users may not value a software product at a realistic level because they (the end-user) are faced with massive costs in other areas that dwarf any potential for software.

• Teams that don't pay attention to their development processes. I have seen too many projects, where due to a whole range of factors such as poor planning and design, sloppy programming practices, a lack of risk analysis, defect backlogs, etc., a project team is required that is too large for the size of the target market. These are projects that are quickly cancelled, because the investment does not justify the returns: i.e., why should a company invest in a project with lower returns than if it was to take the money and put it in a bank account to collect interest?

• If the only value you provide to an organization is writing code, then your job can be outsourced (i.e., worked on by cheaper labor).

You need to understand your company's markets, users, competition, and financials. You won't always have access to all this information down to the finest level of detail, but you should have enough access to ask intelligent questions or be able to ask questions to get some information. Don't look upon it as "management's" responsibility to give you this information; effective communication goes both ways. People in management are almost always too immersed in the details of the business to realize what type of information you need.

My largest observation of people who work in most companies today is that they are too isolated from customers. Try to visit your customers or at least ask people who do visit customers to write up reports or give a short talk about what they learned. Bring your customers to visit you as often as you can.

Direct Customer Contact Helps Create a Balanced View

Recently, one of my co-workers went to a trade show and attended a user forum for the product he works on. He went in thinking he had better bring a bulletproof jacket because all he had seen were defect reports and postings on user forums. He came back completely rejuvenated and very positive. Sure, there were some unhappy customers but even they said, "Hey, I know I complain about your product, but it rocks. I couldn't do without it!".

Project teams often get a distorted view of their work if they don't have enough direct customer contact. This is because it is human nature to want to report problems and to say nothing when things are going well, and customers are human. Since most problem reports are done through impersonal e-mail or web forms, it is also human nature for many people to be less diplomatic than they should beproblems are frustrating after all. If all a product team sees are the defects that customers report and negative e-mails, then the team is likely lacking a balanced view of what customers really think.

One of the things I have little tolerance for is a software team that insists it needs to completely rewrite the product. Too many developers don't understand the company's need to stay in business. The problem, of course, is that it's always easier to write code than to read it, especially when you didn't write it. And it's no fun just fixing bugs in someone else's code. But few companies in the software industry can afford to start again from scratch. That's why teams should be encouraged to rewrite parts of their products as required and aggressively and constantly refactor as recommended in Chapter 6. The alternative is not pretty: While a product is being rewritten, your competition is developing new features while you are effectively standing still. Even if you build in new features, you are still going to be behind simply because of the lost market share. People who get this are highly treasured by organizations (or at least should be!).

Professional Development

Professional development is important for both personal and project reasons [Hunt and Thomas 2000] [Hohmann 1996]. From a project standpoint, teams that are knowledgeable in as many areas as possible, even those that are seemingly unrelated to the current project, have the best chance of succeeding at sustainable development. The reason for this is simple: These teams have a varied set of skills and knowledge, a rich tool chest if you will, that can be drawn from and applied with maximal effect. Professional development is vital to ensure that the team has all the skills it needs to understand its ecosystem of markets, competition, and underlying technologies.

At a personal level, your skills are vital to your team's success and to yours. It is your responsibility to ensure you are continually improving in your profession. You can't rely on anyone else to tell you to take courses or read or learn. You have to be proactive. You can't blame anyone else if your career does not progress as you would like. Read, take training courses, experiment with new programming languages and approaches to problems, and above all learn, collaborate, mentor, and teach.