One of the strong selling points of pair programming is that knowledge of the code base, techniques, and domain are shared across multiple people. We joke that this reduces the "truck factor" for a team. Truck factor is the risk to the team or project of any specific person getting "hit by a truck".
Some other phrases: "beer truck factor", for those who like to imagine being hit by a worthy cause, or "lottery factor", as one colleague suggested, since it is a happier ending.
High truck factors can be good for the individual. After all, if your specific knowledge or talent is critical to the firm, so too, is your ability to negotiate for higher compensation or to easily acquire extra latitude for resources and decision-making authority. Management does not want to scare away the geese that lay the golden eggs when they have no idea how the egg-laying works.
A high truck factor has a downside for the individual though. When you finally get tired of the same platform/domain/language and want to move on, the hand that feeds you is likely to restrain you from departing to other projects. Sometimes, the only departure path is to leave the company. That can be a good thing for getting out of a rut (and introducing potentially lucrative contract work with your prior employer), but can also force you to start from scratch in building a reputation in a new situation.
What of leadership/management? How do we reduce the truck factor for managers? They don't typically pair. What happens when opportunities arise for a promotion, or an exciting lateral move, but the leader is tied to his current position with no replacement in site? Perhaps he needs to turn the new position down. Perhaps the external market is tapped for a replacement. Perhaps he just adds the new position's responsibilities to his current responsibilities. These are smells of poor succession planning.
If you're a technical superstar, or simply a master of your technical niche, or
if you're a domain expert, or simply master of your domain niche, or
if you're a leadership expert, or simply the most ingrained leader in your current role:
Identify, train and groom your successor(s)
You never know when that lottery ticket will hit.
Showing posts with label Leadership. Show all posts
Showing posts with label Leadership. Show all posts
Friday, April 16, 2010
Wednesday, December 09, 2009
Politics at work
I just read The Five Dysfunctions of a Team on the plane this week.
I saw an interesting interpretation of the term "politics" which intrigues me:
"Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think."
I saw an interesting interpretation of the term "politics" which intrigues me:
"Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think."
Monday, January 26, 2009
Developing Extreme Talent
Thanks to Jason Yip's blog entry: On chess grandmasters and the expert mind for pointing me to this fascinating article - The Expert Mind: Studies of the mental processes of chess grandmasters have revealed clues to how people become experts in other fields as well - from Scientific American.
From the Scientific American article:
The concept of effortful study essentially suggests that you grow only when you push yourself. As a very-practiced and accomplished pool player (before I had a family and other commitments), I know that I only improved when I played better players. Seeing this article expanded my thinking on the topic into other areas... such as programming talent and general education (I have four young children).
This points to difficulties in making our educational system effective: teachers who are responsible for 15 or 20 students cannot possibly tailor the education to push the envelope for each child. Even with five children, a common lesson plan loses the ability to maintain that tension between comfort and discomfort that leads to the kind of discovery that keeps up with a student's need to push forward. This is precisely why parental involvement is necessary ... to maintain that tension and to challenge our children - not just in maintaining the necessarily dictated classroom pace, but in tapping into the wellspring of talent and desire living within our children. I see it so clearly now.
Perhaps Laszlo's ability to adapt the level of effort required for each child helped. I'm interested in learning more about how much of his lesson plans were chess oriented and how much were geared towards general education. There's also the genetics argument; if he was good at chess, perhaps he passed on the chess genes.
This argument for driving towards early success is somewhat orthogonal to the "effortful study" thesis, but bears import to the parenting issue (and perhaps the programmer development issue as well). Positive reinforcement and successful results early-on can provide the confidence that children and programmers need to continue pushing forward.
If you are a parent, or a mentor of a young programmer (or any other professional I would think), these concepts bear consideration.
From the Scientific American article:
"K. Anders Ericsson of Florida State University argues that what matters [toward improving one's chess playing skill] is not experience per se but "effortful study," which entails continually tackling challenges that lie just beyond one's competence. That is why it is possible for enthusiasts to spend tens of thousands of hours playing chess or golf or a musical instrument without ever advancing beyond the amateur level and why a properly trained student can overtake them in a relatively short time. It is interesting to note that time spent playing chess, even in tournaments, appears to contribute less than such study to a player's progress; the main training value of such games is to point up weaknesses for future study."
The concept of effortful study essentially suggests that you grow only when you push yourself. As a very-practiced and accomplished pool player (before I had a family and other commitments), I know that I only improved when I played better players. Seeing this article expanded my thinking on the topic into other areas... such as programming talent and general education (I have four young children).
"The preponderance of psychological evidence indicates that experts are made, not born. What is more, the demonstrated ability to turn a child quickly into an expert--in chess, music and a host of other subjects--sets a clear challenge before the schools."
This points to difficulties in making our educational system effective: teachers who are responsible for 15 or 20 students cannot possibly tailor the education to push the envelope for each child. Even with five children, a common lesson plan loses the ability to maintain that tension between comfort and discomfort that leads to the kind of discovery that keeps up with a student's need to push forward. This is precisely why parental involvement is necessary ... to maintain that tension and to challenge our children - not just in maintaining the necessarily dictated classroom pace, but in tapping into the wellspring of talent and desire living within our children. I see it so clearly now.
"Laszlo Polgar, an educator in Hungary, homeschooled his three daughters in chess, assigning as much as six hours of work a day, producing one international master and two grandmasters--the strongest chess-playing siblings in history. The youngest Polgar, 30-year-old Judit, is now ranked 14th in the world."
Perhaps Laszlo's ability to adapt the level of effort required for each child helped. I'm interested in learning more about how much of his lesson plans were chess oriented and how much were geared towards general education. There's also the genetics argument; if he was good at chess, perhaps he passed on the chess genes.
"[...] success builds on success, because each accomplishment can strengthen a child's motivation. A 1999 study of professional soccer players from several countries showed that they were much more likely than the general population to have been born at a time of year that would have dictated their enrollment in youth soccer leagues at ages older than the average. In their early years, these children would have enjoyed a substantial advantage in size and strength when playing soccer with their teammates. Because the larger, more agile children would get more opportunities to handle the ball, they would score more often, and their success at the game would motivate them to become even better."
This argument for driving towards early success is somewhat orthogonal to the "effortful study" thesis, but bears import to the parenting issue (and perhaps the programmer development issue as well). Positive reinforcement and successful results early-on can provide the confidence that children and programmers need to continue pushing forward.
If you are a parent, or a mentor of a young programmer (or any other professional I would think), these concepts bear consideration.
Monday, December 22, 2008
Wanted: Software Development Leader
One thing led to another and there I was contemplating the job req for what I would look for in (and what I strive to be as) a software development leader.
Experience:
- Development experience - preferably within the last decade
Aptitude:
- Can tell a crappy architecture from a sound architecture
- Can tell a crappy implementation from a sound implementation
- Can tell the difference between someone who is busy and someone who is productive
- Can discern the difference between a good candidate for a position "on paper" and a good candidate for real
- Demonstrates a deep understanding of what quality means for a software product (including non-functional requirements like performance, supportability, and extensibility)
- Can tell when an architect, developer, QA, BA, or business partner is blowing smoke up his hind quarters
- Can speak the dialect of business - ROI, NPV, customer acquisition cost
- Can relate to business stakeholders and build collaborative relationships
- Can connect to team members on a personal level
- Has a good sense of humor
- Understands the difference between a prototype and a production application
Attitude:
- Will call out a crappy architecture and drive change
- Will call out a crappy implementation and drive change
- Will call out the busy-bees and the smoke-blowers
- Will demand demonstrable quality (including non-functional requirements)
- Will demand reasonable tests (unit tests, component tests, system tests)
- Does not suffer fools gladly
- Will not sit through a PowerPoint that depicts supposed progress without demanding demonstration of said progress
- Will not abide bubble gum and duct tape solutions to production (or development) defects
- Demands continuous improvement
- Demands root cause analysis (5 why's)
- Demands customer involvement in product development
- Continuously seeks to improve efficiency by asking "why" and "how can we do this more efficiently" (e.g. - PMO requirements for excessive documentation)
- Is willing to fight for the resources required by the team to deliver
- Cares deeply about the team
- Cares about the career development of team members
- Cares deeply about product quality
- Will celebrate true success with the team (no gratuitous applause please)
- Will always give credit to the team for success
- Will remove team members when necessary
- Has a coaching mentality
- Is willing to get hands dirty (writing code, writing/running/debugging tests, fetching pizza)
- Is always available to the team
- Exhibits patience, when appropriate
- Exhibits impatience, when appropriate
Integrity:
- Tells the truth - for instance about project status
- Is clear to team members on expectations and performance on a regular basis (not just at review time)
- Is willing to stand up and fight for the team
Ah... it's late. that's as far as I got. I felt like the integrity section was short, but many of the integrity issues bled into attitude. What did I miss? What do you disagree with?
Experience:
- Development experience - preferably within the last decade
Aptitude:
- Can tell a crappy architecture from a sound architecture
- Can tell a crappy implementation from a sound implementation
- Can tell the difference between someone who is busy and someone who is productive
- Can discern the difference between a good candidate for a position "on paper" and a good candidate for real
- Demonstrates a deep understanding of what quality means for a software product (including non-functional requirements like performance, supportability, and extensibility)
- Can tell when an architect, developer, QA, BA, or business partner is blowing smoke up his hind quarters
- Can speak the dialect of business - ROI, NPV, customer acquisition cost
- Can relate to business stakeholders and build collaborative relationships
- Can connect to team members on a personal level
- Has a good sense of humor
- Understands the difference between a prototype and a production application
Attitude:
- Will call out a crappy architecture and drive change
- Will call out a crappy implementation and drive change
- Will call out the busy-bees and the smoke-blowers
- Will demand demonstrable quality (including non-functional requirements)
- Will demand reasonable tests (unit tests, component tests, system tests)
- Does not suffer fools gladly
- Will not sit through a PowerPoint that depicts supposed progress without demanding demonstration of said progress
- Will not abide bubble gum and duct tape solutions to production (or development) defects
- Demands continuous improvement
- Demands root cause analysis (5 why's)
- Demands customer involvement in product development
- Continuously seeks to improve efficiency by asking "why" and "how can we do this more efficiently" (e.g. - PMO requirements for excessive documentation)
- Is willing to fight for the resources required by the team to deliver
- Cares deeply about the team
- Cares about the career development of team members
- Cares deeply about product quality
- Will celebrate true success with the team (no gratuitous applause please)
- Will always give credit to the team for success
- Will remove team members when necessary
- Has a coaching mentality
- Is willing to get hands dirty (writing code, writing/running/debugging tests, fetching pizza)
- Is always available to the team
- Exhibits patience, when appropriate
- Exhibits impatience, when appropriate
Integrity:
- Tells the truth - for instance about project status
- Is clear to team members on expectations and performance on a regular basis (not just at review time)
- Is willing to stand up and fight for the team
Ah... it's late. that's as far as I got. I felt like the integrity section was short, but many of the integrity issues bled into attitude. What did I miss? What do you disagree with?
Sunday, May 11, 2008
Top Chef Leadership
I'm becoming addicted to Bravo Network's "Top Chef" show. OK, so I'm generally addicted to cooking shows, but have, heretofore, confined my addiction to the Food Network.
I feel the role of a chef is a melding of cooking and leadership. Top Chef seems to focus more on the cooking aspect, and the extent to which folks step up in the delivery of good food. I think this misses a large part of the role of a chef. It's not enough to be able to deliver high quality food. You have to be adept at inspiring the other cooks in your kitchen to deliver.
Nikki, one of the chefs who was eliminated recently, was canned mostly because the menu was Italian, and she didn't exert leadership in driving the menu; her forte' is Italian food. So her inability to exert leadership was pivotal for her. One of the guys who escaped elimination focused on one dish - vs. another who went to the mat for the team in doing almost everything else.
When the elimination was announced, other chefs shook their heads. They knew that the one-dish guy should have been the one to go...
An ex-colleague of mine regales me of similar stories from her company. Promotions that make mouths gape, people surviving layoffs when more capable people are released. She sees some of the same aspects from "Top Chef" in that company. One-dish wonders survive because they play the game better than others. I sometimes wonder why "Top Chef" doesn't ask the other cooks directly about who should be eliminated.I guess that's show business.
I feel the role of a chef is a melding of cooking and leadership. Top Chef seems to focus more on the cooking aspect, and the extent to which folks step up in the delivery of good food. I think this misses a large part of the role of a chef. It's not enough to be able to deliver high quality food. You have to be adept at inspiring the other cooks in your kitchen to deliver.
Nikki, one of the chefs who was eliminated recently, was canned mostly because the menu was Italian, and she didn't exert leadership in driving the menu; her forte' is Italian food. So her inability to exert leadership was pivotal for her. One of the guys who escaped elimination focused on one dish - vs. another who went to the mat for the team in doing almost everything else.
When the elimination was announced, other chefs shook their heads. They knew that the one-dish guy should have been the one to go...
An ex-colleague of mine regales me of similar stories from her company. Promotions that make mouths gape, people surviving layoffs when more capable people are released. She sees some of the same aspects from "Top Chef" in that company. One-dish wonders survive because they play the game better than others. I sometimes wonder why "Top Chef" doesn't ask the other cooks directly about who should be eliminated.I guess that's show business.
Sunday, April 20, 2008
Receiving Feedback
My last post on feedback was on giving constructive feedback. Here, I'll focus on receiving feedback.
In the question of feedback - what, where, when, why, and how - the receiver of the feedback may not have control over many of the elements. To some extent, your ability to receive feedback effectively is determined by how effectively the provider shares it. But you do have some control.
If you have a regularly scheduled one-on-one with someone, or performance review meetings, you should always be prepared for feedback. Prepare yourself for these meetings with an attitude adjustment that suggests "I am open and willing to receive feedback constructively so that I can improve". If you enter meetings with this mental preparation, you are way ahead of the game.
Another attitude adjustment that helps you to receive feedback openly is to consider the alternative. That is - what if the person providing this feedback just stayed quiet? I assert that you always gain information and knowledge (even if it's simply an impression of the regard that the giver of feedback holds for you). Treat it as an information gathering exercise. You will learn
First, let's cover the "when" and "where" of feedback. I've already mentioned naturally occurring events where feedback will be shared. But it sometimes occurs (and should more often occur) in an ad hoc manner. If you sense that you are not in a good mental or physical place to deal with feedback at that time, it is well within your control to request a postponement of the discussion. Try something like this: "Adrian, I am very interested in hearing your feedback, but would it be OK if we schedule some time to discuss this privately - perhaps tomorrow morning? I feel like I will be in a better place to listen and take your feedback constructively at that time".
"What" feedback provided is primarily - but not exclusively - determined by the person providing feedback. If I tell Jeff that the coffee he has been providing me is too hot, that is the primary message. But if Jeff probes on what the temperature should be, what I feel the temperature has been and such, he can steer the feedback towards the constructive content he needs in order to improve. In this way, he can control the "what". In addition, he can use it as an opportunity to probe for related (or unrelated) feedback.
"How" the feedback is provided can be steered by the recipient as well. I mentioned in the "giving feedback" post that one should focus on the behavior and not the person and should provide specific examples of where the behavior needed improvement. If the feedback giver is speaking in generalities, you can steer him by asking for specific examples. If he can't provide specific examples, ask him to keep an eye out for instances in the future. Something like: "I appreciate your feedback that I'm often late for standups without providing advance notice. I can't recall an instance when I failed to notify you in advance - though I do remember the one time that I overslept, which I understand is not a great excuse. I will make every effort to be on time and to notify you if extenuating circumstances arise. If you find examples when I fail to do so, could you please notify me right away, so I can determine the root cause at that time". OK, I'm going on and on for a silly example; you get the idea.
Take notes. Sometimes - particularly if feedback is negative - our emotions cloud our ability to retain the information being provided. It is helpful to take notes to revisit once the dust settles.
Always receive feedback in a positive manner. Always thank the person for taking the time to give you the feedback - even if you disagree. We need to reward people with thanks for taking the time, effort, and risk of conflict to provide feedback. "Thank you, Adrian, for the feedback on the temperature of the coffee. Though I think I've been rigorous about controlling the temperature, perhaps if I find a thermometer for you to measure, you can let me know the temperature you find when the heat is unbearable. In this way, I can improve my coffee provisioning". (I'm getting tired of this example... from now on, no more coffee... this analogy has run its course).
Don't be defensive! Again, treat the feedback as a gift, not as an attack. You're not perfect. We all strive towards perfection, and the more input and feedback we receive from others, the more adjustments we can make on the path.
Don't fight back with criticism. "Yeah? Well, I think your burnup charts should be done in crayon, Adrian, because they're like the work of a 3-year-old."
Consider returning to the person who gave you the feedback after you've had time to digest and perhaps implement some change. "Thank you again for the feedback you gave me last week. I've been thinking about it, and have adjusted a couple of things. Can I share with you the changes I've made?" This shows a healthy dose of maturity, willingness to improve, and respect for the person who took the time to give you feedback.
I'm open to receiving [meta?] feedback on this post.
In the question of feedback - what, where, when, why, and how - the receiver of the feedback may not have control over many of the elements. To some extent, your ability to receive feedback effectively is determined by how effectively the provider shares it. But you do have some control.
If you have a regularly scheduled one-on-one with someone, or performance review meetings, you should always be prepared for feedback. Prepare yourself for these meetings with an attitude adjustment that suggests "I am open and willing to receive feedback constructively so that I can improve". If you enter meetings with this mental preparation, you are way ahead of the game.
Another attitude adjustment that helps you to receive feedback openly is to consider the alternative. That is - what if the person providing this feedback just stayed quiet? I assert that you always gain information and knowledge (even if it's simply an impression of the regard that the giver of feedback holds for you). Treat it as an information gathering exercise. You will learn
- What that person thinks about your behavior - or even you
- By extension, if that person holds that view, then others may as well
- Hopefully - examples of the behavior that the reviewer deems in need of improvement
- Suggestions of how you can improve
First, let's cover the "when" and "where" of feedback. I've already mentioned naturally occurring events where feedback will be shared. But it sometimes occurs (and should more often occur) in an ad hoc manner. If you sense that you are not in a good mental or physical place to deal with feedback at that time, it is well within your control to request a postponement of the discussion. Try something like this: "Adrian, I am very interested in hearing your feedback, but would it be OK if we schedule some time to discuss this privately - perhaps tomorrow morning? I feel like I will be in a better place to listen and take your feedback constructively at that time".
"What" feedback provided is primarily - but not exclusively - determined by the person providing feedback. If I tell Jeff that the coffee he has been providing me is too hot, that is the primary message. But if Jeff probes on what the temperature should be, what I feel the temperature has been and such, he can steer the feedback towards the constructive content he needs in order to improve. In this way, he can control the "what". In addition, he can use it as an opportunity to probe for related (or unrelated) feedback.
"How" the feedback is provided can be steered by the recipient as well. I mentioned in the "giving feedback" post that one should focus on the behavior and not the person and should provide specific examples of where the behavior needed improvement. If the feedback giver is speaking in generalities, you can steer him by asking for specific examples. If he can't provide specific examples, ask him to keep an eye out for instances in the future. Something like: "I appreciate your feedback that I'm often late for standups without providing advance notice. I can't recall an instance when I failed to notify you in advance - though I do remember the one time that I overslept, which I understand is not a great excuse. I will make every effort to be on time and to notify you if extenuating circumstances arise. If you find examples when I fail to do so, could you please notify me right away, so I can determine the root cause at that time". OK, I'm going on and on for a silly example; you get the idea.
Take notes. Sometimes - particularly if feedback is negative - our emotions cloud our ability to retain the information being provided. It is helpful to take notes to revisit once the dust settles.
Always receive feedback in a positive manner. Always thank the person for taking the time to give you the feedback - even if you disagree. We need to reward people with thanks for taking the time, effort, and risk of conflict to provide feedback. "Thank you, Adrian, for the feedback on the temperature of the coffee. Though I think I've been rigorous about controlling the temperature, perhaps if I find a thermometer for you to measure, you can let me know the temperature you find when the heat is unbearable. In this way, I can improve my coffee provisioning". (I'm getting tired of this example... from now on, no more coffee... this analogy has run its course).
Don't be defensive! Again, treat the feedback as a gift, not as an attack. You're not perfect. We all strive towards perfection, and the more input and feedback we receive from others, the more adjustments we can make on the path.
Don't fight back with criticism. "Yeah? Well, I think your burnup charts should be done in crayon, Adrian, because they're like the work of a 3-year-old."
Consider returning to the person who gave you the feedback after you've had time to digest and perhaps implement some change. "Thank you again for the feedback you gave me last week. I've been thinking about it, and have adjusted a couple of things. Can I share with you the changes I've made?" This shows a healthy dose of maturity, willingness to improve, and respect for the person who took the time to give you feedback.
I'm open to receiving [meta?] feedback on this post.
Giving feedback
Giving and receiving feedback is difficult.
Umm... well. That's not exactly correct. Giving feedback is easy. Giving constructive feedback is difficult.
For now, let’s focus on giving feedback
In my team blog, I used the example of one of my team members getting me coffee. It was meant in jest, but I won't use his name here... Let’s use that as an example in giving/receiving feedback.
Adrian: Hey Jerry… I want to talk to you about something. The coffee thing isn’t working for me. You’re not satisfying my requirements. The coffee is frequently too hot, and you’re always late with it. I’m really annoyed with you.
Jerry: I don’t know what you’re talking about. I always get that seam thing right… well, most of the time. And I can’t control the heat of coffee. And I’m not late with it. You must be delirious. I’m doing the best I can. I’m better at getting coffee than David was.
Adrian: Come on, I know you can do better. Please, let’s get that coffee thing fixed.
What’s wrong with this dialog - everything?
No. There is something good here…. There is a bit of specificity in the feedback. There are three things brought up here… the heat of the coffee, delivery timing, and the seam facing the right way.
There are many things wrong with the dialog. Adrian is making several common mistakes.
Adrian should give positive as well as negative feedback. We tend to speak up when something is wrong and focus on what’s wrong. We should find opportunities to give positive feedback in relation to the negative feedback. So something like
Adrian: Hey Jerry… Thanks for getting me coffee. The other day when I got in, I was so rushed and needed to get off to a meeting; it was nice to have my coffee right here ready to go. It made a huge difference in my day that day. One thing I’ve been meaning to mention – it seems to be too hot sometimes. Last Thursday, it burned the roof of my mouth. Was there something specific you did that day that caused it to be hotter than usual? Is there some way that we can get the temperature down a bit?
Jerry: Gee, I don’t know. It may be that you got it that day right when I returned from the coffee shop. I can’t control the temperature of the coffee they serve, but perhaps I could get some ice cubes and have them available for you. Would that work? Or perhaps if you called when you are 10 minutes away from work, I can get the coffee then, so the coffee has some time to cool.
Adrian: Those are great suggestions. I hadn’t thought of ice cubes. Don’t worry about getting them for me; I’ll just get one and pop it in if it’s too hot.
Notice the difference in the tone of the conversation. Adrian and Jerry are collaborating in finding a way to get the heat of the coffee right. Also – Adrian is being much more specific.
It is critical in giving feedback to find instances where the results were not acceptable. “Last Thursday” provides a very specific example that Jerry can think back to. Last Thursday is also relatively timely. We’re not talking about last month.
The coffee being “always late” is clearly not accurate. Again, by providing specific examples and focusing on the behavior or results rather than the person, you are more apt to get the results you seek.
Here are some attributes of effective feedback:
• Specific – rather than general. With specific examples.
• Sharing impact. Why is the behavior a problem? What was the impact of the poor performance to the team, to the company, etc.?
• Timely – both in relation to the incident/behavior, and in terms of the recipient’s receptiveness (e.g. not when the person is on their way out the door or troubleshooting a high priority production issue).
• Focused on the behavior, not the person
There are more, but this is a start.
Next time, I'll address receiving feedback.
Umm... well. That's not exactly correct. Giving feedback is easy. Giving constructive feedback is difficult.
For now, let’s focus on giving feedback
In my team blog, I used the example of one of my team members getting me coffee. It was meant in jest, but I won't use his name here... Let’s use that as an example in giving/receiving feedback.
Adrian: Hey Jerry… I want to talk to you about something. The coffee thing isn’t working for me. You’re not satisfying my requirements. The coffee is frequently too hot, and you’re always late with it. I’m really annoyed with you.
Jerry: I don’t know what you’re talking about. I always get that seam thing right… well, most of the time. And I can’t control the heat of coffee. And I’m not late with it. You must be delirious. I’m doing the best I can. I’m better at getting coffee than David was.
Adrian: Come on, I know you can do better. Please, let’s get that coffee thing fixed.
What’s wrong with this dialog - everything?
No. There is something good here…. There is a bit of specificity in the feedback. There are three things brought up here… the heat of the coffee, delivery timing, and the seam facing the right way.
There are many things wrong with the dialog. Adrian is making several common mistakes.
Adrian should give positive as well as negative feedback. We tend to speak up when something is wrong and focus on what’s wrong. We should find opportunities to give positive feedback in relation to the negative feedback. So something like
Adrian: Hey Jerry… Thanks for getting me coffee. The other day when I got in, I was so rushed and needed to get off to a meeting; it was nice to have my coffee right here ready to go. It made a huge difference in my day that day. One thing I’ve been meaning to mention – it seems to be too hot sometimes. Last Thursday, it burned the roof of my mouth. Was there something specific you did that day that caused it to be hotter than usual? Is there some way that we can get the temperature down a bit?
Jerry: Gee, I don’t know. It may be that you got it that day right when I returned from the coffee shop. I can’t control the temperature of the coffee they serve, but perhaps I could get some ice cubes and have them available for you. Would that work? Or perhaps if you called when you are 10 minutes away from work, I can get the coffee then, so the coffee has some time to cool.
Adrian: Those are great suggestions. I hadn’t thought of ice cubes. Don’t worry about getting them for me; I’ll just get one and pop it in if it’s too hot.
Notice the difference in the tone of the conversation. Adrian and Jerry are collaborating in finding a way to get the heat of the coffee right. Also – Adrian is being much more specific.
It is critical in giving feedback to find instances where the results were not acceptable. “Last Thursday” provides a very specific example that Jerry can think back to. Last Thursday is also relatively timely. We’re not talking about last month.
The coffee being “always late” is clearly not accurate. Again, by providing specific examples and focusing on the behavior or results rather than the person, you are more apt to get the results you seek.
Here are some attributes of effective feedback:
• Specific – rather than general. With specific examples.
• Sharing impact. Why is the behavior a problem? What was the impact of the poor performance to the team, to the company, etc.?
• Timely – both in relation to the incident/behavior, and in terms of the recipient’s receptiveness (e.g. not when the person is on their way out the door or troubleshooting a high priority production issue).
• Focused on the behavior, not the person
There are more, but this is a start.
Next time, I'll address receiving feedback.
Tuesday, February 26, 2008
Seeing how others see
I'm taking a Myers Briggs test right now. My whole team is taking the test this week. I learned alot from doing the test in grad school; it helped many of us adapt to our different approaches to working. But that's for another blog entry.
One of the questions: Are you more likely to
a) see how others are useful
b) see how others see
My answer is a), but I wish it were b). That's not to say I'm all about usefulness; I think I do probe on a deeper level more than most would consider typical of a manager. But I think there's something here to work on. The a) answer is more tactical I think; b) is more strategic. Are you seeking results? Or are you seeking to understand the people on the bus1 to channel them effectively towards helping you to - not only answer questions and solve problems, but to - ask the right questions and identify the approach to solving the problem.
I blogged some time ago about this quote I like - "Managers use people to do work; Leaders use work to grow people." Related (same?) point.
1Reference here to "Good to Great"... a book that suggests that one of the attributes of a company that bridges the gap from good to great is that it focuses less on the strategy than on the people you have defining the strategy... their metaphor is a bus, having the right people on the bus, and having the right people in the right seats on the bus.
One of the questions: Are you more likely to
a) see how others are useful
b) see how others see
My answer is a), but I wish it were b). That's not to say I'm all about usefulness; I think I do probe on a deeper level more than most would consider typical of a manager. But I think there's something here to work on. The a) answer is more tactical I think; b) is more strategic. Are you seeking results? Or are you seeking to understand the people on the bus1 to channel them effectively towards helping you to - not only answer questions and solve problems, but to - ask the right questions and identify the approach to solving the problem.
I blogged some time ago about this quote I like - "Managers use people to do work; Leaders use work to grow people." Related (same?) point.
1Reference here to "Good to Great"... a book that suggests that one of the attributes of a company that bridges the gap from good to great is that it focuses less on the strategy than on the people you have defining the strategy... their metaphor is a bus, having the right people on the bus, and having the right people in the right seats on the bus.
Thursday, October 18, 2007
Growing People
I saw a great quote the other day referenced on a blog. I can't stop thinking about it. It's from the book "Powerful Project Leadership" and the quote is:
"Managers use people to accomplish work; leaders use work to grow people".
This quote captures a great deal of what I think about leadership. It's about really caring about people. You can try to fake it (ala "How to Win Friends and Influence People"), but folks can see through the ruse. True leadership requires, I think, a fundamental desire to develop people to their ultimate potential. It's sort of like the adage "Satisfy the customer; the profits will follow" with a twist: "Satisfy the fundamental needs of your employees to contribute and grow, and the profits will follow".
"Managers use people to accomplish work; leaders use work to grow people".
This quote captures a great deal of what I think about leadership. It's about really caring about people. You can try to fake it (ala "How to Win Friends and Influence People"), but folks can see through the ruse. True leadership requires, I think, a fundamental desire to develop people to their ultimate potential. It's sort of like the adage "Satisfy the customer; the profits will follow" with a twist: "Satisfy the fundamental needs of your employees to contribute and grow, and the profits will follow".
Sunday, October 07, 2007
Agile Leadership and Typical Management Titles
I worked at a very big company as a software engineer for 15 years. When I began out of college, my title was "junior programmer". The promotion path was well known. Perform at a level between barely satisfactory and outstanding and get promoted in a year to "associate programmer". Keep doing a satisfactory job, get promoted again two years later to "senior associate programmer". Two more years and it was "staff programmer" (and get your own office). Promotions after that were less structured/timed and based strictly on merit.
Well... OK... not just merit.
Of course there was also the management path at this company, but the gig was the same.... keep doing a good job, keep climbing that ladder.
I'm now an agile guy. I look back and can't believe I had to function in such a dysfunctional system. I left that far behind. Or so I thought.
As a consultant, I get to operate in many different environments. Sometimes I get to work with just my team - the enlightened, intelligent, cutting-edge consultants at Thoughtworks and we can build a sort of bubble of rationality - a pseudo meritocracy. More often, I have to manage within the constructs of the company in which I am consulting. Many of them look like my first company where employees are operating on the ladder path.... climbing away. So the question is: when you remove rungs off the ladder in the flattening exercise (whether explicitly or implicitly), what becomes of those who were on those rungs?
Different positions - whether higher (1) on the ladder, lateral, or even lower (1) require different skills and expertise. If you're a developer, you may get promoted to "development manager" because you write great software. The aptitude, skills and motivation to write great software are very different from the aptitude, knowledge, and motivation required to be a good manager or leader. Moving "down" the ladder - say, back to writing software - usually requires missing skills, since technology changes so quickly.
So what aptitude, skills, and motivation do agile leaders need? Here's my list (in no particular order):
The key for the project, I think, is to ensure that these responsibilities are represented in the leadership team overall, not necessarily in one person.
How do these map to more traditional hierarchical positions?
Any of the folks in these positions can provide agile leadership. In general, the more of these leadership aspects that are exhibited by folks in leadership roles the better. For example, though the C-level leader is likely to have ability to inspire, having a development manager who can also inspire can be a great bonus for the project.
Stay tuned for more on each of the agile leadership opportunities I enumerated. In the meantime... tell me what I've missed.
(1) Higher and lower are expressed, for the purposes of this conversation, in terms of the typical hierarchical leadership. I'll save the servant leadership and inverted pyramid conversation for another time.
Well... OK... not just merit.
Of course there was also the management path at this company, but the gig was the same.... keep doing a good job, keep climbing that ladder.
I'm now an agile guy. I look back and can't believe I had to function in such a dysfunctional system. I left that far behind. Or so I thought.
As a consultant, I get to operate in many different environments. Sometimes I get to work with just my team - the enlightened, intelligent, cutting-edge consultants at Thoughtworks and we can build a sort of bubble of rationality - a pseudo meritocracy. More often, I have to manage within the constructs of the company in which I am consulting. Many of them look like my first company where employees are operating on the ladder path.... climbing away. So the question is: when you remove rungs off the ladder in the flattening exercise (whether explicitly or implicitly), what becomes of those who were on those rungs?
Different positions - whether higher (1) on the ladder, lateral, or even lower (1) require different skills and expertise. If you're a developer, you may get promoted to "development manager" because you write great software. The aptitude, skills and motivation to write great software are very different from the aptitude, knowledge, and motivation required to be a good manager or leader. Moving "down" the ladder - say, back to writing software - usually requires missing skills, since technology changes so quickly.
So what aptitude, skills, and motivation do agile leaders need? Here's my list (in no particular order):
- Communication/Collaboration skills - "down" - in coaching and developing people within your organization
- Communication/Collaboration skills - "across" - in collaborating with folks on peer projects, others within IT
- Communication/Collaboration skills - "up" - in managing relationships with higher level IT management/leadership
- Communication/Collaboration skills - "Business" - in managing relationships with the business
- Technical skills - understanding the technology, architecture
- Domain knowledge - understanding the business
- Agile Project Management - from estimation and planning to iteration tracking
- Ability to inspire
- A fundamental philosophy that prefers frequent inspection and adaption to continuously improve
The key for the project, I think, is to ensure that these responsibilities are represented in the leadership team overall, not necessarily in one person.
How do these map to more traditional hierarchical positions?
- development/QA/BA manager (managing a group of folks based on functional alignment)
- lead developer/QA/BA (individual contributor who is annointed with the "lead" adjective).
- architect (might be a member of an architecture team, or may just be a responsibility for someone holding a different title)
- director of development (overseeing everything from requirements to release for a project)
- C-level leader (person who holds the pursestrings, defines strategy, provides the context & constraints in which the project must operate)
Any of the folks in these positions can provide agile leadership. In general, the more of these leadership aspects that are exhibited by folks in leadership roles the better. For example, though the C-level leader is likely to have ability to inspire, having a development manager who can also inspire can be a great bonus for the project.
Stay tuned for more on each of the agile leadership opportunities I enumerated. In the meantime... tell me what I've missed.
(1) Higher and lower are expressed, for the purposes of this conversation, in terms of the typical hierarchical leadership. I'll save the servant leadership and inverted pyramid conversation for another time.
Saturday, June 16, 2007
10 Attributes of Well-Run Meetings
I love well-run meetings. The key here - well-run. What are the qualities of a well-run meeting?
1) Facilitated. Note the distinction between this property and "led" or "managed" or "controlled". The person running the meeting has good skills at eliciting input, tracking progress and action items, and keeping everyone engaged.
2) Non-laptop/PDA focused. I can't recount how many meetings I've attended where one or, usually more, attendees have laptops/PDA's open and are focused somewhere else. Yes, I understand multitasking and the demands on our time, and the usefulness of getting things done while sitting in a meeting. The cause and effect here is not always clear, but I submit that if the meeting was well-run, the attendees would be riveted to the discussion topic to the point where they'd forget they were carrying a PDA.
3) Accomplishment-bound instead of time-bound. Meetings fill the time they are allotted. If you have 26 minutes worth of productive discussion, don't keep the meeting going to fill the whole hour you reserved. Keep focused, accomplish your objective, and release folks early to go do their email.
4) Speaking of objectives.... HAVE ONE! In agile, we talk about having "acceptance criteria" for story completion. We should adopt the same approach to meeting management. An agenda would be nice too - for more formal meetings - but I don't think it's always necessary.
5) Take issues offline. This is easy for an effective facilitator to drive, but is not done nearly enough.
6) Determine if a meeting is the right approach to accomplishing your objective. I was a participant in a weekly meeting for a couple of months for which the only agenda item was to go through an action item list and report status. I stopped going. So did many others. Fortunately, the organizer(s) got the message and canceled it. We can easily update a wiki as needed to update status. If folks have questions, walk over to the other person's office and talk in person.
7) Find a good time for the meeting. I know that cross-oceanic teams sometimes necessitate bizarre meeting times (unfortunately, early morning for me - ugh). If you have to have an 8am (or 7am or....) meeting, at least bring bagels and coffee or something. And don't schedule lame meetings for that timeframe, because your attendance will suffer even more for the time schedule (in addition to the lameness factor). If I'm an attendee to that early morning meeting, and the alarm goes off, I have a choice.... hit the snooze, or wake up excited to attend the meeting. Unfortunately, my snooze-button is well-warn.
8) Cancel if the right people can't attend. Use those "optional" and "required" tags on your meeting invitations and mean it! If someone is required, and they reject your invitation, find out why and reschedule or address the issue.
9) Don't call all-day meetings unless you have a plan for how to spend the time.
10) Don't forget the remote attendees. I find this difficult; the conference phone is dialed to the conference line and the remote attendees are there, but often the facilitator forgets them, or doesn't include them in the discussion as often as possible. Also - make the communication bandwidth as rich as possible. Use Netmeeting or other conference alternatives to share the desktop with remote participants, and set up a webcam if you can. The more you can do to make the remote attendees feel a part of the meeting, the more valuable participation you'll gain from their attendance.
I could go on. What attributes do you find to be important in meeting effectiveness and efficiency?
1) Facilitated. Note the distinction between this property and "led" or "managed" or "controlled". The person running the meeting has good skills at eliciting input, tracking progress and action items, and keeping everyone engaged.
2) Non-laptop/PDA focused. I can't recount how many meetings I've attended where one or, usually more, attendees have laptops/PDA's open and are focused somewhere else. Yes, I understand multitasking and the demands on our time, and the usefulness of getting things done while sitting in a meeting. The cause and effect here is not always clear, but I submit that if the meeting was well-run, the attendees would be riveted to the discussion topic to the point where they'd forget they were carrying a PDA.
3) Accomplishment-bound instead of time-bound. Meetings fill the time they are allotted. If you have 26 minutes worth of productive discussion, don't keep the meeting going to fill the whole hour you reserved. Keep focused, accomplish your objective, and release folks early to go do their email.
4) Speaking of objectives.... HAVE ONE! In agile, we talk about having "acceptance criteria" for story completion. We should adopt the same approach to meeting management. An agenda would be nice too - for more formal meetings - but I don't think it's always necessary.
5) Take issues offline. This is easy for an effective facilitator to drive, but is not done nearly enough.
6) Determine if a meeting is the right approach to accomplishing your objective. I was a participant in a weekly meeting for a couple of months for which the only agenda item was to go through an action item list and report status. I stopped going. So did many others. Fortunately, the organizer(s) got the message and canceled it. We can easily update a wiki as needed to update status. If folks have questions, walk over to the other person's office and talk in person.
7) Find a good time for the meeting. I know that cross-oceanic teams sometimes necessitate bizarre meeting times (unfortunately, early morning for me - ugh). If you have to have an 8am (or 7am or....) meeting, at least bring bagels and coffee or something. And don't schedule lame meetings for that timeframe, because your attendance will suffer even more for the time schedule (in addition to the lameness factor). If I'm an attendee to that early morning meeting, and the alarm goes off, I have a choice.... hit the snooze, or wake up excited to attend the meeting. Unfortunately, my snooze-button is well-warn.
8) Cancel if the right people can't attend. Use those "optional" and "required" tags on your meeting invitations and mean it! If someone is required, and they reject your invitation, find out why and reschedule or address the issue.
9) Don't call all-day meetings unless you have a plan for how to spend the time.
10) Don't forget the remote attendees. I find this difficult; the conference phone is dialed to the conference line and the remote attendees are there, but often the facilitator forgets them, or doesn't include them in the discussion as often as possible. Also - make the communication bandwidth as rich as possible. Use Netmeeting or other conference alternatives to share the desktop with remote participants, and set up a webcam if you can. The more you can do to make the remote attendees feel a part of the meeting, the more valuable participation you'll gain from their attendance.
I could go on. What attributes do you find to be important in meeting effectiveness and efficiency?
Saturday, October 21, 2006
Cram First
CRAM First
CRAM is an acronym that represents a model for dealing with workplace performance. I first heard it in business school – in my Managing People and Organizations class. It resonated with me at the time and has endured the test of time: 7 years beyond graduation. How much do you remember that long after school finishes?
The natural reaction to underperformance of a team member is to blame it on motivation. “He’s lazy” or “She’s just not applying herself.” While this reaction may be accurate, there may be other more substantial issues that render the motivation issue irrelevant. This model can help to “peel the onion” to find more basic issues related to performance.
To the point: C = Constraints; R = Resources; A = Aptitude; M = Motivation. Think of these as cascading (or – like Maslow’s hierarchy of needs – a pyramid).
Constraints: I have been divorced twice. The first time I got separated, I was working at IBM on mainframe operating system development. I was on an elite team doing cutting edge development – writing software that translates service-level-agreement objectives into algorithms that adjust resource allocation within the system to achieve performance objectives. It was complex work and demanded a great deal of concentration.
When my personal life took a dive, I would – literally – sit in front of the computer screen and stare at it. I felt like a zombie. Though I knew that I was falling behind, I didn’t want to – no, that’s not right – I didn’t care about raising a flag to indicate that I was in trouble. I’m sure I experienced aspects of clinical depression. I finally spoke to my manager. He moved me onto a less complex part of the project, where I flourished. I was fortunate that my prior performance provided evidence of my capability, so my manager was able to understand the impact of my personal issues.
So ask me – was I motivated? I don’t know. I didn’t care. My issues were more foundational – my motivation was irrelevant. Ask a homeless person if they are working on self-actualization.
Resources: In this day and age, why doesn’t every developer have a big flat-screen monitor on which to work? Why don’t they have 2-gig systems (or more) with dual-core multiprocessors to speed their work? Understand that the more lag time there is between tasks, the more start/stop energy that gets expended by thrashing. If my build takes 4 minutes, and I start looking at cnn.com in the meantime, I’m losing my concentration. Nobody can be expected to maintain concentration over this time.
I run meetings where I need a projector. Management decides to purchase one projector to share among 50 people – to save money. Consider that I’m costing you $150 an hour… so every 10 minutes I spend hunting down, or reserving the projector costs you $25. Moreover, I’m losing concentration on the tasks I could have been performing.
Administrative assistants provide incredible leverage for productivity. I spent an hour recently reserving rooms for a recurring daily meeting using a terrible Lotus Notes conference room scheduling implementation. You can hire great administrative assistants to do this at a much lower cost. Think of me (and other high-tech workers) as expensive pieces of machinery in your manufacturing plant. To optimize your profit, you need to keep your expensive pieces of machinery at optimum capacity. Don’t eschew paying $50 an hour for a maintenance person who keeps a $1,000 per hour piece of machinery humming.
Aptitude: I had a good friend/colleague at IBM once who was extremely bright. He had (presumably still has) a quick wit, a great attitude, and could solve some complex problems with ease. He had a master’s degree in Mathematics. Unfortunately, he was working as a programmer. He wasn’t a great programmer. He was eventually managed out of the company. To this day, it bothers me. I was his team leader, but I was young and had no leadership sense. I was timid. I wanted to get along – climb the IBM corporate ladder – become CEO someday. My friend was not a poor employee; his best skills were simply not being leveraged. He would have been an outstanding software performance analyst. To this day, when faced with seemingly incompetent people, my experience tells me to look for where the aptitude lies. That person may not be shining in his current role, but may be brilliant in other areas. Let’s find the areas where we can all be brilliant.
Motivation: Some people are lazy, unmotivated – whatever. There are reams of books on motivating people – particularly in the sales arena. I’m sure some of these tactics work. But motivation is irrelevant when deeper issues exist. Don’t be lazy in managing these individuals. Figure out if there are more foundational issues to address before giving your next motivational speech. CRAM first; motivate later.
CRAM is an acronym that represents a model for dealing with workplace performance. I first heard it in business school – in my Managing People and Organizations class. It resonated with me at the time and has endured the test of time: 7 years beyond graduation. How much do you remember that long after school finishes?
The natural reaction to underperformance of a team member is to blame it on motivation. “He’s lazy” or “She’s just not applying herself.” While this reaction may be accurate, there may be other more substantial issues that render the motivation issue irrelevant. This model can help to “peel the onion” to find more basic issues related to performance.
To the point: C = Constraints; R = Resources; A = Aptitude; M = Motivation. Think of these as cascading (or – like Maslow’s hierarchy of needs – a pyramid).
Constraints: I have been divorced twice. The first time I got separated, I was working at IBM on mainframe operating system development. I was on an elite team doing cutting edge development – writing software that translates service-level-agreement objectives into algorithms that adjust resource allocation within the system to achieve performance objectives. It was complex work and demanded a great deal of concentration.
When my personal life took a dive, I would – literally – sit in front of the computer screen and stare at it. I felt like a zombie. Though I knew that I was falling behind, I didn’t want to – no, that’s not right – I didn’t care about raising a flag to indicate that I was in trouble. I’m sure I experienced aspects of clinical depression. I finally spoke to my manager. He moved me onto a less complex part of the project, where I flourished. I was fortunate that my prior performance provided evidence of my capability, so my manager was able to understand the impact of my personal issues.
So ask me – was I motivated? I don’t know. I didn’t care. My issues were more foundational – my motivation was irrelevant. Ask a homeless person if they are working on self-actualization.
Resources: In this day and age, why doesn’t every developer have a big flat-screen monitor on which to work? Why don’t they have 2-gig systems (or more) with dual-core multiprocessors to speed their work? Understand that the more lag time there is between tasks, the more start/stop energy that gets expended by thrashing. If my build takes 4 minutes, and I start looking at cnn.com in the meantime, I’m losing my concentration. Nobody can be expected to maintain concentration over this time.
I run meetings where I need a projector. Management decides to purchase one projector to share among 50 people – to save money. Consider that I’m costing you $150 an hour… so every 10 minutes I spend hunting down, or reserving the projector costs you $25. Moreover, I’m losing concentration on the tasks I could have been performing.
Administrative assistants provide incredible leverage for productivity. I spent an hour recently reserving rooms for a recurring daily meeting using a terrible Lotus Notes conference room scheduling implementation. You can hire great administrative assistants to do this at a much lower cost. Think of me (and other high-tech workers) as expensive pieces of machinery in your manufacturing plant. To optimize your profit, you need to keep your expensive pieces of machinery at optimum capacity. Don’t eschew paying $50 an hour for a maintenance person who keeps a $1,000 per hour piece of machinery humming.
Aptitude: I had a good friend/colleague at IBM once who was extremely bright. He had (presumably still has) a quick wit, a great attitude, and could solve some complex problems with ease. He had a master’s degree in Mathematics. Unfortunately, he was working as a programmer. He wasn’t a great programmer. He was eventually managed out of the company. To this day, it bothers me. I was his team leader, but I was young and had no leadership sense. I was timid. I wanted to get along – climb the IBM corporate ladder – become CEO someday. My friend was not a poor employee; his best skills were simply not being leveraged. He would have been an outstanding software performance analyst. To this day, when faced with seemingly incompetent people, my experience tells me to look for where the aptitude lies. That person may not be shining in his current role, but may be brilliant in other areas. Let’s find the areas where we can all be brilliant.
Motivation: Some people are lazy, unmotivated – whatever. There are reams of books on motivating people – particularly in the sales arena. I’m sure some of these tactics work. But motivation is irrelevant when deeper issues exist. Don’t be lazy in managing these individuals. Figure out if there are more foundational issues to address before giving your next motivational speech. CRAM first; motivate later.
Subscribe to:
Comments (Atom)
