Showing posts with label Management. Show all posts
Showing posts with label Management. Show all posts
1: Accountability
Perhaps the most important attribute a leader needs to be successful is accountability. Humans will do amazing things if they know what is expected of them. They will often do stupid things if they don't.
Consider the parable of the rock:
A village chieftain once asked a young warrior to bring him a rock. The young man, feeling excited, creative, and proud to have been asked, guessed that the chieftain wanted a new decoration for his hut. He went out and found a beautiful quartz crystal and brought it to the chieftain who shrugged and said, "Thank you. But that's not the rock I wanted. Please try again." Disappointed, but still resolute, the warrior then decided that the chieftain must be worried about the oncoming winter, so he returned with a piece of coal. "That's not it either,” said the chieftain. Getting frustrated, the warrior asked around the village and found that the chieftain had asked for rocks before and had once accepted a piece of granite. Thus, the young man traveled several days to a place where he could find granite. He chipped off a large piece and hauled it home to the chief, who didn't have time to see him, but sent a message through his lieutenant-chieftain that he had changed his mind and no longer wanted a rock.
You've probably been on both ends of that story. I know I have. The warrior, instead of spending productive time, spent time trying to divine what the chieftain wanted. What a waste of effort! Clear instructions save everybody time and improve the quality of work. Accountability is impossible without them. You can grow leaders by giving clear instructions and letting them flourish.
I once had a manager who subscribed to the “bring me a rock” school of thought. He was a smart, talented guy, but he had very stringent, inflexible notions of how things ought to be done. He would ask me to bring him a rock over and over and over again until, at last, the rock I brought was the one he wanted. Hey, I eventually brought him what he wanted, so we succeeded together, right? Wrong. Each day seemed like a continual struggle with this manager, and I often felt like I was spinning my wheels. I definitely wasn't as productive as I could have been. Obviously, this behavior turns people into drones whose purpose is to figure out the leader's will.
As a leader, you have a responsibility to help your people help you. If you have particular concepts of how things ought to be done, be clear on those up front. People need a sandbox, especially in large enterprises where standards, protocol, politics, and policy, by necessity, govern. But make those boundaries as spacious and as well-documented as possible.
Once you establish boundaries, you must set people free within them. People want to feel empowered. They want to be creative. They want to solve problems and have freedom. Turn them loose and stay out of the way! People are paid to use their brains, and the more they're micromanaged, the more they have a tendency to turn their brains off. Micromanagement can work well in very small groups with monumental challenges which require heroics. But micromanagement doesn't grow leaders. I know. I'm a recovering micromanager and I've seen the negative effects of meddling on potential leaders.
It may be easy to criticize someone's ideas. And it's human nature to think that your way is better. You might even be prescient enough to see a potential train wreck coming. But letting leaders own their decisions allows them to feel accountable and learn from their own mistakes. We can't (and we shouldn't) want to teach every person to do every job. We don't know enough and we don't have enough time. Let people learn on their own. Each time you swoop in to solve a problem that you see coming you remove a potential lesson from the people in you organization. Accept mistakes for what they are: cheap leadership training courses.
Clear expectations and defined, yet spacious boundaries with room for mistakes will create leaders in your organization.
Consider the parable of the rock:
A village chieftain once asked a young warrior to bring him a rock. The young man, feeling excited, creative, and proud to have been asked, guessed that the chieftain wanted a new decoration for his hut. He went out and found a beautiful quartz crystal and brought it to the chieftain who shrugged and said, "Thank you. But that's not the rock I wanted. Please try again." Disappointed, but still resolute, the warrior then decided that the chieftain must be worried about the oncoming winter, so he returned with a piece of coal. "That's not it either,” said the chieftain. Getting frustrated, the warrior asked around the village and found that the chieftain had asked for rocks before and had once accepted a piece of granite. Thus, the young man traveled several days to a place where he could find granite. He chipped off a large piece and hauled it home to the chief, who didn't have time to see him, but sent a message through his lieutenant-chieftain that he had changed his mind and no longer wanted a rock.
You've probably been on both ends of that story. I know I have. The warrior, instead of spending productive time, spent time trying to divine what the chieftain wanted. What a waste of effort! Clear instructions save everybody time and improve the quality of work. Accountability is impossible without them. You can grow leaders by giving clear instructions and letting them flourish.
I once had a manager who subscribed to the “bring me a rock” school of thought. He was a smart, talented guy, but he had very stringent, inflexible notions of how things ought to be done. He would ask me to bring him a rock over and over and over again until, at last, the rock I brought was the one he wanted. Hey, I eventually brought him what he wanted, so we succeeded together, right? Wrong. Each day seemed like a continual struggle with this manager, and I often felt like I was spinning my wheels. I definitely wasn't as productive as I could have been. Obviously, this behavior turns people into drones whose purpose is to figure out the leader's will.
As a leader, you have a responsibility to help your people help you. If you have particular concepts of how things ought to be done, be clear on those up front. People need a sandbox, especially in large enterprises where standards, protocol, politics, and policy, by necessity, govern. But make those boundaries as spacious and as well-documented as possible.
Once you establish boundaries, you must set people free within them. People want to feel empowered. They want to be creative. They want to solve problems and have freedom. Turn them loose and stay out of the way! People are paid to use their brains, and the more they're micromanaged, the more they have a tendency to turn their brains off. Micromanagement can work well in very small groups with monumental challenges which require heroics. But micromanagement doesn't grow leaders. I know. I'm a recovering micromanager and I've seen the negative effects of meddling on potential leaders.
It may be easy to criticize someone's ideas. And it's human nature to think that your way is better. You might even be prescient enough to see a potential train wreck coming. But letting leaders own their decisions allows them to feel accountable and learn from their own mistakes. We can't (and we shouldn't) want to teach every person to do every job. We don't know enough and we don't have enough time. Let people learn on their own. Each time you swoop in to solve a problem that you see coming you remove a potential lesson from the people in you organization. Accept mistakes for what they are: cheap leadership training courses.
Clear expectations and defined, yet spacious boundaries with room for mistakes will create leaders in your organization.
Growing Leaders
In a recent post I talked about the need to infuse IT professionals with business, leadership and interpersonal skills. Easier said than done for some, but still possible and a worthy effort. In the coming weeks, I'll discuss some of the principles we use as we try to grow our leaders from within.
- Accountablity, 7/14
- Learn, 9/30
Scrum at Google
Jeff Sutherland is one of the co-creators of "scrum." Scrum is an agile software methodology.
In this talk, Jeff describes how he consulted with Google on their AdWords project and helped them implement Scrum. It's an enjoyable talk. I listened while cleaning my office this morning. Make sure you peek at the slides once in a while which flow as he talks. The Q&A at the end is good.
In this talk, Jeff describes how he consulted with Google on their AdWords project and helped them implement Scrum. It's an enjoyable talk. I listened while cleaning my office this morning. Make sure you peek at the slides once in a while which flow as he talks. The Q&A at the end is good.
Hear from the Engineers
Some of our engineers (program managers, QA, developers and others) have been posting about their experiences working at the LDS Church on the LDS Tech blog.
If you have any interest in what it is like to work at the LDS Church, check it out.
If you have any interest in what it is like to work at the LDS Church, check it out.
Book Club: What Got You Here Won't Get You There
What Got You Here Won't Get You There is the best business book I've read in a long time. The premise is that executives (and managers) will be more successful leaders if they quit being jerks. Sounds simple, but he enumerates exceptional examples of his canonical "20 reasons why leaders fail."
It includes things like "always having to be heard," "shooting the messenger," and "not saying thank you."
Not only does he give hard hitting examples, but he talks about how to start getting rid of these personality and leadership flaws.
Here's the one I'm going to work on: "saying but."
Scenario: Colleague comes in with great idea. Instead of saying "thank you" and expressing the enthusiasm that I actually feel, I say something like: "That's really cool, but..." and then proceed to make my mark on the conversation by bringing up some reason why the idea is partially flawed or a "counterpoint to think about" or just some general critique.
What's the point? Think before you talk and thank people for speaking up! Don't be Mr. Debate all the time! I'm resolving to quit.
It includes things like "always having to be heard," "shooting the messenger," and "not saying thank you."
Not only does he give hard hitting examples, but he talks about how to start getting rid of these personality and leadership flaws.
Here's the one I'm going to work on: "saying but."
Scenario: Colleague comes in with great idea. Instead of saying "thank you" and expressing the enthusiasm that I actually feel, I say something like: "That's really cool, but..." and then proceed to make my mark on the conversation by bringing up some reason why the idea is partially flawed or a "counterpoint to think about" or just some general critique.
What's the point? Think before you talk and thank people for speaking up! Don't be Mr. Debate all the time! I'm resolving to quit.
Tapping with a Sledge Hammer
Last week brought a most excellent event: pinewood derby.
Oh yes. Pinewood derby.
Pinewood derby is a cub scout event where dads cub scouts take a block of pine wood, four nails, and four plastic wheels and create a car. They then race the cars along a track against all of the other dads cub scouts. Dads Cub scouts look forward to this event all year long.
Talk about a rich environment for potential blog entries!
We got the car painted the night before (an improvement over past pinewood derbies) so we planned to wait to put the wheels on the car until the next day when I would "get home early."
Of course we had a late meeting the next day. I live almost an hour away from the office so I called Lani to let her know I would barely make it. We decided that she would bring Alex, the car pieces and a hammer to the event.
A hammer. Not a sledge hammer--a hammer! The axles for these things are tiny little pieces of metal. If you're not familiar with pinewood derby, there are tons of legal tricks you can employ to make your car faster: lubricate the axle, use a drill press to drill new holes closer to the edges, make one of the holes a little higher off the ground than the other three, carve out most of the body and add weight to the back, etc, etc, etc. But no tricks will compensate for bad wheels or bad axles. And in my hand were four tiny little nails and a gigantic hammer. Since we seemed to have no other choice, we lay the car on its side and prepared to insert the axles by pounding them into the soft wood.
A friend stopped us and held up a tiny little hammer. "Try this," she said with a smile.
Back in November I wrote about matching great systems with great people to increase effectiveness. The point, in the conext of this metaphor, was that if people aren't getting the job done, check that you've got the right tools before you blame the worker.
Unfortunately, we often try to do too much with tools and process. We use a sledgehammer for a small job.
In our shop, we have a process we use for accomplishing projects. Most feel the process is too cumbersome and slow. However, when faced with some kind of persistent problem the same people who complain about the burden of the current process want to add more steps or controls, making it even slower or bureaucratic feeling.
If you assume people have good intentions, you can often accomplish the same things through simple training. In our department, we have a number of requirements for software development projects:
When we began implementing process in Church I.T. we had a tendency to put controls and process in place to make sure all of these things happened.
However, process shouldn't be used as a gate unless it's absolutely necessary. Rather, people should be trained to understand expectations and they will, more often than not, comply!
Why use a sledge hammer on a pinewood derby car when you can use a tiny little tapping hammer?
Assume people are well-intended and teach them what they need to do to be effective!
Oh yes. Pinewood derby.
Pinewood derby is a cub scout event where dads cub scouts take a block of pine wood, four nails, and four plastic wheels and create a car. They then race the cars along a track against all of the other dads cub scouts. Dads Cub scouts look forward to this event all year long.
Talk about a rich environment for potential blog entries!
We got the car painted the night before (an improvement over past pinewood derbies) so we planned to wait to put the wheels on the car until the next day when I would "get home early."
Of course we had a late meeting the next day. I live almost an hour away from the office so I called Lani to let her know I would barely make it. We decided that she would bring Alex, the car pieces and a hammer to the event.
A hammer. Not a sledge hammer--a hammer! The axles for these things are tiny little pieces of metal. If you're not familiar with pinewood derby, there are tons of legal tricks you can employ to make your car faster: lubricate the axle, use a drill press to drill new holes closer to the edges, make one of the holes a little higher off the ground than the other three, carve out most of the body and add weight to the back, etc, etc, etc. But no tricks will compensate for bad wheels or bad axles. And in my hand were four tiny little nails and a gigantic hammer. Since we seemed to have no other choice, we lay the car on its side and prepared to insert the axles by pounding them into the soft wood.
A friend stopped us and held up a tiny little hammer. "Try this," she said with a smile.
Back in November I wrote about matching great systems with great people to increase effectiveness. The point, in the conext of this metaphor, was that if people aren't getting the job done, check that you've got the right tools before you blame the worker.
Unfortunately, we often try to do too much with tools and process. We use a sledgehammer for a small job.
In our shop, we have a process we use for accomplishing projects. Most feel the process is too cumbersome and slow. However, when faced with some kind of persistent problem the same people who complain about the burden of the current process want to add more steps or controls, making it even slower or bureaucratic feeling.
If you assume people have good intentions, you can often accomplish the same things through simple training. In our department, we have a number of requirements for software development projects:
- Language must be Java or .NET.
- Code coverage for unit tests must be a certain percentage.
- All of the functional disciplines (like interaction design, development, QA, database, etc.) must be consulted on the plan.
- Resources must be freed up and ready to go.
When we began implementing process in Church I.T. we had a tendency to put controls and process in place to make sure all of these things happened.
However, process shouldn't be used as a gate unless it's absolutely necessary. Rather, people should be trained to understand expectations and they will, more often than not, comply!
Why use a sledge hammer on a pinewood derby car when you can use a tiny little tapping hammer?
Assume people are well-intended and teach them what they need to do to be effective!
Need a CIO? Grow Your Own.
In this post over at CIO.COM, Susan Cramm makes the point that the average I.T. professional who feels he is ready to be a CIO isn't ready at all. She makes a call to CIOs to inform their people that they need to get more "business experience" and to develop "senior level relationships."
Her charge is noble, necessary and terribly difficult. Many I.T. professionals lack skills critical to being successful in a C-level role. To many I.T. professionals, a vertical career track requires technical depth and specialization. Consequently they spend a disproportionate amount of time developing technical skills and not enough time on skills that would help them get into and navigate within the boardroom.
Skills like:
Communication. My department works on hundreds of simultaneous projects. In addition, we operate hundreds of different products and services continually. It's critical that we keep our customers and our management aware of what is going on in the shop. I plead and beg our engineers and project/program managers to write very simple, understandable status reports. It is a constant struggle. A member of my office reviews (and in the past has typically re-written) every one of them. We have a hard time talking without jargon and acronyms.
Relationship Management. When I worked in computer games at Microsoft I often had to "check out the competition" and so played an awful lot of games for a couple of years. I remember telling my wife, Lani, about this great new game called Everquest where you could meet new people, develop friendships and have fun together, all in a virtual world. She said, "Gee Joel. It sounds almost as fun as real life." Hmmm. Sarcasm. The fact is that relationships are easier on line than in real life. If things aren't going well, you log out or you just "block" the other person. You don't have to co-exist in a meaningful way--the biggest source of conflict is deciding who gets the +4 magic, +4 intelligence mace you picked up off a monster your party just clobbered. I know I.T. guys who get along socially just fine in on line games and who struggle to go out to lunch periodically with their customers. "I don't really have anything to talk about with them." "I'm too busy."
Business Acumen. Our shop is going through some growing pains this year as one of our focuses is on writing effective business objectives for a project. It's hard. Engineers think about solving problems very naturally. We don't always think about cost justification. Why does it make business sense to upgrade your application server? "Well, the cache is filling up and we're queue'ing requests. That's why." Upgrading may make all the sense in the world to a technologist who understands what's under the hood, but a business person might decide that the business consequences of not upgrading are acceptable in light of the cost of upgrade. This is particularly relevant at the Church where we have to take extra precautions to keep costs low. Many basic business skills like cost-benefit analysis, contract negotiation, and others are not even taught in computer science or information technology programs, and when those skills are taught, they atrophy in I.T. people who are not being required to use them.
In our department, we're taking steps to help our professionals develop these skills. I'll talk about those steps in the next post.
Her charge is noble, necessary and terribly difficult. Many I.T. professionals lack skills critical to being successful in a C-level role. To many I.T. professionals, a vertical career track requires technical depth and specialization. Consequently they spend a disproportionate amount of time developing technical skills and not enough time on skills that would help them get into and navigate within the boardroom.
Skills like:
Communication. My department works on hundreds of simultaneous projects. In addition, we operate hundreds of different products and services continually. It's critical that we keep our customers and our management aware of what is going on in the shop. I plead and beg our engineers and project/program managers to write very simple, understandable status reports. It is a constant struggle. A member of my office reviews (and in the past has typically re-written) every one of them. We have a hard time talking without jargon and acronyms.
Relationship Management. When I worked in computer games at Microsoft I often had to "check out the competition" and so played an awful lot of games for a couple of years. I remember telling my wife, Lani, about this great new game called Everquest where you could meet new people, develop friendships and have fun together, all in a virtual world. She said, "Gee Joel. It sounds almost as fun as real life." Hmmm. Sarcasm. The fact is that relationships are easier on line than in real life. If things aren't going well, you log out or you just "block" the other person. You don't have to co-exist in a meaningful way--the biggest source of conflict is deciding who gets the +4 magic, +4 intelligence mace you picked up off a monster your party just clobbered. I know I.T. guys who get along socially just fine in on line games and who struggle to go out to lunch periodically with their customers. "I don't really have anything to talk about with them." "I'm too busy."
Business Acumen. Our shop is going through some growing pains this year as one of our focuses is on writing effective business objectives for a project. It's hard. Engineers think about solving problems very naturally. We don't always think about cost justification. Why does it make business sense to upgrade your application server? "Well, the cache is filling up and we're queue'ing requests. That's why." Upgrading may make all the sense in the world to a technologist who understands what's under the hood, but a business person might decide that the business consequences of not upgrading are acceptable in light of the cost of upgrade. This is particularly relevant at the Church where we have to take extra precautions to keep costs low. Many basic business skills like cost-benefit analysis, contract negotiation, and others are not even taught in computer science or information technology programs, and when those skills are taught, they atrophy in I.T. people who are not being required to use them.
In our department, we're taking steps to help our professionals develop these skills. I'll talk about those steps in the next post.
Book Club: The Culture Code
The Culture Code is an amazing read. I don't claim to agree with everything that Rapaille writes, but it's undeniably interesting. The author comes off as a little cocky and presumptuous. If you can get past that, then if part of what you do requires understanding a market then you would do well to read this book.
Bad systems or wrong people?
A key principle in one of my favorite books, Good to Great, is described metaphorically as "getting the right people on the bus." When a manager is trying to move toward a vision, the most important thing he can do to be successful, I believe, is to have great people along for the ride. You can cover an awful lot of organizational weakness by having great people. Some managers feel threatened by surrounding themselves with great people. I try to always hire people who are smarter and more capable than myself. It makes my job much easier and increases my organization's effectiveness.
Hiring great people isn't a panacea, however. It's easy to thwart even the most proficient employee by surrounding him with ineffectual or slow systems. By system, I mean interdependent process and tools--not just tools. Too many times I've hired someone who was very successful in one context, only to see her become frustrated and ineffectual with the context I hired her into.
When facing a situation where an employee seems not to be working out, first consider the system you've surrounded him with. Does she have the tools she needs to be successful? Is he clear on his role? Are you running interference for her? Does he have the time he needs to do his job or is he spending his time floundering in administrivia?
Good managers fix systems first and employees second. In the coming weeks, I'll talk about some of the systems an I.T. shop can focus on improving.
Hiring great people isn't a panacea, however. It's easy to thwart even the most proficient employee by surrounding him with ineffectual or slow systems. By system, I mean interdependent process and tools--not just tools. Too many times I've hired someone who was very successful in one context, only to see her become frustrated and ineffectual with the context I hired her into.
When facing a situation where an employee seems not to be working out, first consider the system you've surrounded him with. Does she have the tools she needs to be successful? Is he clear on his role? Are you running interference for her? Does he have the time he needs to do his job or is he spending his time floundering in administrivia?
Good managers fix systems first and employees second. In the coming weeks, I'll talk about some of the systems an I.T. shop can focus on improving.
Book Club: Primal Leadership
I've been reading Primal Leadership and it is exceptional.
It's written by the same gentleman who wrote Emotional Intelligence. He discusses why some people are better at dealing with emotional issues like empathy and self-awareness then others and also discusses how to improve our skills in these areas, both as individuals and as groups.
It's written by the same gentleman who wrote Emotional Intelligence. He discusses why some people are better at dealing with emotional issues like empathy and self-awareness then others and also discusses how to improve our skills in these areas, both as individuals and as groups.
Subscribe to:
Posts (Atom)