The (Im)Perfect Manager had a job hunt followed by a job find followed by several personal items coming to pass at the same time; I will have a bonus blog with the product of my labors coming up. My apologies for not noting it here on the blog. I expect the blog to resume in June, which is easy to say, but easy to enforce through guilt to myself to actually do it.
Thanks, so much, for reading (if you still are).
Friday, May 25, 2012
Wednesday, April 25, 2012
Don't Kill The Idiots
There are too many of them and not enough of you. Also, idiocy is typically a temporary condition for most people.
The basic concept to take away from this post is don't talk/email/interact with people when you are out of sorts and/or out of control. I know, way easier to say than to do (but hard to type, what with all the slashes (/).
Also, use your eyes, ears, and gut to notice things like major mood swing issues with others. People who are angry or upset are clenched up; rarely are they relaxed in demeanor. Some get very quiet, others get very shrill. You can tell after talking to someone a few minutes that maybe they're not at their best.
Recommendation: walk away.
You don't want them killing you for being an idiot, either.
This is all pretty basic advice: most people know not to poke the angry beast when the angry beast is being angry. Which is why noticing when you are the angry beast--the first part of this blog post--is a skill to hone.
Get grumpy when you don't eat or don't get that first cup of coffee? Don't talk to people about controversial subjects (or at all if you can avoid it), until those hurdles have been leaped. Low blood sugar and caffeine addiction are reasons for bad behavior; they do not erase it or excuse it. If a co-worker felt the need to blast your head off for saying "Good morning," to him or her, you're probably not going to feel charitable towards them if your head could have remained in place had they but eaten their breakfast bar.
A lot of issues regarding anger/fear/anxiety/upset in the work place are specific to physical conditions of the body. You could be really tired, really hungry, crashing from sugar, jonesing for caffeine, or if you're particularly a braniac, you could be recovering from a hangover. All of these are conditions that have been brought on by yourself, the same way that a driver who loses control of a car because of a faulty tire is to blame: it's the driver's JOB to make sure the vehicle is safe to operate, and its your job to make sure you are safe to be around other people.
Now you may have a baby at home, which is what is killing your ability to sleep; you could blame the baby for your lack of sleep, or your wife for sleeping because it was your turn to cope with baby last night. However, its not really anyone's fault here: you made a choice to participate in the raising of a beautiful, awesome creature that hasn't figured out the concept of a schedule yet. Your co-workers did not get consulted about that. First, that would be weird, and second, they don't expect to be. But they do expect you to perform as well as you did before the kid came along, with a few exceptions because they are not heartless automatons, and some of them probably have kids, too.
So if you're prone to bouts of unreasonableness when you're tired, they will put up with a bit of it--kids are awesome and they are a lot of work--but you never want to push them too far on that. This may mean mini-naps at lunchtime for you, or napping instead of your normal decompression when you get home (when you can, as baby and family life permits). This may mean--if you aren't nursing--consuming more caffeine than you might otherwise to keep the peace.
Whatever you do, be AWARE. You may need to make a note for yourself related to physical conditions and keep it on your monitor or tacked to your phone to remind you that the guy you're talking to on the phone might not actually be a moron, it might be that you're in a bit of a pissy mood. Also, regardless of mood, never treat anyone like a complete moron. You might be right, but the workplace rarely rewards people for calling out complete morons. Someone had to hire that moron. They might not enjoy you pointing out their mistake.
The second big reason you could try/want to kill the idiots is mood related to emotional context. You come into work having narrowly avoided an accident caused by someone talking on their cell, then run into a co-worker talking on his cell, there is a temptation to lash out. Needless to say, DON'T. Easy to say, by the way. Hard to realize that you might be in an altered state due to emotional issues going on.
Have a sick kid at home? Buying a house? Managing a promotion? Comforting a friend whose loved one has died? These all eat up energy from you. The less energy you have, the more likely you are to turn evil at a moment's notice.
So, question what comes out of your mouth, before it comes out of your mouth. Is it polite? Is it emotional? If its emotional, where is the emotion coming from? Note, some people NEVER MASTER THIS SKILL. There is a disconnect between their ability to filter and their brain. Many of them are hilarious. Many of them are never going to get terribly far, depending on their career of choice.
In summary, question yourself before you question other people. Preferably in your head. Despite Gizmodo's recent article about talking to yourself making you smarter (and not actually crazy), many people are still hung up on the crazy part. Also, unfiltered external dialog is a lot like leaving TNT lying around for the cat to play with: generally a bad idea. You never know who will over hear you. You also don't know who the person you are talking to today will be tomorrow; a simple kindness (such as rushing for coffee before having a quick morning discussion), could make or break someone's impression of you, and those impressions have long lives in the increasingly cozy career world where someone who was your co-worker yesterday is your boss tomorrow.
The basic concept to take away from this post is don't talk/email/interact with people when you are out of sorts and/or out of control. I know, way easier to say than to do (but hard to type, what with all the slashes (/).
Also, use your eyes, ears, and gut to notice things like major mood swing issues with others. People who are angry or upset are clenched up; rarely are they relaxed in demeanor. Some get very quiet, others get very shrill. You can tell after talking to someone a few minutes that maybe they're not at their best.
Recommendation: walk away.
You don't want them killing you for being an idiot, either.
This is all pretty basic advice: most people know not to poke the angry beast when the angry beast is being angry. Which is why noticing when you are the angry beast--the first part of this blog post--is a skill to hone.
Get grumpy when you don't eat or don't get that first cup of coffee? Don't talk to people about controversial subjects (or at all if you can avoid it), until those hurdles have been leaped. Low blood sugar and caffeine addiction are reasons for bad behavior; they do not erase it or excuse it. If a co-worker felt the need to blast your head off for saying "Good morning," to him or her, you're probably not going to feel charitable towards them if your head could have remained in place had they but eaten their breakfast bar.
A lot of issues regarding anger/fear/anxiety/upset in the work place are specific to physical conditions of the body. You could be really tired, really hungry, crashing from sugar, jonesing for caffeine, or if you're particularly a braniac, you could be recovering from a hangover. All of these are conditions that have been brought on by yourself, the same way that a driver who loses control of a car because of a faulty tire is to blame: it's the driver's JOB to make sure the vehicle is safe to operate, and its your job to make sure you are safe to be around other people.
Now you may have a baby at home, which is what is killing your ability to sleep; you could blame the baby for your lack of sleep, or your wife for sleeping because it was your turn to cope with baby last night. However, its not really anyone's fault here: you made a choice to participate in the raising of a beautiful, awesome creature that hasn't figured out the concept of a schedule yet. Your co-workers did not get consulted about that. First, that would be weird, and second, they don't expect to be. But they do expect you to perform as well as you did before the kid came along, with a few exceptions because they are not heartless automatons, and some of them probably have kids, too.
So if you're prone to bouts of unreasonableness when you're tired, they will put up with a bit of it--kids are awesome and they are a lot of work--but you never want to push them too far on that. This may mean mini-naps at lunchtime for you, or napping instead of your normal decompression when you get home (when you can, as baby and family life permits). This may mean--if you aren't nursing--consuming more caffeine than you might otherwise to keep the peace.
Whatever you do, be AWARE. You may need to make a note for yourself related to physical conditions and keep it on your monitor or tacked to your phone to remind you that the guy you're talking to on the phone might not actually be a moron, it might be that you're in a bit of a pissy mood. Also, regardless of mood, never treat anyone like a complete moron. You might be right, but the workplace rarely rewards people for calling out complete morons. Someone had to hire that moron. They might not enjoy you pointing out their mistake.
The second big reason you could try/want to kill the idiots is mood related to emotional context. You come into work having narrowly avoided an accident caused by someone talking on their cell, then run into a co-worker talking on his cell, there is a temptation to lash out. Needless to say, DON'T. Easy to say, by the way. Hard to realize that you might be in an altered state due to emotional issues going on.
Have a sick kid at home? Buying a house? Managing a promotion? Comforting a friend whose loved one has died? These all eat up energy from you. The less energy you have, the more likely you are to turn evil at a moment's notice.
So, question what comes out of your mouth, before it comes out of your mouth. Is it polite? Is it emotional? If its emotional, where is the emotion coming from? Note, some people NEVER MASTER THIS SKILL. There is a disconnect between their ability to filter and their brain. Many of them are hilarious. Many of them are never going to get terribly far, depending on their career of choice.
In summary, question yourself before you question other people. Preferably in your head. Despite Gizmodo's recent article about talking to yourself making you smarter (and not actually crazy), many people are still hung up on the crazy part. Also, unfiltered external dialog is a lot like leaving TNT lying around for the cat to play with: generally a bad idea. You never know who will over hear you. You also don't know who the person you are talking to today will be tomorrow; a simple kindness (such as rushing for coffee before having a quick morning discussion), could make or break someone's impression of you, and those impressions have long lives in the increasingly cozy career world where someone who was your co-worker yesterday is your boss tomorrow.
Tuesday, April 17, 2012
Once More Into the Breach, Thoughts on Job Seeking and Interviewing: Doing Your Homework
So, you've contacted friends and they've kindly passed on your resume. You've hit the job boards and applied to anything that looked remotely like you could do it. Recruiters are actually calling you.
The way the current job market manages hiring is a multiple step process:
1) Your resume gets through the slush pile to someone who thinks you can do the job/might be a good fit.
2) This person (or someone in their org) contacts you about a phone screen.
3) You agree to a phone screen and schedule one.
4) You do the initial 'is this person insane/lying to me' dance of the first phone screen.
5) You pass! They ask to schedule another phone screen and/or they ask you to come in for an in-person interview (9 times out of 10 it's another phone screen)
6) You pass the phone screens/initial in-person interview! They schedule you for at least one more interview.
7) It is now down to you and whomever else has passed these hurdles (Typically 5 or fewer applicants)
8) You do or do not get the job
9) They notify you, typically via email if you didn't get it, by phone if you did
10) If you got it, you discuss rates, vacation time, contract length...whatever is pertinent to the gig.
Let's break this down.
(1) I've covered in an earlier blog on resumes; everyone has what they like, I have what I like. Check it out - there are comments from other managers indicating their preferences to get resumes through the slush pile, as well.
You schedule a phone screen (3). I'm going to state the obvious here, but bear with me: if you are currently employed do not do the phone screen on the time of the company for whom you still work. Do it on a lunch break or after or before work. I'm generally okay if you are a contractor and no one else is using that room during the time, in scheduling time in a conference room over lunch to do the interview. If you are a permanent employee, its up to you whether you feel comfortable doing that or if you want to take the call outside/in the cover of the stairwell/whatever.
The first phone screen is usually not the person who can make a hiring decision. However, it is the person who gets to decide if you get anywhere NEAR the person who makes the hiring decision. Also, you never really know who you are talking to; I've done an initial phone screen with the CEO of a company because she was managing HR while the HR director was out at the start up where I was interviewing. This person may seem like the first obstacle on your path to this job, but really, they're the first person who can remove that obstacle for you. BE NICE.
Before you even talk to them, if I have a name, I Google it to get a better idea of whom I am speaking to. I wouldn't immediately drop the name of their dogs or ask them how their kids are doing when you talk to them--that sort of escalates to stalking and will definitely get you banned from moving forward with that company--but it does mean if you also like dogs, bringing them up is probably a safe concept. If you have kids, it might also be a safe area for small talk. Read carefully though; no one wants to talk about dogs when Betsy, their baby, passed away Tuesday. The emotional mood of the person with whom you are talking will influence their opinion of you (whether they think so or want it to or not). So try to keep them positive, talk about things they like, and to do that, you need to look them up.
You also need to look up the company. I've screened a lot of people who had never even glanced at the website. When asked what they thought we did, the number of "ums" was in the hundreds. Don't be the person "umming" their way through this part of the interview. Read about the company. TAKE NOTES. Write down the name, what they're famous for/main product is, find out where they are (so you aren't asking that embarrassing question in the interview when you could have found out yourself), and anything of interest on their "breaking news" or "marketing" division sites. Companies like it if you can a) spit their buzzwords out at them and b) know what they mean. So, look up anything you don't understand. For example, I've been in tech for wow, 20 years now, and I can NEVER remember what SaaS means. For the record, it's "Software as a service." Enjoy your acronym.
Finally, look over the job description to which you applied again. Make sure you understand those acronyms. Review the expected job experience and requirements. Prepare stories of the times you did those things--or things like them--at other companies if the question comes up. If you are shy required experience and you got the screen anyway, there's something they value in you, so prep for why that lack of experience is not a drawback/how you will get caught up/how you have it in this other way/etc.
Take your notes, the open job description, and a copy of your resume and have them with you when you do the phone screen. Try to keep answers positive; if you don't know something, that's okay, just answer how you'd find out (or how you've handled a situation in the past with a positive ending).
Traditionally the initial screeners aren't going to go for the throat--they may just be making sure that if you wrote "Agile/Scrum" experience on your resume you know what an Iteration is and what a daily stand up means. But sometimes they will. Be prepared.
I recommend against having a computer in front of you, other than for data that is already up on the screen (such as their website). People can hear you typing when you talk to them, and phone screeners are not stupid when there are short delays between asking a question and getting an answer. No searching the internet for stuff you're supposed to know once you're on the phone, unless you're explaining every step of the search process to the person on the phone and why you're doing it. And even then, avoid it.
I like to interview people about the job, just as much as I want to put my best foot forward in being interviewed. One of the ways I do this, as noted in a previous blog post, is to ask what people like about the job themselves; it tells you a lot. It also typically puts the interviewer in a good mood because you've asked about something positive. Every little bit of good mood while you are present helps in the interview process.
After the interview is over, you're likely to receive an email about next steps (or a "thank you but no thank you" typically in email form). I like to respond to that thanking the interviewer for their time, expressing interest in the upcoming interview, and if the upcoming interview is an in person interview, asking a little about the dress code at the company.
Do all the same prep for (6) again about a half hour before the interview. If it's an in-person interview, prepare to kill some trees. I like to bring at least two copies of my resume, a copy of the job description, my notes, a copy of the email thread or written notes for the name/contact info of the first call, and directions on how to get there. I like to review all this before I leave for the interview.
If they do not expressly say "jeans" in the reply email about the interview, or do not provide any information about normal company dress policy, slacks (for men) and slacks or skirt for women are the best option. For men I recommend a button up shirt, buttoned to the top, slacks (that are not part of a matching suit, but still nice), and a jacket (again, not part of a matching suit). In this way if it turns out you're over dressed, you can take off the jacket and unbutton a few buttons. For women, a utility dress--that can be dressed up with a jacket and jewelry--or slacks/skirt and blouse that can be dressed up or down with a jacket or scarf, is the equivalent. Something that can be upped if you need to look nicer with accessories from your purse, or that can easily be taken off to get you closer to what your interviewers are wearing. You want to look nice, and you want to be memorable, but you also want to play on the fact that people like people who are like them.
Don't lose heart if you have to be interviewed more between options (4) and (6). Depending on the market, there may be a glut of competitors out there, and to weed you out, they'll have everyone they can think of talk to you. Additionally, especially in places where they really need the additional help, they need help because they haven't got time...such as the time needed to hire you to help them. You could do three phone screens and four in-person interviews, or you might get one phone screen and one interview and get the gig. But take heart--unless two weeks pass without word OR you receive the very nice "thank you but no thank you" letter, you're probably still in the running. Just, it's a really long run.
When I find out (7)--that I'm one of the final candidates--I like to send an email to those who have given me their email (I never ask for it, because people worry about that whole "stalking" thing); each on personalized thanking them for their time and letting them know I enjoyed speaking with them...typically, if I can remember something fun we talked about, I will try to recount how awesome it was there. Keep it short--a four sentence paragraph or shorter. Then leave them alone to make the decision.
If a week passes with no word, ping the person responsible for telling you the news with a polite inquiry.
If several weeks pass (and no response to your query), call it done and move on. If they call you back a month later, it's up to you if you still want the gig (depending on your needs, etc.), but if they do that to you during the interview process, what will it be like to work there?
If you do get the gig, you'll probably get a phone call. Thank them profusely. If you haven't already asked about dress code, ask. Get their take on the best commute routes and places to eat locally (or who in the office might help you with that). Talk to them about rates (if you haven't already, which you should have by this time), vacation time, contract length...whatever is pertinent to the gig. Note: a lot of things are negotiable, but companies frequently bank on the reciprocity principle--they're giving you a job so you feel like you owe them--to prevent you from even thinking of asking. But it cannot hurt to ask about a third week of vacation or extra sick leave. As long as you don't threaten to fail to work without those things, the job will still be yours. But if you don't ask for what you're interested in, you certainly won't get it. After all that, thank them again and show up when told.
If you didn't get it, typically you get a very nice email explaining how close you were, but that someone else was just a titch closer.
A lot of people just stop here. DON'T. Instead, send a polite email thanking them so much and letting them know how much you liked everyone you talked to/met. Name names. Ask them to think of you if they have additional openings in the future. Sometimes initial candidates accept and back out, or turn out to be crazy and don't make it through the company's probationary time. Candidates that respond positively, and paid attention, get called back when there are job openings. You want that to be you. And maybe it won't be this time you're hunting, but people remember your good deeds--if you're looking three years from now, it might help you out.
I'm sure I'm sure I'll revisit this topic again, but in summary: be nice to everyone, you never know when it will come back to bite you if you're not, or when it will come back to help you when you are; prep small talk as well as technical and job related skills; do your homework before you talk to people; and don't burn any bridges behind you. The job market may seem vast, but it can be a rather small pool depending on your career choices; you always want people to want to work with you and they talk to each other. Keep that in mind, and you'll soar through this process like a pro.
The way the current job market manages hiring is a multiple step process:
1) Your resume gets through the slush pile to someone who thinks you can do the job/might be a good fit.
2) This person (or someone in their org) contacts you about a phone screen.
3) You agree to a phone screen and schedule one.
4) You do the initial 'is this person insane/lying to me' dance of the first phone screen.
5) You pass! They ask to schedule another phone screen and/or they ask you to come in for an in-person interview (9 times out of 10 it's another phone screen)
6) You pass the phone screens/initial in-person interview! They schedule you for at least one more interview.
7) It is now down to you and whomever else has passed these hurdles (Typically 5 or fewer applicants)
8) You do or do not get the job
9) They notify you, typically via email if you didn't get it, by phone if you did
10) If you got it, you discuss rates, vacation time, contract length...whatever is pertinent to the gig.
Let's break this down.
(1) I've covered in an earlier blog on resumes; everyone has what they like, I have what I like. Check it out - there are comments from other managers indicating their preferences to get resumes through the slush pile, as well.
You schedule a phone screen (3). I'm going to state the obvious here, but bear with me: if you are currently employed do not do the phone screen on the time of the company for whom you still work. Do it on a lunch break or after or before work. I'm generally okay if you are a contractor and no one else is using that room during the time, in scheduling time in a conference room over lunch to do the interview. If you are a permanent employee, its up to you whether you feel comfortable doing that or if you want to take the call outside/in the cover of the stairwell/whatever.
The first phone screen is usually not the person who can make a hiring decision. However, it is the person who gets to decide if you get anywhere NEAR the person who makes the hiring decision. Also, you never really know who you are talking to; I've done an initial phone screen with the CEO of a company because she was managing HR while the HR director was out at the start up where I was interviewing. This person may seem like the first obstacle on your path to this job, but really, they're the first person who can remove that obstacle for you. BE NICE.
Before you even talk to them, if I have a name, I Google it to get a better idea of whom I am speaking to. I wouldn't immediately drop the name of their dogs or ask them how their kids are doing when you talk to them--that sort of escalates to stalking and will definitely get you banned from moving forward with that company--but it does mean if you also like dogs, bringing them up is probably a safe concept. If you have kids, it might also be a safe area for small talk. Read carefully though; no one wants to talk about dogs when Betsy, their baby, passed away Tuesday. The emotional mood of the person with whom you are talking will influence their opinion of you (whether they think so or want it to or not). So try to keep them positive, talk about things they like, and to do that, you need to look them up.
You also need to look up the company. I've screened a lot of people who had never even glanced at the website. When asked what they thought we did, the number of "ums" was in the hundreds. Don't be the person "umming" their way through this part of the interview. Read about the company. TAKE NOTES. Write down the name, what they're famous for/main product is, find out where they are (so you aren't asking that embarrassing question in the interview when you could have found out yourself), and anything of interest on their "breaking news" or "marketing" division sites. Companies like it if you can a) spit their buzzwords out at them and b) know what they mean. So, look up anything you don't understand. For example, I've been in tech for wow, 20 years now, and I can NEVER remember what SaaS means. For the record, it's "Software as a service." Enjoy your acronym.
Finally, look over the job description to which you applied again. Make sure you understand those acronyms. Review the expected job experience and requirements. Prepare stories of the times you did those things--or things like them--at other companies if the question comes up. If you are shy required experience and you got the screen anyway, there's something they value in you, so prep for why that lack of experience is not a drawback/how you will get caught up/how you have it in this other way/etc.
Take your notes, the open job description, and a copy of your resume and have them with you when you do the phone screen. Try to keep answers positive; if you don't know something, that's okay, just answer how you'd find out (or how you've handled a situation in the past with a positive ending).
Traditionally the initial screeners aren't going to go for the throat--they may just be making sure that if you wrote "Agile/Scrum" experience on your resume you know what an Iteration is and what a daily stand up means. But sometimes they will. Be prepared.
I recommend against having a computer in front of you, other than for data that is already up on the screen (such as their website). People can hear you typing when you talk to them, and phone screeners are not stupid when there are short delays between asking a question and getting an answer. No searching the internet for stuff you're supposed to know once you're on the phone, unless you're explaining every step of the search process to the person on the phone and why you're doing it. And even then, avoid it.
I like to interview people about the job, just as much as I want to put my best foot forward in being interviewed. One of the ways I do this, as noted in a previous blog post, is to ask what people like about the job themselves; it tells you a lot. It also typically puts the interviewer in a good mood because you've asked about something positive. Every little bit of good mood while you are present helps in the interview process.
After the interview is over, you're likely to receive an email about next steps (or a "thank you but no thank you" typically in email form). I like to respond to that thanking the interviewer for their time, expressing interest in the upcoming interview, and if the upcoming interview is an in person interview, asking a little about the dress code at the company.
Do all the same prep for (6) again about a half hour before the interview. If it's an in-person interview, prepare to kill some trees. I like to bring at least two copies of my resume, a copy of the job description, my notes, a copy of the email thread or written notes for the name/contact info of the first call, and directions on how to get there. I like to review all this before I leave for the interview.
If they do not expressly say "jeans" in the reply email about the interview, or do not provide any information about normal company dress policy, slacks (for men) and slacks or skirt for women are the best option. For men I recommend a button up shirt, buttoned to the top, slacks (that are not part of a matching suit, but still nice), and a jacket (again, not part of a matching suit). In this way if it turns out you're over dressed, you can take off the jacket and unbutton a few buttons. For women, a utility dress--that can be dressed up with a jacket and jewelry--or slacks/skirt and blouse that can be dressed up or down with a jacket or scarf, is the equivalent. Something that can be upped if you need to look nicer with accessories from your purse, or that can easily be taken off to get you closer to what your interviewers are wearing. You want to look nice, and you want to be memorable, but you also want to play on the fact that people like people who are like them.
Don't lose heart if you have to be interviewed more between options (4) and (6). Depending on the market, there may be a glut of competitors out there, and to weed you out, they'll have everyone they can think of talk to you. Additionally, especially in places where they really need the additional help, they need help because they haven't got time...such as the time needed to hire you to help them. You could do three phone screens and four in-person interviews, or you might get one phone screen and one interview and get the gig. But take heart--unless two weeks pass without word OR you receive the very nice "thank you but no thank you" letter, you're probably still in the running. Just, it's a really long run.
When I find out (7)--that I'm one of the final candidates--I like to send an email to those who have given me their email (I never ask for it, because people worry about that whole "stalking" thing); each on personalized thanking them for their time and letting them know I enjoyed speaking with them...typically, if I can remember something fun we talked about, I will try to recount how awesome it was there. Keep it short--a four sentence paragraph or shorter. Then leave them alone to make the decision.
If a week passes with no word, ping the person responsible for telling you the news with a polite inquiry.
If several weeks pass (and no response to your query), call it done and move on. If they call you back a month later, it's up to you if you still want the gig (depending on your needs, etc.), but if they do that to you during the interview process, what will it be like to work there?
If you do get the gig, you'll probably get a phone call. Thank them profusely. If you haven't already asked about dress code, ask. Get their take on the best commute routes and places to eat locally (or who in the office might help you with that). Talk to them about rates (if you haven't already, which you should have by this time), vacation time, contract length...whatever is pertinent to the gig. Note: a lot of things are negotiable, but companies frequently bank on the reciprocity principle--they're giving you a job so you feel like you owe them--to prevent you from even thinking of asking. But it cannot hurt to ask about a third week of vacation or extra sick leave. As long as you don't threaten to fail to work without those things, the job will still be yours. But if you don't ask for what you're interested in, you certainly won't get it. After all that, thank them again and show up when told.
If you didn't get it, typically you get a very nice email explaining how close you were, but that someone else was just a titch closer.
A lot of people just stop here. DON'T. Instead, send a polite email thanking them so much and letting them know how much you liked everyone you talked to/met. Name names. Ask them to think of you if they have additional openings in the future. Sometimes initial candidates accept and back out, or turn out to be crazy and don't make it through the company's probationary time. Candidates that respond positively, and paid attention, get called back when there are job openings. You want that to be you. And maybe it won't be this time you're hunting, but people remember your good deeds--if you're looking three years from now, it might help you out.
I'm sure I'm sure I'll revisit this topic again, but in summary: be nice to everyone, you never know when it will come back to bite you if you're not, or when it will come back to help you when you are; prep small talk as well as technical and job related skills; do your homework before you talk to people; and don't burn any bridges behind you. The job market may seem vast, but it can be a rather small pool depending on your career choices; you always want people to want to work with you and they talk to each other. Keep that in mind, and you'll soar through this process like a pro.
Tuesday, April 10, 2012
Failure is not only an option, its sometimes the required option
I work with a friend who doesn't like to screw up. As someone who also doesn't like to screw up, I'm down with that. However, this person wants to be a lead, which is a type of manager, and if you've never screwed up, when you become a lead, screwing up is a) inevitable and b) freakier than hell if you've never done it before.
Unlike code or sofas that will take whatever you or your cats do to them (spoken as a woman whose cat almost succeeded in editing the registry of her husband's laptop with the power of a sunbeam and her butt), with people there is always, always, always, a wrong answer.
I've talked in previous posts about the fact that some people may have a bad day and that can affect their performance and interaction. Sometimes people are ignorant, as well--they've never encountered whatever and just don't know the pitfalls. Sometimes people are scared, and they hide that by puffing up and digging in. Whatever the reason, people are the part of the equation that makes managing fail (as well as succeed). You will do something wrong. You will do something perceived to be wrong. You will FAIL at something. Someone who works for you will FAIL and you'll wonder where you failed. Basically, failure is a part of life, yes, but it's a bigger part of your life if you're responsible for anyone (like a team) or anything (like a project).
To steal from the remade Batman franchise: "Why do we fall? So we can learn how to get up." I'd not go so far as to fall down a well and be attacked by frightened bats trying to escape from you, but its basically true: you fell on your butt several times before you learned your balance to walk. You may have skinned your knees a bit getting the hang of the bike. Hopefully the dents in the car were invisible or hideable from your parents when you were learning to drive. And I dearly hope the person or persons you love have forgiven you for that time when you (insert the incident in question that was definitively a mistake).
Management is a lot like that. When you are a manager, people expect that you will not screw up, so the pressure is even worse.
What I'm here to tell you is that: a) you will screw up, b) its okay if you screw up as long as you c) handle the screw up properly.
I've talked in previous entries about handling personnel issues; I have a few posts on "Screw Ups Happen." What this is about is to clarify that there is a purpose to failing, even in management, and that is to learn from the failure. Many of us want to just bury it and move on, but the truth of the matter is 99% of the time the failure is somehow connected to other humans (I'm assuming robots for that other 1%, but don't quote me). You need to know how that failure happened for yourself, so it doesn't happen again.
And, as I noted in my article on the Blame Game, I don't mean "who did this" but "what part did I play in this?" When folks you manage fail, you fail. When you're connected to a project with a failure, there is typically something you can learn so that a project you work on doesn't fail in the same way again.
Failure, therefore, is not only an option, it's sometimes required.
This is not to say that you should run right out and start screwing things up for learning opportunities. Trust me, failure will find you and yours all its own, without having to invite it in. Also, your manager generally frowns on you encouraging failure as what she/he pays you for is quite the opposite.
When a failure or potential failure comes up--from a comment that got your back up to a full fledged missed deadline--go somewhere private and react to what happened as you need to do so. Don't be self indulgent (it's not all day thing), but its normal and human to react, and its best not to react where normal humans can see you, as how you react will often guide how your team reacts. You want to, whenever possible, be calm and prepared for them, so they can be calm and prepared in return.
After you've reacted, do your clean up; I have lots of great advice in my Blame Game column and my Screw Ups Happen columns.
After you've done your clean up, go do something completely different and rest your brain. Come back the next day to review the failure itself.
Now look at what happened and ask yourself:
No one likes to fail. The desire to avoid failure frequently spawns fear which can be harnessed into good things like planning. But you will fail. Probably at least big time once in your life. Not only do you need to get yourself up, dust yourself off, and get back to whatever you were doing, you also need to know how to take a critical eye to the failure in question and learn from it. This is the huge divider between those who can lead well, and those who are lead (but may be put in leadership positions): they take experience in whatever form it may come, and they use it effectively.
Unlike code or sofas that will take whatever you or your cats do to them (spoken as a woman whose cat almost succeeded in editing the registry of her husband's laptop with the power of a sunbeam and her butt), with people there is always, always, always, a wrong answer.
I've talked in previous posts about the fact that some people may have a bad day and that can affect their performance and interaction. Sometimes people are ignorant, as well--they've never encountered whatever and just don't know the pitfalls. Sometimes people are scared, and they hide that by puffing up and digging in. Whatever the reason, people are the part of the equation that makes managing fail (as well as succeed). You will do something wrong. You will do something perceived to be wrong. You will FAIL at something. Someone who works for you will FAIL and you'll wonder where you failed. Basically, failure is a part of life, yes, but it's a bigger part of your life if you're responsible for anyone (like a team) or anything (like a project).
To steal from the remade Batman franchise: "Why do we fall? So we can learn how to get up." I'd not go so far as to fall down a well and be attacked by frightened bats trying to escape from you, but its basically true: you fell on your butt several times before you learned your balance to walk. You may have skinned your knees a bit getting the hang of the bike. Hopefully the dents in the car were invisible or hideable from your parents when you were learning to drive. And I dearly hope the person or persons you love have forgiven you for that time when you (insert the incident in question that was definitively a mistake).
Management is a lot like that. When you are a manager, people expect that you will not screw up, so the pressure is even worse.
What I'm here to tell you is that: a) you will screw up, b) its okay if you screw up as long as you c) handle the screw up properly.
I've talked in previous entries about handling personnel issues; I have a few posts on "Screw Ups Happen." What this is about is to clarify that there is a purpose to failing, even in management, and that is to learn from the failure. Many of us want to just bury it and move on, but the truth of the matter is 99% of the time the failure is somehow connected to other humans (I'm assuming robots for that other 1%, but don't quote me). You need to know how that failure happened for yourself, so it doesn't happen again.
And, as I noted in my article on the Blame Game, I don't mean "who did this" but "what part did I play in this?" When folks you manage fail, you fail. When you're connected to a project with a failure, there is typically something you can learn so that a project you work on doesn't fail in the same way again.
Failure, therefore, is not only an option, it's sometimes required.
This is not to say that you should run right out and start screwing things up for learning opportunities. Trust me, failure will find you and yours all its own, without having to invite it in. Also, your manager generally frowns on you encouraging failure as what she/he pays you for is quite the opposite.
When a failure or potential failure comes up--from a comment that got your back up to a full fledged missed deadline--go somewhere private and react to what happened as you need to do so. Don't be self indulgent (it's not all day thing), but its normal and human to react, and its best not to react where normal humans can see you, as how you react will often guide how your team reacts. You want to, whenever possible, be calm and prepared for them, so they can be calm and prepared in return.
After you've reacted, do your clean up; I have lots of great advice in my Blame Game column and my Screw Ups Happen columns.
After you've done your clean up, go do something completely different and rest your brain. Come back the next day to review the failure itself.
Now look at what happened and ask yourself:
- What actually happened?
- How did it get to this point?
- Can I make a guess at the motivations of the other people involved who made the initial request or requests that led to this?
- What do I know now that I didn't know before this happened?
- can I make it part of my normal routine to learn what I know now that I didn't know then (if humanly possible; no one expects you to anticipate Earthquakes or the invention of actual cold fusion)?
- What are the best take-aways from this failure that aren't self-deprecating?
No one likes to fail. The desire to avoid failure frequently spawns fear which can be harnessed into good things like planning. But you will fail. Probably at least big time once in your life. Not only do you need to get yourself up, dust yourself off, and get back to whatever you were doing, you also need to know how to take a critical eye to the failure in question and learn from it. This is the huge divider between those who can lead well, and those who are lead (but may be put in leadership positions): they take experience in whatever form it may come, and they use it effectively.
Tuesday, April 3, 2012
Servant Leadership: Sometimes it's less good to be the king
Mel Brooks once said many things (and is still saying them, the guy is a riot). The applicable saying here, copied by Ash in Army of Darkness is, "It's good to be the king."
Being a manager, however, is sadly not being a king. Honestly, you don't even get to be consort or princess or court jester. You're pretty much a Knight Errant, running around saving people from dragons and making sure the honest every day folks get what they need in terms of food, seeds, protection, etc.
I see being a manager as being the person who makes it easier/possible for the people you manage to do their jobs. In Agile, this is called Servant Leadership. It's not 'My Team' when you talk, it's "Our Team" or "The Team." You do not succeed as a manager, the team succeeds. Mind you, when the team succeeds you, too, succeed, but you never can claim their victories as yours alone. People see through that, it causes problems with the team, and generally it's just kind of a dick move all together.
As I noted in my first ever blog entry, my father thinks you can get ahead by climbing over bodies or by having people lift you up. Servant leadership counts on you being lifted up by people willing to work with you again and again. It is not what most people think of when they think of "the boss." Typically they may see themselves in an office with a great view, telling people what to do, and, if they think further than that, giving reports and presentations to other admiring and astonished folks.
Now, don't get me wrong, some folks to whom you give presentations will be astonished, but often not for the reasons you'd like them to be. Maybe they want more from the presentation, or less, or a different presentation all together. This involves a lot of talking, taking time in meetings, and extra work. This is the exact type of thing that a manager protects you from...and you're becoming someone else's manager where you'll be doing lots, and lots more of this to protect the time and efficiency of the folks with whom you work.
The world your manager manages--project manager, scrum master, boss, etc.--includes people who don't like things or like things a lot...either way translating into a lot of information coming in to manage and potential work. Those managers keep schedules and employees on track, and they do it by standing between all the various sources of potential distraction. Being a manager can often mean one less level of shielding of that for yourself + all the duties and obligations of shielding the folks that you manage.
What this translates to, in practical terms, is not giving anyone orders. It does mean TAKING ORDERS from the team, in a manner of speaking. It involves regular meetings with the team if you are a direct boss (at least once a week if possible, for a scheduled half hour, though less is fine). It doesn't just involve asking what people need help with, either. It involves taking an interest in their work life and a little in their personal life (nothing that will get HR after you, but it is nice if you can remember the names of their kids). In this way you can talk about what they're doing and FIND issues where they need help. Folks often don't realize help is available, want to "figure things out on their own" when maybe they cannot, and may not realize they need help unless they are talking to someone regularly about their work.
Taking from those meetings--formal and informal--what the folks on the team need, you now have to fill the order; finding additional technical expertise, altering the schedule to increase the time or reduce the features, altering the work day to accommodate child care needs...whatever it takes, that is within your power and not illegal or immoral, you should try to do.
This is because the more successful these people are, the more successful their work will be. As their manager, you'll be known for the work of the team you are on. Further, you get additional benefits from the team. If you come through for them, they may well work longer hours for you, or research something on their own time, or put in a good word in another meeting where you're not. A servant leader is basically there to make the team successful and to be the best manager that team (or those individuals) have ever had, without sacrificing efficiency, productivity, or anything else.
This adds a lot of work to your plate; mediocre managers will push this off onto other people on the team. A superlative manager will take it on, plan for it, and make it part of their normal work tasks when they take on how much they, themselves can do within a time frame. Plan for it. The people component, the managing their time, the issues, running interference with folks that would give them more work to do,...all that is the real job of a manager...everything else, like status reports and representing the team outside of the team (which is often like giving a status report) is secondary to managing a successful team.
It also means you need to be a better listener than a talker. This isn't to say that your advice and input isn't valuable, but it is often more valuable to let folks tell you, in their own words, what they see going on so you can understand how they think and what their perspectives are. In group settings, you'll get a lot of pressure to make decisions for the team, but this is also a case where asking questions and just listening to them talk among themselves is best. People who are privy to, discuss, and agree with a solution that they came up with are more inclined to support that solution moving forward. Would it be the solution you'd normally pick? Maybe not always. But remember: your job is to help solve a problem, not necessarily define what that solution will be.
So there you go. It is good to be the king, but as a manager, you'll never know, because your job isn't king. Your job is to help people be successful, and use that success to make the team and yourself successful. Your job is to listen. Your job is to protect. And, once you really get rolling in servant leadership, you won't miss being the king at all. Knights, after all, get the awesome horse and are the people you remember for saving the day.
Being a manager, however, is sadly not being a king. Honestly, you don't even get to be consort or princess or court jester. You're pretty much a Knight Errant, running around saving people from dragons and making sure the honest every day folks get what they need in terms of food, seeds, protection, etc.
I see being a manager as being the person who makes it easier/possible for the people you manage to do their jobs. In Agile, this is called Servant Leadership. It's not 'My Team' when you talk, it's "Our Team" or "The Team." You do not succeed as a manager, the team succeeds. Mind you, when the team succeeds you, too, succeed, but you never can claim their victories as yours alone. People see through that, it causes problems with the team, and generally it's just kind of a dick move all together.
As I noted in my first ever blog entry, my father thinks you can get ahead by climbing over bodies or by having people lift you up. Servant leadership counts on you being lifted up by people willing to work with you again and again. It is not what most people think of when they think of "the boss." Typically they may see themselves in an office with a great view, telling people what to do, and, if they think further than that, giving reports and presentations to other admiring and astonished folks.
Now, don't get me wrong, some folks to whom you give presentations will be astonished, but often not for the reasons you'd like them to be. Maybe they want more from the presentation, or less, or a different presentation all together. This involves a lot of talking, taking time in meetings, and extra work. This is the exact type of thing that a manager protects you from...and you're becoming someone else's manager where you'll be doing lots, and lots more of this to protect the time and efficiency of the folks with whom you work.
The world your manager manages--project manager, scrum master, boss, etc.--includes people who don't like things or like things a lot...either way translating into a lot of information coming in to manage and potential work. Those managers keep schedules and employees on track, and they do it by standing between all the various sources of potential distraction. Being a manager can often mean one less level of shielding of that for yourself + all the duties and obligations of shielding the folks that you manage.
What this translates to, in practical terms, is not giving anyone orders. It does mean TAKING ORDERS from the team, in a manner of speaking. It involves regular meetings with the team if you are a direct boss (at least once a week if possible, for a scheduled half hour, though less is fine). It doesn't just involve asking what people need help with, either. It involves taking an interest in their work life and a little in their personal life (nothing that will get HR after you, but it is nice if you can remember the names of their kids). In this way you can talk about what they're doing and FIND issues where they need help. Folks often don't realize help is available, want to "figure things out on their own" when maybe they cannot, and may not realize they need help unless they are talking to someone regularly about their work.
Taking from those meetings--formal and informal--what the folks on the team need, you now have to fill the order; finding additional technical expertise, altering the schedule to increase the time or reduce the features, altering the work day to accommodate child care needs...whatever it takes, that is within your power and not illegal or immoral, you should try to do.
This is because the more successful these people are, the more successful their work will be. As their manager, you'll be known for the work of the team you are on. Further, you get additional benefits from the team. If you come through for them, they may well work longer hours for you, or research something on their own time, or put in a good word in another meeting where you're not. A servant leader is basically there to make the team successful and to be the best manager that team (or those individuals) have ever had, without sacrificing efficiency, productivity, or anything else.
This adds a lot of work to your plate; mediocre managers will push this off onto other people on the team. A superlative manager will take it on, plan for it, and make it part of their normal work tasks when they take on how much they, themselves can do within a time frame. Plan for it. The people component, the managing their time, the issues, running interference with folks that would give them more work to do,...all that is the real job of a manager...everything else, like status reports and representing the team outside of the team (which is often like giving a status report) is secondary to managing a successful team.
It also means you need to be a better listener than a talker. This isn't to say that your advice and input isn't valuable, but it is often more valuable to let folks tell you, in their own words, what they see going on so you can understand how they think and what their perspectives are. In group settings, you'll get a lot of pressure to make decisions for the team, but this is also a case where asking questions and just listening to them talk among themselves is best. People who are privy to, discuss, and agree with a solution that they came up with are more inclined to support that solution moving forward. Would it be the solution you'd normally pick? Maybe not always. But remember: your job is to help solve a problem, not necessarily define what that solution will be.
So there you go. It is good to be the king, but as a manager, you'll never know, because your job isn't king. Your job is to help people be successful, and use that success to make the team and yourself successful. Your job is to listen. Your job is to protect. And, once you really get rolling in servant leadership, you won't miss being the king at all. Knights, after all, get the awesome horse and are the people you remember for saving the day.
Tuesday, March 27, 2012
Blame: Not as Important As Fixing What's Broken.
I'm sure you've often heard people ask not to 'Play the Blame Game' when an issue comes up during a project (or after a project has launched). Typically, they are two types of people: 1) people who feel the blame game would end very poorly for them and 2) people who are actually interested in solving the issue as soon as possible, and don't want to wade through the morass of figuring out who did it when making it not exist is the company/team/group priority.
Note, the two types of folks opposed to the blame game are not mutually exclusive.
Those invested in the blame game--who dive immediately into "who did this"--are 1) trying to figure it out so they can assign someone to fix it, 2) trying to figure it out so that it never happens again, 3) feel impotent because they can't fix it and finding who did this is something they can do 4)know exactly who did it and are trying desperately to push blame elsewhere for reasons of their own or 5) some combination of these things.
When dealing with an issue that results in some version of the Blame Game--either people deliberately asking not to play it and then playing it like crazy or folks invested in it for other reasons as listed above--you have to consider two main things: 1) Everyone involved needs to escape with their face intact (ie: not losing face) and 2) getting through the process (or skipping it if possible) as fast as you can so you can address the issue; as much as upper management may wish to know whom to crucify, they are twice as interested in knowing whom to hoist on their shoulders for leading them out of this calamity.
I like to do the following to step around the entire blame game and all the emotional and political investment within it: postpone it. Explain to everyone you can have a review or a post mortem or whatever you want to call it (I've always thought calling it a post mortem was too akin to investigating a death, which is not really what I want people to think of when they think of me and my projects) AFTER the problem is solved.
People who are scared (either because this is their fault or their afraid it will be blamed on them) will try to force the issue now. Some very well meaning people may wish to push the issue to "prevent it happening again." I liken it to a group of Girl Scouts in quicksand. Yes, putting up a sign that there is quicksand here will really help the next pack of scouts, but probably won't save the lives of the current girls slowly descending.
That said, if you have to do so, you can work with those folks who are alarmed and create an investigation of some sort to keep them happy and occupied. For example, my preferred method would be to talk to a senior dev and ask her/him to "investigate" how things happened, to appease those who are very concerned, and then work with the rest of the team to fix the issue immediately.
Investigations can also be highly useful for getting rid of people who are not actually helping. That is to say, when the Titanic sank, there were a lot of people squabbling about the iceberg and how to avoid it blocking the exits for other people trying to get off the sinking ship. Give those people something to DO. Put boundaries around their investigation, such as not being able to talk to the team until the issue is resolved, and spend some personal time with them (so they don't go looking to talk to the team, anyway) with some suggestions for future prevention that they can write up and "explore" with others.
You'll have to sell investigations to avoid a blame game, but you'll find it much easier to sell an investigation than to actually PLAY the blame game. Also, having an investigation in place while the team works to resolve the issue sounds very good in status reports to upper level managers anxious to find out what's being done NOW.
Now that the game is postponed, work to fix the problem. Offer amnesty to the entire team. It is your job to take it on the chin so they can get their work done, and this is one of those cases where you should do that. Anything they say will be kept within the team unless they agree otherwise. Let the team be honest and open with each other about mistakes, forgotten features, misunderstandings in implementation, unclear requirements, whatever. This honest is the fastest possible way to get the issue resolved. Be available to get them anything they need, from additional technical expertise to a product manager in the room to answer specific questions for them (but not actually grilling them on what they're doing or why this happened).
Resolve the issue. Note I did not say "fix." Fixing things often takes additional releases and external input. But triaging and resolving the immediate issue will make consumers, management, and the team happy.
Next step, face the postponed music. I like to gather the investigators and the team and have the investigators start by declaring their "findings." These are abbreviated to three or fewer bullet points on a white board. Then I put up the categories of "What Went Well?" "What could have gone better?" and "Action Items." If people want, I include a column for "Kudos."
We go through the "What went well?" category, drawing in investigatory findings as appropriate, and we follow that up with "What could have gone better" in the same way. Once folks feel they've got a good amount of stuff in both columns, we move to Action items and try to derive what next steps will be taken based on what went well as well as what went poorly, for the next version of the product and/or the immediate future of this resolution. Finally, I like to go over the Kudos column and end the meeting on a high note, celebrating team members, investigatory team folks, etc., for their work on SOLVING the problem.
Take all the notes from the meeting and pass them to all attendees and upper management. Post the action items where they can be seen/used for future versions.
Note this process completely avoids blaming anyone. If people try to pigeonhole in on that, drive them right back out. I like to say "It's not the people we are unhappy with, it's the behavior, so let's mark the behavior and not the people. Behavior is easier to change." This is where you protect the team to avoid finger-pointing and blaming. Even at this phase in the process, after the issue is triaged, blaming isn't helpful. Knowing which individual screwed up isn't as important as knowing how not to screw up again, and this review/post mortem/whatever you call it is going to help you not screw up again, with findings that reinforce that and can be shared with any and all involved...thus shutting down the blame game entirely.
In summary, avoid the blame game in all it's forms, postpone the blaming, include investigation to keep people busy (and out of your hair), protect your team and encourage honesty and cooperation, resolve the issue, face the postponed meeting music, and walk away with next steps to avoid this in the future. Above all: don't let any one person be blamed for anything. Its counterproductive and if you plan on working with these people again--which you probably will unless you immediately quit your job--its in your best interest everyone continues to get along.
Note, the two types of folks opposed to the blame game are not mutually exclusive.
Those invested in the blame game--who dive immediately into "who did this"--are 1) trying to figure it out so they can assign someone to fix it, 2) trying to figure it out so that it never happens again, 3) feel impotent because they can't fix it and finding who did this is something they can do 4)know exactly who did it and are trying desperately to push blame elsewhere for reasons of their own or 5) some combination of these things.
When dealing with an issue that results in some version of the Blame Game--either people deliberately asking not to play it and then playing it like crazy or folks invested in it for other reasons as listed above--you have to consider two main things: 1) Everyone involved needs to escape with their face intact (ie: not losing face) and 2) getting through the process (or skipping it if possible) as fast as you can so you can address the issue; as much as upper management may wish to know whom to crucify, they are twice as interested in knowing whom to hoist on their shoulders for leading them out of this calamity.
I like to do the following to step around the entire blame game and all the emotional and political investment within it: postpone it. Explain to everyone you can have a review or a post mortem or whatever you want to call it (I've always thought calling it a post mortem was too akin to investigating a death, which is not really what I want people to think of when they think of me and my projects) AFTER the problem is solved.
People who are scared (either because this is their fault or their afraid it will be blamed on them) will try to force the issue now. Some very well meaning people may wish to push the issue to "prevent it happening again." I liken it to a group of Girl Scouts in quicksand. Yes, putting up a sign that there is quicksand here will really help the next pack of scouts, but probably won't save the lives of the current girls slowly descending.
That said, if you have to do so, you can work with those folks who are alarmed and create an investigation of some sort to keep them happy and occupied. For example, my preferred method would be to talk to a senior dev and ask her/him to "investigate" how things happened, to appease those who are very concerned, and then work with the rest of the team to fix the issue immediately.
Investigations can also be highly useful for getting rid of people who are not actually helping. That is to say, when the Titanic sank, there were a lot of people squabbling about the iceberg and how to avoid it blocking the exits for other people trying to get off the sinking ship. Give those people something to DO. Put boundaries around their investigation, such as not being able to talk to the team until the issue is resolved, and spend some personal time with them (so they don't go looking to talk to the team, anyway) with some suggestions for future prevention that they can write up and "explore" with others.
You'll have to sell investigations to avoid a blame game, but you'll find it much easier to sell an investigation than to actually PLAY the blame game. Also, having an investigation in place while the team works to resolve the issue sounds very good in status reports to upper level managers anxious to find out what's being done NOW.
Now that the game is postponed, work to fix the problem. Offer amnesty to the entire team. It is your job to take it on the chin so they can get their work done, and this is one of those cases where you should do that. Anything they say will be kept within the team unless they agree otherwise. Let the team be honest and open with each other about mistakes, forgotten features, misunderstandings in implementation, unclear requirements, whatever. This honest is the fastest possible way to get the issue resolved. Be available to get them anything they need, from additional technical expertise to a product manager in the room to answer specific questions for them (but not actually grilling them on what they're doing or why this happened).
Resolve the issue. Note I did not say "fix." Fixing things often takes additional releases and external input. But triaging and resolving the immediate issue will make consumers, management, and the team happy.
Next step, face the postponed music. I like to gather the investigators and the team and have the investigators start by declaring their "findings." These are abbreviated to three or fewer bullet points on a white board. Then I put up the categories of "What Went Well?" "What could have gone better?" and "Action Items." If people want, I include a column for "Kudos."
We go through the "What went well?" category, drawing in investigatory findings as appropriate, and we follow that up with "What could have gone better" in the same way. Once folks feel they've got a good amount of stuff in both columns, we move to Action items and try to derive what next steps will be taken based on what went well as well as what went poorly, for the next version of the product and/or the immediate future of this resolution. Finally, I like to go over the Kudos column and end the meeting on a high note, celebrating team members, investigatory team folks, etc., for their work on SOLVING the problem.
Take all the notes from the meeting and pass them to all attendees and upper management. Post the action items where they can be seen/used for future versions.
Note this process completely avoids blaming anyone. If people try to pigeonhole in on that, drive them right back out. I like to say "It's not the people we are unhappy with, it's the behavior, so let's mark the behavior and not the people. Behavior is easier to change." This is where you protect the team to avoid finger-pointing and blaming. Even at this phase in the process, after the issue is triaged, blaming isn't helpful. Knowing which individual screwed up isn't as important as knowing how not to screw up again, and this review/post mortem/whatever you call it is going to help you not screw up again, with findings that reinforce that and can be shared with any and all involved...thus shutting down the blame game entirely.
In summary, avoid the blame game in all it's forms, postpone the blaming, include investigation to keep people busy (and out of your hair), protect your team and encourage honesty and cooperation, resolve the issue, face the postponed meeting music, and walk away with next steps to avoid this in the future. Above all: don't let any one person be blamed for anything. Its counterproductive and if you plan on working with these people again--which you probably will unless you immediately quit your job--its in your best interest everyone continues to get along.
Tuesday, March 20, 2012
Don't Let Perfect Be The Enemy of Done
A problem not often discussed in management is employees that are too conscientious and so eager to make an excellent product/program/etc. that they may, in fact, blow right past deadlines in trying to put out the best possible thing they can produce. On the face of it, it's a good problem to have all things considered: folks working with and around you with little interest in the best outcome is a completely different, and very serious problem to have; its hard to get people to care, but it is easier to reign in folks that care too much. Many people would be stoked to be with a team that puts quality above all else.
However, there's a reason that Voltaire wrote "Le mieux est l'ennemi du bien," frequently translated as "The perfect is the enemy of the good." Even in his day, a missed deadline was a missed deadline, and it didn't really matter how seriously awesome the castle walls were if they weren't up by the day they were being attacked by the British.
It is a fine balance between focusing on quality and focusing on the deadline. Delivering a product on time with too many bugs and not enough features should be just as bad as missing the deadline, but having great quality two weeks later. Sadly, it typically isn't because most companies measure success by meeting deadlines. While bugs creeping into 'finished' projects at the end often cost the company considerably more than what they would have if they'd been eliminated in the design phase, the types of measurements for fixing critical bugs don't often factor into the review process for the folks setting the release cycle. Additionally, the bugs that don't get fixed--in favor of putting in more features, for example--have no easy method of measuring affect to the users of the product unless they are very severe, in which case they affect the trust relationship with the customer. Understanding of this affect goes from 'hey, nothing's wrong, we rock' to 'crap, they hate us, what now?' pretty darn fast.
Not all companies judge strictly by the requirements of the deadline; but in software, my experience has been that at least 75% respect the deadline more than just about anything else. So deadlines are important. However, so is quality.
While I've discussed that it's hard to quantitatively determine loss of productivity and money in terms of missing bugs, I can say that there are losses if not all features are implemented, and those are very easy to ascertain. In working on a banking application, for example, failing to complete the user creation portion of the process renders the rest of the program useless, because users cannot log in to access their account information and/or make transactions. For a social website, completing the e-commerce component but failing to provide the services promised by marketing--for example, forums for the users to discuss things--have immediate impact on sales and the future success (if there is a future) of the product being constructed.
Thus, the quandry: the item needs to be built and delivered on time to preserve you and your team's reputation and your livelihood within the company as well as the company's livelihood, but it also needs to be feature robust (at least to some extent of the promises made by marketing/sales so people will buy/rent/use it) and as bug free as possible (to avoid affecting future feature creation which would be delayed by mission critical bug fixes or, worse, loss of trust with clients over severity of live bugs).
Take this quandry to a team of professionals who are here to kick ass and chew bubble gum, who are now all out of bubble gum, and you are in a position where you have to balance their natural desire to kick ass with quality as well as to kick ass within the assigned time frame.
Whether your industry is computer/IT (like mine) or building ambulances, you need to build in quality as part of the construction process of the product. Including quality in the feature creation and description will help you estimate the time to complete those features, quality included. In my previous article on the iron triangle, you have three axis to play with in order to complete a product: resources, schedule and scope. Including quality in the construction of the scope gives you information about the schedule, and can let you know early on if you need additional resources.
Prioritizing the scoped features is another huge help. Folks concentrating on quality will feel good about knowing what the most important items are to be quality, versus the items cared less about product management. For example, in a software product, the additional work to completely redesign the existing UI is easy to prioritize below the new features being promised by sales; on the ambulance example, the length of time the red paint on the ambulance will last is not as important as building a car that can withstand an impact going through a red light with a patient in the back and getting hit by someone who cannot hear the siren.
This gives your quality folks a place to SHINE. It gives them focus to make things great, and to spec out the time for that greatness. It then gives you more to bargain with and discuss when you get to the less prioritized features; they may still want everything perfect, but you have given them an opportunity to get other things perfect. Now you can focus them on getting things DONE.
Even then, folks who like to do things perfectly are usually unhappy (at least a little), and that's really what you love about them: their devotion to the work. In this case, you write bugs for the imperfect parts. You prioritize the bugs and fix the highest impact/most important ones, and then set the others aside for the next version of the product. They feel heard. Their ideas aren't lost. They can let go of perfect, and get to good.
Sometimes, as the manager, its you who needs to confront your assertions around perfect and done. It can be overwhelming to feel that you have X amount of time to deliver Y amount of quality. 99% of the time, the way that schedules are created, that business folks come up with new ideas, that customers request things, that bugs are found, things are set up to prevent both quality and timeliness. Its not like a group of people organize it that way just to see what you'll do (though it can often feel like that), it's just how things fall out in business when multiple parties at multiple levels provide input and priorities.
To combat it, do the same as you would for your team: include quality in the feature creation and scoping process, prioritize the highest features that deserve the most quality, "let go" of your need for perfection in the lesser prioritized items, and keep track of defects/issues/bugs so that the imperfections can be fixed at another time, but you can release the product now.
Good enough sounds terrible to say: "This product is good enough to go out." But the truth of the matter is that if you built a quality product, it really is good enough to go out. And the next version will be even better, because of you and your team's committment to quality. Don't let perfect be the enemy of done.
However, there's a reason that Voltaire wrote "Le mieux est l'ennemi du bien," frequently translated as "The perfect is the enemy of the good." Even in his day, a missed deadline was a missed deadline, and it didn't really matter how seriously awesome the castle walls were if they weren't up by the day they were being attacked by the British.
It is a fine balance between focusing on quality and focusing on the deadline. Delivering a product on time with too many bugs and not enough features should be just as bad as missing the deadline, but having great quality two weeks later. Sadly, it typically isn't because most companies measure success by meeting deadlines. While bugs creeping into 'finished' projects at the end often cost the company considerably more than what they would have if they'd been eliminated in the design phase, the types of measurements for fixing critical bugs don't often factor into the review process for the folks setting the release cycle. Additionally, the bugs that don't get fixed--in favor of putting in more features, for example--have no easy method of measuring affect to the users of the product unless they are very severe, in which case they affect the trust relationship with the customer. Understanding of this affect goes from 'hey, nothing's wrong, we rock' to 'crap, they hate us, what now?' pretty darn fast.
Not all companies judge strictly by the requirements of the deadline; but in software, my experience has been that at least 75% respect the deadline more than just about anything else. So deadlines are important. However, so is quality.
While I've discussed that it's hard to quantitatively determine loss of productivity and money in terms of missing bugs, I can say that there are losses if not all features are implemented, and those are very easy to ascertain. In working on a banking application, for example, failing to complete the user creation portion of the process renders the rest of the program useless, because users cannot log in to access their account information and/or make transactions. For a social website, completing the e-commerce component but failing to provide the services promised by marketing--for example, forums for the users to discuss things--have immediate impact on sales and the future success (if there is a future) of the product being constructed.
Thus, the quandry: the item needs to be built and delivered on time to preserve you and your team's reputation and your livelihood within the company as well as the company's livelihood, but it also needs to be feature robust (at least to some extent of the promises made by marketing/sales so people will buy/rent/use it) and as bug free as possible (to avoid affecting future feature creation which would be delayed by mission critical bug fixes or, worse, loss of trust with clients over severity of live bugs).
Take this quandry to a team of professionals who are here to kick ass and chew bubble gum, who are now all out of bubble gum, and you are in a position where you have to balance their natural desire to kick ass with quality as well as to kick ass within the assigned time frame.
Whether your industry is computer/IT (like mine) or building ambulances, you need to build in quality as part of the construction process of the product. Including quality in the feature creation and description will help you estimate the time to complete those features, quality included. In my previous article on the iron triangle, you have three axis to play with in order to complete a product: resources, schedule and scope. Including quality in the construction of the scope gives you information about the schedule, and can let you know early on if you need additional resources.
Prioritizing the scoped features is another huge help. Folks concentrating on quality will feel good about knowing what the most important items are to be quality, versus the items cared less about product management. For example, in a software product, the additional work to completely redesign the existing UI is easy to prioritize below the new features being promised by sales; on the ambulance example, the length of time the red paint on the ambulance will last is not as important as building a car that can withstand an impact going through a red light with a patient in the back and getting hit by someone who cannot hear the siren.
This gives your quality folks a place to SHINE. It gives them focus to make things great, and to spec out the time for that greatness. It then gives you more to bargain with and discuss when you get to the less prioritized features; they may still want everything perfect, but you have given them an opportunity to get other things perfect. Now you can focus them on getting things DONE.
Even then, folks who like to do things perfectly are usually unhappy (at least a little), and that's really what you love about them: their devotion to the work. In this case, you write bugs for the imperfect parts. You prioritize the bugs and fix the highest impact/most important ones, and then set the others aside for the next version of the product. They feel heard. Their ideas aren't lost. They can let go of perfect, and get to good.
Sometimes, as the manager, its you who needs to confront your assertions around perfect and done. It can be overwhelming to feel that you have X amount of time to deliver Y amount of quality. 99% of the time, the way that schedules are created, that business folks come up with new ideas, that customers request things, that bugs are found, things are set up to prevent both quality and timeliness. Its not like a group of people organize it that way just to see what you'll do (though it can often feel like that), it's just how things fall out in business when multiple parties at multiple levels provide input and priorities.
To combat it, do the same as you would for your team: include quality in the feature creation and scoping process, prioritize the highest features that deserve the most quality, "let go" of your need for perfection in the lesser prioritized items, and keep track of defects/issues/bugs so that the imperfections can be fixed at another time, but you can release the product now.
Good enough sounds terrible to say: "This product is good enough to go out." But the truth of the matter is that if you built a quality product, it really is good enough to go out. And the next version will be even better, because of you and your team's committment to quality. Don't let perfect be the enemy of done.
Subscribe to:
Posts (Atom)