• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Principles of Technology Leadership
 

Principles of Technology Leadership

on

  • 929 views

Ten often-overlooked principles of technology leadership

Ten often-overlooked principles of technology leadership

Statistics

Views

Total Views
929
Views on SlideShare
923
Embed Views
6

Actions

Likes
0
Downloads
19
Comments
0

3 Embeds 6

http://www.lmodules.com 4
http://www.slideshare.net 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Principles of Technology Leadership Principles of Technology Leadership Document Transcript

    • Often-Overlooked Principles of Effective Technology Leadership The following are some basic principles that I have found useful in leading technology teams, but which are often ignored. Most are things that technology leaders are not immediately rewarded for, but which are essential for long-term success and consistent delivery of real business value. I make no claim to be a management expert. The principles below have little to do with management science and everything to do with managing technologists. 1. Pick up a shovel The more you understand about the day-to-day challenges and activities of your team, the more you can be counted on to make the right decisions and to get the team to support your decisions. Of course, this requires that you invest in learning the technology that your team works with and that you get some practical experience working with it. Production support and release management are areas where leaders can often learn a lot about the systems that their teams work with. Documentation and test plan development are other areas where you can "roll up your sleeves" and bond with the technology and the team. 2. Grow the vision Technologists do not like to accept strategies or solutions that are forced on them "from above." A team vision that is grown from within is certainly more likely to be supported by the team and generally better informed than one based on pronouncements from you. If education and "rumination time" are required to grow the vision, you need to buy the time necessary to make this happen. In the long run, you will save time by getting the team to share the vision. In some situations, you will be forced to "align" your team with a strategy that is imposed by your business or technology environment (e.g. contractual obligations or enterprise technology standards). Even in this case, you need to grow the alignment vision within the team. If this is not possible, you need to challenge the strategy. 3. Grow the team, but not too fast Your long-term success largely depends on how well you succeed at human resource planning and development. Unfortunately, near-term pressures often force suboptimal resourcing decisions from the standpoint of human capital development. You need to take the short-term heat in order to build the team. You need to understand and accept two basic facts: 1) it can take years to develop strong technical resources and 2) business- critical projects are not suitable for on-the-job training. This means that you have to take the long view, adding team members in advance of demand, with the full knowledge that their contribution may be minimal for quite some time. You must resist the pressure to "ramp up quickly" with green resources on business critical projects. You must also resist -- at all costs -- the "add more bodies" approach to project acceleration. The real (durable) work always gets accomplished by small, focused, well-trained, well-equipped teams.
    • 4. Show real commitment to quality Technologists (correctly) assume that most management discussion of quality is lip service. When things get tight, budget and delivery dates always force compromises in quality. This is the common body of experience shared by technologists (especially web technologists) today. To get real quality from technology teams today, you have to start by digging your way out of this cultural hole. The only way to do this is to demonstrate that you will NOT use quality as a control variable -- i.e., you will take the heat when you encounter budget, scope or date crises and force one of these to give instead of quality. You need real concrete, visible examples showing your own intestinal fortitude. You must also establish and religiously adhere to rigorous standards and quality control processes for your team. It is essential that the standards and processes be of the highest quality themselves -- i.e., you do not waste anyone's time and the technical strength of the standards and the reviewers must be unimpeachable. Finally, you need fair but effective means to ensure personal accountability and consequence management. 5. Solve the real problem Technology is a wonderful thing. So wonderful, in fact, that it can distract attention from solving real problems. Software vendors are particularly adept at pushing "transformational solutions" that can "transform" a well-conceived technology project with a strong business case into a multi-million dollar waste of time. You need to constantly reorient yourself and your team vis-a-vis the real business context of your efforts. Technology can sometimes create new business value and/or new business opportunities. This is the exception, however, not the rule, in spite of what the vendors and consultants may say. Most successful technology projects succeed by solving simple problems with straightforward solutions. You need to keep your team focused on the real business problems that they are trying to solve. 6. Ask hard questions Your team -- and your technology partners -- should be prepared to answer probing and difficult questions from you. Beyond "how exactly will this work?" you need to constantly ask "how will this fail? how will we know when it is failing? what are the key risk points?" Any signs of flakiness, lack of confidence, or lack of technical consensus need to be probed and questioned aggressively by you. You obviously need to do this in a friendly, understanding and supportive way; but as I always say, "it's better to deal with the hard questions now, among ourselves, than later on a service restoration bridge." You need to establish a culture and understanding on the team that expects and welcomes hard questions.
    • 7. Listen to the real experts Unfortunately, most technology "experts" have no real, recent and relevant implementation and deployment experience. If you let the high level box-drawers drive your key technology decisions, you are guaranteed to waste lots of time and money, you are likely to alienate your team and there is no guarantee that the solutions that you develop will work. The key is to find a few real experts and use them to set your strategic direction and to identify the other real experts among your technology partners. There is a certain "bootstrapping" problem here -- until you have this core of real experts, you will not know how to identify who the real experts are. This is really a situation where "it takes one to know one." Once you have built the core, you need to extend this to a network that spans your technology partners. Finally, you need to listen to the real experts and base your decisions on their consensus. 8. Change your mind wisely Even with the best experts advising you, you will make lots of suboptimal decisions. If you constantly change direction, you will never make progress and you will lose the confidence of your team. On the other hand, if you hold maniacally to a course that is doomed to failure, you will also lose the team's confidence and you will waste a lot of time and money. You need to change your mind wisely, always focusing 100% on the lowest cost and lowest risk path to meeting your business objectives. Never worry too much about what people outside of your team will think about your decisions. Make the right decision first and then worry about explaining it to the rest of the world. 9. Limit the rah-rah Real technologists despise slick demos and other forms of self-congratulatory nonsense. You definitely need to celebrate the accomplishments of your team, but it is essential that you make it real. Never overstate or "hype" your team's accomplishments. Remember that they know exactly what they have done and your job is to show pride in their real accomplishments. If you present their work as more than it is, you are essentially telling them that what they have delivered is not good enough (or worse, that you have no concept of what they have done). The consumers of your technology solutions also know exactly what has been delivered to them. If your team achieves excellence, the facts will speak for themselves. If you are still on the path to excellence, celebrating/advertising small successes for what they are will help you along and establish credibility with your business partners. 10. Empower production support I have saved the most important principle for last. There are lots of statistics about how much more maintenance costs than development. This is obvious. The people who know the most about maintenance, performance, availability and required hardware resources are those involved in production support. Effectively empowering production support requires two things: first, you need to staff your production support team with your strongest resources and second, you have to let them have a strong influence on design and development. If you do the first, the second may happen by itself, since among real
    • technologists, the strongest emerge as de facto leaders. You need to accept the fact that some of your strongest leaders and technical resources are going to have to be pulled out of development. If you take the view that your strongest resources should be focused where the most money is at stake, then it is obvious that you need to do this.