Better Software - May 2008 - (Page 47)

The Last Word When to Step Up, When to Step Back by Pollyanna Pixton From day one as a developer, I was asked by leaders to do things that I knew were a waste of time—keeping me from getting the “real” work done. When I became a project manager, those leaders continued wasting my time with questions such as: Where are we? When will we finish? How many errors are there? How much will it cost? But when I became the dreaded leader, it all became clear. When developing products, leaders need to know things to meet customer needs in the optimal market window so the company can continue to exist and hopefully prosper. Leaders can stifle progress when they interfere with team processes. But as a leader, you don’t want an on-track project to go over the cliff and deliver the wrong results. There are times when leaders should stand back and let the team work—and times when leaders should step up and lead. How do we decide which is which? Let’s start with stepping back. You hired your staff members for their abilities to address issues, solve problems, and create innovative and competitive products. Put your people to work improving operations, increasing workflow, and removing bottlenecks. They operate closest to the problems and have the best chance of finding workable solutions. You hired these people to deliver new, exciting, and competitive products to the marketplace before your competition can. As their leader, you must unleash this talent and allow the team to succeed. Create an environment based on trust, bring together people who have the right knowledge, ensure they understand the objectives, purpose, and constraints of the project—and then step back. As a contributing team member, I want to take pride in my work. I want to use my knowledge and experience to develop and deliver my part of the product. I want to create the best and most efficient solution, and I want to collaborate with my teammates to make sure we all deliver by assisting each other when we need help. I am not happy when someone begins to tell me how I should do my job or when I don’t get the opportunity to find and correct my own mistakes. That’s how I learn and gain more experience and knowledge. So, I need leaders to stand back and let me get the work done. What about accountability? I want to be held accountable by the people who understand what I am doing and how I think and who share in the challenges of the team. In other words, I want my teammates to hold me accountable—and they do. But there are times when leaders need to step up and lead. As leaders, we want our projects to deliver results, but not just any results, the right results—results that are inline with the corporate strategy. You could just lecture team members on this and hope as judgment that they cannot overcome). Do not ask them where they are stuck (they might not be; they might only need a new view). Ask team members to tell you about the project, their approach, their ideas, and their solutions so far. Help them take a new and fresh look. Often, this is not easy. When leaders hear a problem and know the answer, they will want to give the answer. Once you do this, you are cooked. Your effectiveness as a leader diminishes. Suddenly, a steady stream of people will be in your office asking you to fix their project and give them the solutions to all their problems. You have taken away the team’s ownership and, in effect, told team members they are incapable of solving their own problems. They will lose pride in their work and their productivity will drop off dramatically. Allow your teams to manage their workload, find solutions, and deliver. Make sure all team members understand that their solutions, objectives, and goals must be in line with the company strategy. Help your teams find their own solutions—but only after they have tried on their own. Don’t be too quick to give them solutions. Ask questions without giving answers. Your questions will help your team members discover their solutions. Use your questions to unleash the talent and creativity in your organization. Then stand back, get out of the way, and let them get the “real” work done. {end} Another key to success: Don’t rescue your teams—but don’t let them flounder for too long, either. they get it. More effective than lecturing, though, is continuously asking questions to help them discover the answers. Questions like: How does this feature/objective fit with our company strategy? If it does not, do we need to modify our strategy? Does our prioritization scheme match our business priorities? Can we reach our market window? Another key to success: Don’t rescue your teams—but don’t let them flounder for too long, either. It can be difficult to know when the team needs more time to struggle toward a solution or needs you to add some leadership (not step in!). How do you know when to step up? Through your own experience and intuition. If you ask inquiring questions rather than tell the team what to do, you will maintain the integrity of its own problemsolving process. So, when you get a sense that team members are thrashing, bring them together. Do not ask what’s wrong (this may pass www.StickyMinds.com MAY 2008 BETTER SOFTWARE 47 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - May 2008

Better Software - May 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: It's A Bug! The Chivalrous Team Member Let's Talk Agile Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.