“Over the years, the biggest lesson we have learned from our workshops is that becoming a leader is not something that happens to you, but something that you do.”
“Leadership is like sex. Many people have trouble discussing the subject, but it never fails to arouse intense interest and feelings.”
The essays in the book:
What is leadership anyway?
Models of leadership style
A problem-solving style
How leaders develop
But I can’t because.
The three great obstacles to innovation
A tool for developing self-awareness
Developing idea power
The first great obstacle to motivating others
The second great obstacle to motivating others
The problem of helping others
Learning to be a motivator
Where power comes from
Power imperfection and congruence
Gaining organizational power
Effective organizational problem-solving teams
Obstacles to effective organizing
Learning to be an organizer
How you will be graded as a leader
Passing your own leadership tests
A personal plan for change
Finding time to change
Finding support for change
I lead an IT Business Unit for almost 8 years (in a SAP R/3 environment). Some of what Weinberg talks about resonated with me. Weinberg’s approach is as much about therapy and self-help as leadership. The best part of it is when Weinberg explores the reasons why he’s even writing the book at all. “Introspection” is the keyword here and I agree with it. If one wants to be a leader, one has to be visualize it. It seems bullshit, but it really works. I can vouch for it... It’s not a snake oil pitch…
I’ll try some introspection as well and try enumerating why I like writing book reviews/essays:
- Try something new -> App development for Android and Python
- Keep on trying something new -> the blog serves this purpose (not being afraid to go outside my comfort zone, and try to incorporate something new in mind mindset, otherwise I risk getting overtaken by those who do)
- Writing about stuff -> my blog serves this purpose
- Learn about blogging -> my blog serves this purpose
- Have a personal journal –> 750.com (Weinberg suggests that I should keep a journal, say five minutes per day, and use this to trace output as the starting point for debugging my life and work…I’ve done this on and off through the years. Maybe it’s time to do it more consistently.
- Promote awareness by putting forth ideas -> my blog serves this purpose
- Pipeline of things to do/done -> my blog serves this purpose
As you can see, the book is as much about patterns of influence and self-improvement as it’s about technical management.
This people is excellent for people stuck in disempowering environments, and in the dysfunctional management behavior that creates them. To work in a successful ecosystem, there needs to be a culture of empowerment, support from the executive staff, and a set of definitions as to what we’re supposed to do.
On the other hand, having now been in the IT industry for some time I've seen many different things under the sun. I've a very particular idea on what it takes for someone to be a Technical Leader. The technical leader is rarely a person who has up-to-date skills. Many times someone moves his or her way up the chain to technical leader, perhaps having been an IT architect in "another life".
Unfortunately in IT, technology moves really fast and things change damn quickly. If someone was a developer say 5 years ago and now primarily does technical leadership, well, things have changed greatly since this person did software development. But since the technical lead hasn’t done coding software or architecture for a while his or her skills are really frozen in time to when they last did either of the roles I mentioned.
As an exception to this rule there are some technical leaders who actually keep up-to-date with skills, i.e., on the side they keep on practicing and learning new stuff. For my part, I always try to be on top of stuff technology-speaking, be it development, or other stuff. If one is not up to speed in terms of current technology trends what ends up happening is that the technical leader makes decisions for the practice that are based on old ideas. This greatly hurts the Praxis...
I've always thought the Technical Leader must have a lot of coding skills up his or her sleeve. In this case, God is not in the details, but in the code... At the end of each year every coder, engineer, or whatever you call yourself worth his or her salt should ask whether he or she's making adjustments to the structure of the solutions being developed and also constantly learning new coding techniques.
The best developers and Systems Engineers are people constantly learning and incorporating those changes into new solutions and this should also be the case with technical leaders.
There are some extremely adjustable and great people to work with, but the majority are just "sticks-in-the-mud". Avoid them at all costs...