presenter Bill Heitzig
11:00 AM 1/10/2013 Nile
Bill was a developer for a number of years and turned down the management path in the last few years. The point of his presentation was that you should create a written ‘Strategy’ for what you are trying to accomplish with your group. The strategy document should be a private document that you use to orient yourself and your actions. It should be shared only with trusted colleagues with the purpose of garner feedback to improve your approach.
Bill believes that having this written strategy document is key to successful leadership. He indicated that he believes leading means having a strategy and having it written down makes it clear it actually and concretely exists. Writing down your strategy also assists you in perfecting communicating your strategy to others verbally. It helps you practice defining your strategy to yourself so you can better communicate it to others.
A strategy is defined as a cohesive and rational vision for the future of your group. The goal of a strategy is not to win, it is to make your project, aka your software, and your team successful.
A strategy should assist you in making decisions. Decisions will be made, but a strategy helps you to actively chose to make decisions as opposed to letting them be made by circumstance.
A strategy should be objective, measurable and repeatable. Bill mentioned Key Performance Indicators as a concept that can be useful in defining the metrics to use in strategy review.
The concept of sphere of concern and sphere of influence was brought up. Bill recommended having your strategy focus on things in your sphere on influence, and to also try to increase your sphere of influence to give your strategy a higher chance of success.
The concept of technical debt was explored. Technical debt increases because of looming deadlines and poor compromises. This leads to downward spiral and your strategy should address shrinking your technical debt. However, technical debt should not be tackled too quickly, it should be reduced over time.
You should invest in your software and your team through training and tools. These investments will produce good roi and should be part of your strategy.
Your strategy should be separate from your implementation process. Your strategy is not agile, agile is part of your strategy.
Your strategy should not strive to provide immediate value, but should focus on delivering value over time. You should use your team on activities that are investment, not every activity can be for immediate gain or will increase to technical debt. Investment items include training, documenting, researching, setting up environments.
Your strategy should include an approach to handling your customers. You should strive to build trust with your customers. You should go to your customers don’t make them come to you. Do not over promise and share bad news with customers quickly. Your strategy should be to try and become your customers trusted adviser.
Find ways to measure capabilities in your team. Define how levels of competency in different areas can be measured and understand what level of competence your team has in different areas.
Build trust with your partners, aka QA and and Deployment. Protect partners from you by helping them be better at what they do. Inform your customers about your partners so they are aware of how you operate so can understand better how hard their requests are to complete.
Your strategy should state the problems you face clearly so you can more easily try and define solutions and approaches to mitigation.
Bill suggests that the higher up in an organization people are the less they read so effective written communication for upper management should be as short as possible.