The Byte Stops Here

Software development is a job. Doing any job well requires that you don't take shortcuts. There are things that work and things that don't. It's creative, often experimental and pioneering. It takes courage. And it takes everyone in the organization to make the process successful.

If you're in a leadership position, do yourself a favor and develop a culture of mutual respect that embraces individual collaboration and contribution. Mistakes are part of the growing process. Create a safe environment for your developers by encouraging iterative development, in small incremental chunks. Recognize that it will be rarely perfect the first time.

Find and hire the best, but then don't rob yourself by not carefully heeding their wisdom. These guys have the scars and they're worth every penny. They're worth even more if they can communicate their wisdom to others. This is how you grow and mature your team - by carefully planting these leaders in strategic positions which aligned to their strengths and interests. These are your Knights, Bishops, and Rooks and they are empowered to move in many ways. If they are happy, you will be happy. Guaranteed.

Avoid the heroes. The ones that crave the spotlight probably do not have your best interests in mind. Fixing problems that could probably have been avoided by taking the time to set the team up for success from the very beginning is a recipe for disaster and loss of credibility for everyone involved. The team wins or nobody wins.

Protect your teams. Educate your stakeholders or your CFO on the process of software development and explain that best practices, such as agile and iterative development, exist for a reason. Millions if not billions of dollars have been spent in the industry to learn these lessons, yet I continually see the same mistakes played out over and over in companies. Instead of answering the question "How much?", ask a question in return: "How much are you willing to invest initially?" Then use agile practices to iterate and demonstrate value by building the most important (prioritized) features first. Let the team showcase their work every sprint. Let them talk directly to your stakeholders and let them take accountability for their work. If at the end of that investment cycle there is no value, then you can recommend to your stakeholder that they should stop investing and as a result would probably save them money in the long run.

Focus on quality. I cannot stress this enough. Quality, not lines of code or number of features delivered, is gold. If your team has been rushing to deliver, before you pull the switch and go into production you *MUST* make sure that you are allowing an appropriate stabilization period for the features that have been developed to be thoroughly tested and quality reviewed, operational procedures and practices are solid, and transitional knowledge for support is well-established. Absolutely do not keep developing new features all the way to the production date if you are not applying solid development and testing practices or if there's any doubt of the quality of the code! This is an advanced level of maturity that very few organizations achieve and it takes time to get there. Be sure to automate testing at every level when possible, from the unit test on up. Be sure to define explicit done criteria at different levels, at the PBI and task level for instance. Each developer on the team should know what is expected of him/her when developing a unit of code. Encourage constant and open communication without fear of reprisal and you'll uncover the "dragons" before your stakeholders do.

Focus your attention outward and manage expectations of your stakeholders and allow the team to do what they need to do. Ask the team and they will tell you what they need. Sometimes this doesn't happen verbally. Learn to recognize the cues, the patterns of behavior. Multi-cultural, multi-national teams are complex systems in their own right. Leverage your strategic assets in order to continually mentor teams.

Grow your developers' knowledge. Provide opportunities for enhancing their skills by allowing for proper training for tasks involving technologies which they may be unfamiliar. Do not assume that just because someone is a contractor that they will somehow magically learn the proper means to work with a particular technology. By not allowing for this experimentation and training phase, you are guaranteeing that the software will be developed poorly. Encourage sharing of knowledge via lunch and learns or communities of practice.

Remember, cheaper is not always better. Faster is not always better. Always look for opportunities to improve and make small changes, not broad sweeping strokes that decimate entire teams. Teams take time to form after all and time is the most precious resource we have. I've seen teams transform from coal into diamonds. It requires patience.

Do not burn good will. If you do, you have to replenish it. Telling your teams to change their work-life balance in order to accommodate operational mistakes or unreasonable demands will burn the good will at both ends. If you've earned the respect of your teams, you won't have to tell them. All you need to do is ask and they will do whatever it takes to not let you down.

Good luck.