Sometimes it feels like non-technical managers just don't understand what we do for a living. The good ones try really hard and stand up for their team, but they just don't feel it in their bones. If technology is not stamped into your DNA, you just don't get it.
So that means that only technical people should manage technical people, right?
Here's the problem: technical people frequently do not make good managers. It isn't that they aren't smart enough; usually the best technicians are the people who are asked to step into leadership roles. But the skills that make a good techie are not necessarily the skills that make a good leader.
When you become a leader, the focus shifts. It is no longer about what you can accomplish as an individual contributor. You will be judged by your team's accomplishments.
Good technical people have developed good study habits, a sense of responsibility, and a solid work ethic. All of these are important, and can translate into skills that will help you be a good leader. But you will only be an effective leader when you inspire your team members to reach their potential.
Moving into a leadership role can be a bumpy ride. But it can also be hugely rewarding. Make sure to approach it from the right frame of mind. It isn't about you anymore. It is about your team.
This book lays out some of the lessons I have learned during my own transition from a front-line techie to a manager. The technical community has always been all about sharing what we learn. I look forward to hearing you share your own stories and lessons from your own journey.
The title of your book looks reasonably generic. That is to say that it implies that it's some sort of generic guide for any technical person to move into management. However, the table of context (listed on Amazon) lists chapters such as "Managing Software Teams" and "Integrating Third Party Software. This leads me to wonder if "Techie" in the title is really some sort of code word for "IT Person." That is to say that I question how generic the book is.
ReplyDeleteCan you address this?
I had someone else ask me a similar question, so I'm going to take advantage of your comment to answer him as well. He asked if my book would be useful to someone with more of an engineering background than a computer background.
DeleteThis book is more of a management book than an IT book. My background is in IT, and so is Dave's, so that is going to color our treatment of different subjects. I think it would still be useful to people in a non-computer technical field.
The problem I was trying to address in this book is that management books seem to mostly be written to MBAs. The personality types that are attracted to technical fields are different from those attracted to business leadership fields, and our educational background is usually different too.
Project management, root cause analysis, time management, people management, etc are all approached from the perspective of someone who has spent a long time in IT. But there isn't anything in those chapters that is applicable only to IT people.
You can use the "Look Inside" feature on Amazon to see if the treatment of one subject or another is helpful to you.
I'd love to hear peoples' comments about how to improve the book, and I expect to try out some of their ideas here on the blog first.
Thanks for the comment!
ReplyDeleteOne of the things that I have learned during the publication process is that the book's title is chosen by the publisher rather than the author. I submitted several titles to the publisher that I think might have answered your question a little better. Here are a few of them:
The New IT Manager's Survival Guide (The marketing people felt that this made our prospective customer seem a little bit desperate. When I suggested that this sounded about right, based on my own experiences, that was probably the death knell for this title.)
Managing Technology Teams (Viewed as too "broad" and really not very catchy.)
Moving into Management (I actually liked this one, especially combined with the "Survival Guide" concept as a subtitle, but it is way too generic on its own.)
To answer your question directly, I think the publisher views "Techie" as more palatable version of "Geek." I was very clear up front that I did not want "Geek" or "Nerd" in the title. I was very put off by the tone of the book "Leading Geeks" and wanted to distinguish my book from that one. (See my review of "Leading Geeks" at http://amzn.to/Z85vNU )
I tried to have the publisher re-consider the word "Boss," since I think the connotations of that word don't fit into the sort of management style that actually works with IT people. No dice. They liked how this title flowed.
The book is relevant to most people in IT. My own experience comes from systems/build/migration/operational roles, and we wanted to make sure to represent development groups as well. A friend with a lot more software development experience than I have, David Jacobs, co-authored the two chapters you mention that are more specific to the challenges faced by software development teams.
This blog has samples of my writing style and the sorts of subjects I like to address. (The blog for my other book, http://solaristroubleshooting.blogspot.com , has more writing samples.) You can also use the "Look Inside" feature on Amazon to read multi-page sections of the book to see if it is what you are looking for.
My style tends to be spare and direct in any case, and I edited this book relentlessly to try to make it shorter. I wanted to end up with a book that could be read comfortably in a weekend, and I felt that 250 pages would be a good length to say what needed to be said without rattling on too much.
This is not a book with a lot of good war stories; there are a couple of other books in the marketplace that fill that niche pretty well. (I recommend "Managing Humans" for that sort of book.)
I hope that helps.