Friday, December 24, 2004
The Mirror of Self Discovery
I just finished an absolutely brilliant book called "First, Break all the Rules" by Marcus Buckingham & Curt Coffman. OK, so the book isn't new, but it was something I picked up recently in my quest to learn more about leadership and management--two things I've been actively interested in since I read "Rogue Warrior" by Richard Marcinko many years ago.
I'm sure those of you who know who Richard Marcinko is would find it a bit strange to put a reference to these two books in the same paragraph. The reality is, that to me, they're related because Mr. Marcinko is the author who really struck a chord with me about leadership as I was reading it when I was first trying to extend my capabilities in that area. A number of things illustrated by the book really spoke to me about how things could be done to achieve a strong team environment and loyalty from those who report to you. Anyway, that's where it started for me back in 2000.
So, today, I finally finished the book I remembered hearing about in the news and seeing on the bookshelf around that time. In retrospect, I don't think I was ready for the book 4 years ago. I would have gotten a lot out of it, but I think that it actually speaks to you more if you have been in a leadership or managerial role for a while. If you haven't and you read the book, you won't really appreciate it when it expounds that there are differences between skills, knowledge and talent and that "everyone has talent" in one way or another.
What I find extremely fascinating about this book (in addition to it's reference value for future personal assessment) is that it actually shows you what you can do to increase your productivity as an employee as well as a manager. If you step back (which the book suggests a couple of times) and look at yourself using the same criteria your manager should be applying to you, it will give you great insight into yourself and your own personal talents. Once you know these, your chances for personal satisfaction and therefore success in your career will be greatly improved. In another, more tangential way, it provides advice that you can apply to all aspects of your interactions with other people.
Take the supposition from the book that great managers should define the right outcomes and then let each person figure out how best they may be achieved. If you think about this, it makes perfect sense.
Still, it is very easy to be overbearing and try to tell someone exactly how to do something--especially if you think you're right or you've done something similar in the past. This was a particularly hard lesson for me to learn, but one which I had to deal with in nearly my very first team at Informix. However, think about the statement more broadly in terms of your personal interactions. If you've read anything about negotiation skills, you'll probably instantly see that there's a connection here as well:
When you want someone to do something for you, articulate what you want to happen and then accept that they will be able to achieve it.
In negotiation (what we do with people every day if you think about it), you generally establish what you want to happen, and then negotiate about how you get there. The "what you want to happen" is the big-ticket outcome of the interaction. Maybe this is you want to buy a car for 10K less than the asking price, or maybe you are in labor negotiations and you want to get the factory operating again as soon as possible with the smallest negative future impact to the business. Once you have defined your "right outcome", then you can discuss or negotiate the best way that it can be done. In a lot of cases, it is similar to the managerial context: you don't necessarily care the how, you just want something to happen. Of course, it goes without saying that the how must be ethical and not violate any laws. I'm not trying to say the ends justify the means. Sometimes, like the labor dispute, the how does matter.
Even in a more relevant setting (to the blog, at least) like software development, the architect should define the outcomes (the what should be built) and give the individual developers enough freedom in the how this is met so that they can successfully answer some of the key 12 questions in the book. In this specific case, the following ones are most important:
These three questions--in particular the first two, define the foundations on which tangible business performance can be based. The happier your developers are, the more pride they will take in the work they do and therefore the better it will be. As mentioned in a number of sources, the cheapest place to find problems in the software is during development. If you have appropriately talented and motivated employees, the defects are less likely to be introduced in the first place.
If the organization, the manager, or the architect attempts to put too many controls on how the person does their job, they begin to wonder why they are even here. People want to be valued as individual contributers to a greater whole. If they have defined outcomes and an understanding how that fits into the bigger picture, you will generally have productive developers. This does not mean things like coding standards are a bad thing. Basic foundations must be laid for order and safety. You can't just drive on whichever side of the road you like, for example, but it doesn't mean you must drive a VW Beetle or a Ferrari. It just means that everyone's following the same fundamental rules. What you do within those rules is up to you.
I realize I'm drifting off track a little here, but the point I'm trying to make is that anyone who absorbs what is said in "First, Break all the Rules" instead of just reading the words will come away with wisdom which can be applied in all directions: up, side to side and down. If you're responsible for people, it will help you be a better manager, but if you aren't, you'll still learn how you can be a better employee and find a place where your talents can excel and you can be happy. If you don't get these things from the book, come back to it in a couple of years. It will still be as relevant and valid when you do.
¶ 11:46 AM
I'm sure those of you who know who Richard Marcinko is would find it a bit strange to put a reference to these two books in the same paragraph. The reality is, that to me, they're related because Mr. Marcinko is the author who really struck a chord with me about leadership as I was reading it when I was first trying to extend my capabilities in that area. A number of things illustrated by the book really spoke to me about how things could be done to achieve a strong team environment and loyalty from those who report to you. Anyway, that's where it started for me back in 2000.
So, today, I finally finished the book I remembered hearing about in the news and seeing on the bookshelf around that time. In retrospect, I don't think I was ready for the book 4 years ago. I would have gotten a lot out of it, but I think that it actually speaks to you more if you have been in a leadership or managerial role for a while. If you haven't and you read the book, you won't really appreciate it when it expounds that there are differences between skills, knowledge and talent and that "everyone has talent" in one way or another.
What I find extremely fascinating about this book (in addition to it's reference value for future personal assessment) is that it actually shows you what you can do to increase your productivity as an employee as well as a manager. If you step back (which the book suggests a couple of times) and look at yourself using the same criteria your manager should be applying to you, it will give you great insight into yourself and your own personal talents. Once you know these, your chances for personal satisfaction and therefore success in your career will be greatly improved. In another, more tangential way, it provides advice that you can apply to all aspects of your interactions with other people.
Take the supposition from the book that great managers should define the right outcomes and then let each person figure out how best they may be achieved. If you think about this, it makes perfect sense.
Still, it is very easy to be overbearing and try to tell someone exactly how to do something--especially if you think you're right or you've done something similar in the past. This was a particularly hard lesson for me to learn, but one which I had to deal with in nearly my very first team at Informix. However, think about the statement more broadly in terms of your personal interactions. If you've read anything about negotiation skills, you'll probably instantly see that there's a connection here as well:
When you want someone to do something for you, articulate what you want to happen and then accept that they will be able to achieve it.
In negotiation (what we do with people every day if you think about it), you generally establish what you want to happen, and then negotiate about how you get there. The "what you want to happen" is the big-ticket outcome of the interaction. Maybe this is you want to buy a car for 10K less than the asking price, or maybe you are in labor negotiations and you want to get the factory operating again as soon as possible with the smallest negative future impact to the business. Once you have defined your "right outcome", then you can discuss or negotiate the best way that it can be done. In a lot of cases, it is similar to the managerial context: you don't necessarily care the how, you just want something to happen. Of course, it goes without saying that the how must be ethical and not violate any laws. I'm not trying to say the ends justify the means. Sometimes, like the labor dispute, the how does matter.
Even in a more relevant setting (to the blog, at least) like software development, the architect should define the outcomes (the what should be built) and give the individual developers enough freedom in the how this is met so that they can successfully answer some of the key 12 questions in the book. In this specific case, the following ones are most important:
- Do I know what is expected of me at work?
- Do I have the materials and equipment I need to do my work correctly?
- Do I have the opportunity to do what I do best every day?
These three questions--in particular the first two, define the foundations on which tangible business performance can be based. The happier your developers are, the more pride they will take in the work they do and therefore the better it will be. As mentioned in a number of sources, the cheapest place to find problems in the software is during development. If you have appropriately talented and motivated employees, the defects are less likely to be introduced in the first place.
If the organization, the manager, or the architect attempts to put too many controls on how the person does their job, they begin to wonder why they are even here. People want to be valued as individual contributers to a greater whole. If they have defined outcomes and an understanding how that fits into the bigger picture, you will generally have productive developers. This does not mean things like coding standards are a bad thing. Basic foundations must be laid for order and safety. You can't just drive on whichever side of the road you like, for example, but it doesn't mean you must drive a VW Beetle or a Ferrari. It just means that everyone's following the same fundamental rules. What you do within those rules is up to you.
I realize I'm drifting off track a little here, but the point I'm trying to make is that anyone who absorbs what is said in "First, Break all the Rules" instead of just reading the words will come away with wisdom which can be applied in all directions: up, side to side and down. If you're responsible for people, it will help you be a better manager, but if you aren't, you'll still learn how you can be a better employee and find a place where your talents can excel and you can be happy. If you don't get these things from the book, come back to it in a couple of years. It will still be as relevant and valid when you do.
¶ 11:46 AM
