Over the years i've been noticing a little something about the usage of specs in design and how you should write and interpret the specs for your design. It's easy to build to a spec (ok, loaded statement but i'll let it stand for the purpose of this article) but what's not easy always is understanding the intent of the spec and the design and building in tolerance for usability.
I think that most of the time we talk about tolerance in engineering as the fudge factor that we allow for in our designs. Or to make the nitpickers more happy, it's the variance that we have to plan for we because we can only expend a certain amount of resources achieving the right level of variation. It's a numbers game filled with trade-off. There's nothing wrong with that, to me it seems like a perfectly reasonable way for the world to work. I don't think that people realize, however, just how much personal opinion they put into the tolerances that they choose.
We were in a meeting a little while ago talking about the design of our parking pay stations and we were talking about meeting ADA standards. (American Disabilities Association). This included putting our keypad at certain heights, angles and etc so people confined to wheelchairs could use them easily. We had a design that we were reviewing and one of our VP's said, 'That's not going to cut it, sure it meets the ADA requirements but it's terrible usability for a person over 6'2". They have to scrunch over to see the keyboard.'
That got me to thinking about such things. I'd noticed something else myself years ago. Most of the cars designed in Japan seemed to be technically large enough to fit a person who is over 6' tall but when you actually fit someone in there'd be a problem with headroom and/or legroom and just overall comfort. But when you put a someone into a similarly sized German car, the tall guy would fit fine. I don't really know but I've always assumed that they are designing against the similar international standards.
But watching what happened in that meeting i understood a lot better what was really going on. When it came time to approve the design or go through product testing, without someone there that actually pushed the bounds of the tolerance themselves the limitation wouldn't be known. And without passing that discomfort onto someone with the power to influence decisions, then it likely wouldn't be heard. In our case the VP made the statement and suddenly it was an important design decision. Compare the average heights of people in Germany to Japan and suddenly things begin to really make sense.
Over time, Japanese design has tailored itself better for North American sizes and i can fit rather comfortably into most of the cars i get into. It's too important a lesson to learn if you want to make sales. I'm sure there's a bunch of science out there about designing for human sizes and if i was a better blogger i might go out and find it for you. but for now i'm happy enough to have learned my little lesson about tolerance, both internal to human interaction as well as to external. After all, the chair that's comfortable to a 6' person, likely isn't nearly as comfortable to someone who's only 4'.
Monday, July 30, 2012
Thursday, July 5, 2012
perception...
quicky...listening to "Under the Influence" with Terry O'Reilly yesterday and heard some cool things.
it's all in how you look at things.
QWERTY keyboards weren't invented to slow down typists as the myth indicates that they were.
There were already 'faster' key layouts in existence that artificially slowed people down because they kept resulting in jams. The QWERTY solution allowed people to go much faster without risks of jams.
So QWERTY, in effect, sped up typists. Today we look at it as a solution to slow down typists but that's a relative statement that doesn't really capture the truth of the matter, it was an efficiency measure.
Side note - also learned that one of the reasons that the exclamation point of the past was much more rarely used was that into the '70's the only way you could get an exclamation point on a typewriter (there was no key) was to type a period, press the backspace key and then type an apostrophe.
it's all in how you look at things.
QWERTY keyboards weren't invented to slow down typists as the myth indicates that they were.
There were already 'faster' key layouts in existence that artificially slowed people down because they kept resulting in jams. The QWERTY solution allowed people to go much faster without risks of jams.
So QWERTY, in effect, sped up typists. Today we look at it as a solution to slow down typists but that's a relative statement that doesn't really capture the truth of the matter, it was an efficiency measure.
Side note - also learned that one of the reasons that the exclamation point of the past was much more rarely used was that into the '70's the only way you could get an exclamation point on a typewriter (there was no key) was to type a period, press the backspace key and then type an apostrophe.
Wednesday, July 4, 2012
It's good to have a Sacrificial Monkey
This post is a bit about presentation capabilities but also about my own personal management style.
On a personal level i have very little shame. There simply isn't much that can happen to me, or that i can cause myself that i can't spin or laugh off or otherwise absorb in some manner. I think this is a skill that derives from my razor (sometimes far too razor-like) wit and fast reaction times. I do feel shame when i say or do things that inadvertently hurt another person's feelings for sure but you simply can't make fun of me to the point where i will blush up and hide my face. Rather in fact i excel at the old give-and-take and it's possibly when i'm feeling most alive. (having said that out loud, that might be a little sad.)
Fast forward from the slightly awkward confession stage of the blog post to the part where i talk about the benefits of having a sacrificial monkey and how, for the sake of this discussion i, myself, was said monkey.
Recently my company brought in a speaker who gave a seminar about personal financial health. A talk about debt managment, managing personal risk (ie buy some insurance from me please) and saving for the future. A topic, if you will, that is at great risk for being slightly traumatic and highly dry and boring.
When our paid speaker came out you could tell that this is what she does for a living. She's dynamic, smiley, friendly and filled with personality. She has lots of little personal anecdotes and stories and tries to make a personal connection to the crowd right from the start. She has two assistants with her who help by passing out some high-quality (read expensive) info folders and then essentially stand around for the rest of the presentation. Attached to each folder is a 'hi my name is' sticker and a pen. First thing i do is pop my name on that sucker and throw it on my chest. I am the ONLY person on the room to do so. I notice this but don't really care and certainly don't take my tag off.
The talk proceeds and as you might expect, even with the dynamic speaker at the front, the dry and yet awkward material has a fairly quiet and potentially non-receptive crowd. After all, who wants to know that their spending and saving habits are probably killing them slowly. She would ask the audience for input or responses to questions and there were only a couple of people who would speak up, the rest were quiet as church mice.
As we went along it was pretty obvious that while it was a respectful audience there wasn't that sort of give and take that can make a presentation really meaningful and help what you learn really sink in. Then the presenter called me out by name...remember, mine was the only name tag available, and asked me a question about something I'd said a little before. And then made fun of me. And then asked me some more questions and made fun of me some more. The more that she interacted with me as part of her presentation, the more you could see the rest of the audience becoming engaged with the talk.
I reacted well to the interplay, joked back with her and effectively kept the humour flowing. In the end, it made for a more enjoyable and powerful discussion. At the end as I was leaving she apologized for picking on me, saying that it seemed like i was able to handle it all right. I agreed, laughed it off and went on with my day.
This interplay helped bring some clarity to something that i've not only observed but used myself in such situations. It works in meetings as well as presentations. It's finding someone to be the 'sacrificial monkey.' Someone willing to be involved in the discussion, willing to be made to look a little silly and to simply be the example. Seeing someone else in that humourous or distressful situation helps bring the rest of the audience alive. You can see the same sort of thing at the circus where a clown plays with an audience member or even with magicians who are using volunteers from the audience.
Whether it be because the audience identifies with the sacrificial monkey, are glad they aren't them or simply revels in the pain of another, it brings their own personal involvement to the situation to a whole new level.
Of course i can not warn you strongly enough that choosing the wrong sacrificial monkey can end up in tears, harassment complaints or just bad feelings. Some people don't react well to the spotlight and you have to be able to see their unease and back away.
In this case i was fine with it. Certainly i didn't need to be apologized two because i knew the trick of bringing in an audience foil. I'm not sure if the presenter actively uses the trick on a regular basis but i'm happy that i was there for her, and more importantly the members of my team that were there and able to have a more powerful learning experience. Being able to use humour, mocking and other tools as part of your management style can give you some pretty powerful tools. As i evolve as a manager, i hope to be able to document some of these tricks in a way that people can learn to embrace the methods themselves.
Until then...will you be my sacrificial monkey?
On a personal level i have very little shame. There simply isn't much that can happen to me, or that i can cause myself that i can't spin or laugh off or otherwise absorb in some manner. I think this is a skill that derives from my razor (sometimes far too razor-like) wit and fast reaction times. I do feel shame when i say or do things that inadvertently hurt another person's feelings for sure but you simply can't make fun of me to the point where i will blush up and hide my face. Rather in fact i excel at the old give-and-take and it's possibly when i'm feeling most alive. (having said that out loud, that might be a little sad.)
Fast forward from the slightly awkward confession stage of the blog post to the part where i talk about the benefits of having a sacrificial monkey and how, for the sake of this discussion i, myself, was said monkey.
Recently my company brought in a speaker who gave a seminar about personal financial health. A talk about debt managment, managing personal risk (ie buy some insurance from me please) and saving for the future. A topic, if you will, that is at great risk for being slightly traumatic and highly dry and boring.
When our paid speaker came out you could tell that this is what she does for a living. She's dynamic, smiley, friendly and filled with personality. She has lots of little personal anecdotes and stories and tries to make a personal connection to the crowd right from the start. She has two assistants with her who help by passing out some high-quality (read expensive) info folders and then essentially stand around for the rest of the presentation. Attached to each folder is a 'hi my name is' sticker and a pen. First thing i do is pop my name on that sucker and throw it on my chest. I am the ONLY person on the room to do so. I notice this but don't really care and certainly don't take my tag off.
The talk proceeds and as you might expect, even with the dynamic speaker at the front, the dry and yet awkward material has a fairly quiet and potentially non-receptive crowd. After all, who wants to know that their spending and saving habits are probably killing them slowly. She would ask the audience for input or responses to questions and there were only a couple of people who would speak up, the rest were quiet as church mice.
As we went along it was pretty obvious that while it was a respectful audience there wasn't that sort of give and take that can make a presentation really meaningful and help what you learn really sink in. Then the presenter called me out by name...remember, mine was the only name tag available, and asked me a question about something I'd said a little before. And then made fun of me. And then asked me some more questions and made fun of me some more. The more that she interacted with me as part of her presentation, the more you could see the rest of the audience becoming engaged with the talk.
I reacted well to the interplay, joked back with her and effectively kept the humour flowing. In the end, it made for a more enjoyable and powerful discussion. At the end as I was leaving she apologized for picking on me, saying that it seemed like i was able to handle it all right. I agreed, laughed it off and went on with my day.
This interplay helped bring some clarity to something that i've not only observed but used myself in such situations. It works in meetings as well as presentations. It's finding someone to be the 'sacrificial monkey.' Someone willing to be involved in the discussion, willing to be made to look a little silly and to simply be the example. Seeing someone else in that humourous or distressful situation helps bring the rest of the audience alive. You can see the same sort of thing at the circus where a clown plays with an audience member or even with magicians who are using volunteers from the audience.
Whether it be because the audience identifies with the sacrificial monkey, are glad they aren't them or simply revels in the pain of another, it brings their own personal involvement to the situation to a whole new level.
Of course i can not warn you strongly enough that choosing the wrong sacrificial monkey can end up in tears, harassment complaints or just bad feelings. Some people don't react well to the spotlight and you have to be able to see their unease and back away.
In this case i was fine with it. Certainly i didn't need to be apologized two because i knew the trick of bringing in an audience foil. I'm not sure if the presenter actively uses the trick on a regular basis but i'm happy that i was there for her, and more importantly the members of my team that were there and able to have a more powerful learning experience. Being able to use humour, mocking and other tools as part of your management style can give you some pretty powerful tools. As i evolve as a manager, i hope to be able to document some of these tricks in a way that people can learn to embrace the methods themselves.
Until then...will you be my sacrificial monkey?
Saturday, June 23, 2012
DDoS - Issue Tracking Style
Sometimes following process bites you in the ass. Or maybe i mean that sometimes following process just bites. Doesn't mean it's not still the right thing to do, it's just sometimes hard. By example...
We use Jira as our issue tracking system at work. As with most issue tracking systems, if you're not incredibly (arguably impossibly) diligent at upkeep you end up getting a number of cases that languish forevermore in an uncertain state. It's just the way of things. there's bugs that you're not going to fix...bugs that didn't make any sense...bugs that got fixed through some other issue but never got cross related...bugs that simply aren't applicable any more because that entire system has been deprecated...and...the list goes on. If you can follow strong process and make sure that every single bug that you get in is cross-referenced properly and categorized well then it minimizes it but i simply don't believe that anyone out there has no issue with growing languished bug lists. My opinion is that you try hard to have a good categorization scheme, strong workflow built into your process and your bug tracking system and make your best effort. And then every couple of years you devote some time to clean-up.
So fast forward to week before last at my company. One of the Dev managers decided that before we start some fairly major re-design efforts that the backlog of languishing bugs should be sorted and dealt with so that when we start the design we're not only taking into consideration the requirements and issues that currently rest in the forefront of everyone's brains but that we also make sure we're building upon lessons learned in the past. A very good and honourable intent. I wasn't aware that she was making this effort...at least until i started to see it's results.
So, as QA manager i have it set up that any bug that gets updated, entered, closed etc in Jira sends me a notification. Daily i read all of these updates, generally less than 50 on your average day and it only takes a few seconds per case unless there are issues. It keeps me in the loop on a lot of things and when i spot issues then the time spent has been invaluable. It's a good process to follow for me and as i'm still pretty new, an important one. Jira has a few annoyances along this line in that standard process for closing bugs for some of my team gets me 3 notifications back to back. But i've learned to recognize these in the first case and just mark the next 2 read and move on.
Well one day a couple of weeks ago i started noticing quite a lump of cases coming from the Dev manager. As i was processing them i noticed that they were all old (some of them 4 years or older) and that they fell into three basic categories;
a) 'no longer an issue, closing the bug,'
b) 'probably not an issue, please retest and confirm,'
c) 'still an issue,' additional categorization added.
So i started to process these cases myself. And by process i mean read. A couple, and only a couple of the close ones i grabbed and asked for re-test instead because i wasn't sure and most of the retest ones i assigned to a particular resource. It was all good. Fast forward again, this time until i've processed over fifty of the things and i go to find out what's up. She tells me what she's doing and i think it's a good idea and i resign myself to some extra work for the next few days. When it hit a 100 or so i realized that although i was seeing about a 25% rate of ones marked for closing i was never actually seeing any bugs being closed.
So i went and asked the Dev Manager if she was closing any, to which her response was that she wasn't because Dev's don't close bugs, QA should. Which i think is a great response and really how it should be. I objected to the use of the term in the bug 'closing the bug,' and she agreed. We discussed and since i review all bugs, even those that have been closed, and since she had some 750 of them to process for this short period she was going to close them as well and rather than my having to read the email notification and then open the bug and update it she would just do that part.
This sounded like a good, safe solution to me. Until she emailed me 15 minutes later saying that she didn't have the rights to close bugs.
Here's where proper process bit me in the ass. It's pretty standard to have this process as well. It's common to only allow QA's to close issues so that you don't have the devs making decisions without knowing the full story. It's good process. I don't argue this fact at all. However, when i went home that friday i still had a queue of about 100 to go through, when i came back in monday, i had 385, the dev manager worked until 8:30 PM on a friday night going through the backlog.
Here's where the DDoS (denial of service) title of the blog entry comes in. All last week i tried to find time to process this stack but all i had was this ever-increasing list of notifications to process because she was finding more time that i could. When you have 400 notification emails most of them with the same sender name beside them, it becomes difficult to see the new updates from other team members. Each scrum that week i mocked the dev manager for her DDoS attack, and each time she apologized. I indicated it was ok but that i was still going to mock her for the attack. It was my method of releasing the annoyance of the task.
Because, everything else said, it's still an important task. Two people processing all the cases seems from some standpoints to be silly but in the end, clearing out the backlog is great. It's going to provide excellent information for the new design work and i'm learning a ton about the system as we go. And i've caught a dozen or so that i wasn't happy with the action taken and altered it to be a little safer.
Sometimes process hurts.
If it's good process though, it always helps.
When i left this friday i still had 100 in the queue. But i had started sorting and ensuring i was going through the new ones first every day. And she's through all 750 now, so 100 is all i should have left.
We use Jira as our issue tracking system at work. As with most issue tracking systems, if you're not incredibly (arguably impossibly) diligent at upkeep you end up getting a number of cases that languish forevermore in an uncertain state. It's just the way of things. there's bugs that you're not going to fix...bugs that didn't make any sense...bugs that got fixed through some other issue but never got cross related...bugs that simply aren't applicable any more because that entire system has been deprecated...and...the list goes on. If you can follow strong process and make sure that every single bug that you get in is cross-referenced properly and categorized well then it minimizes it but i simply don't believe that anyone out there has no issue with growing languished bug lists. My opinion is that you try hard to have a good categorization scheme, strong workflow built into your process and your bug tracking system and make your best effort. And then every couple of years you devote some time to clean-up.
So fast forward to week before last at my company. One of the Dev managers decided that before we start some fairly major re-design efforts that the backlog of languishing bugs should be sorted and dealt with so that when we start the design we're not only taking into consideration the requirements and issues that currently rest in the forefront of everyone's brains but that we also make sure we're building upon lessons learned in the past. A very good and honourable intent. I wasn't aware that she was making this effort...at least until i started to see it's results.
So, as QA manager i have it set up that any bug that gets updated, entered, closed etc in Jira sends me a notification. Daily i read all of these updates, generally less than 50 on your average day and it only takes a few seconds per case unless there are issues. It keeps me in the loop on a lot of things and when i spot issues then the time spent has been invaluable. It's a good process to follow for me and as i'm still pretty new, an important one. Jira has a few annoyances along this line in that standard process for closing bugs for some of my team gets me 3 notifications back to back. But i've learned to recognize these in the first case and just mark the next 2 read and move on.
Well one day a couple of weeks ago i started noticing quite a lump of cases coming from the Dev manager. As i was processing them i noticed that they were all old (some of them 4 years or older) and that they fell into three basic categories;
a) 'no longer an issue, closing the bug,'
b) 'probably not an issue, please retest and confirm,'
c) 'still an issue,' additional categorization added.
So i started to process these cases myself. And by process i mean read. A couple, and only a couple of the close ones i grabbed and asked for re-test instead because i wasn't sure and most of the retest ones i assigned to a particular resource. It was all good. Fast forward again, this time until i've processed over fifty of the things and i go to find out what's up. She tells me what she's doing and i think it's a good idea and i resign myself to some extra work for the next few days. When it hit a 100 or so i realized that although i was seeing about a 25% rate of ones marked for closing i was never actually seeing any bugs being closed.
So i went and asked the Dev Manager if she was closing any, to which her response was that she wasn't because Dev's don't close bugs, QA should. Which i think is a great response and really how it should be. I objected to the use of the term in the bug 'closing the bug,' and she agreed. We discussed and since i review all bugs, even those that have been closed, and since she had some 750 of them to process for this short period she was going to close them as well and rather than my having to read the email notification and then open the bug and update it she would just do that part.
This sounded like a good, safe solution to me. Until she emailed me 15 minutes later saying that she didn't have the rights to close bugs.
Here's where proper process bit me in the ass. It's pretty standard to have this process as well. It's common to only allow QA's to close issues so that you don't have the devs making decisions without knowing the full story. It's good process. I don't argue this fact at all. However, when i went home that friday i still had a queue of about 100 to go through, when i came back in monday, i had 385, the dev manager worked until 8:30 PM on a friday night going through the backlog.
Here's where the DDoS (denial of service) title of the blog entry comes in. All last week i tried to find time to process this stack but all i had was this ever-increasing list of notifications to process because she was finding more time that i could. When you have 400 notification emails most of them with the same sender name beside them, it becomes difficult to see the new updates from other team members. Each scrum that week i mocked the dev manager for her DDoS attack, and each time she apologized. I indicated it was ok but that i was still going to mock her for the attack. It was my method of releasing the annoyance of the task.
Because, everything else said, it's still an important task. Two people processing all the cases seems from some standpoints to be silly but in the end, clearing out the backlog is great. It's going to provide excellent information for the new design work and i'm learning a ton about the system as we go. And i've caught a dozen or so that i wasn't happy with the action taken and altered it to be a little safer.
Sometimes process hurts.
If it's good process though, it always helps.
When i left this friday i still had 100 in the queue. But i had started sorting and ensuring i was going through the new ones first every day. And she's through all 750 now, so 100 is all i should have left.
Thursday, June 14, 2012
Hiring hiring hiring
Hiring is on my mind lately, not the least because i have a couple of spots that i'm looking to fill. This morning the twitterverse handed me a couple of articles that made me want to talk about hiring a little bit.
The articles in question are "Why you should hire like a rock band." and "The case for hiring 'under-qualified' employees," You can read them as you will but essentially the first talks about hiring for culture and the second talks about hiring for hunger. Both of these articles struck a similar chord to me, both have the same goal in the end. You need to hire people that will fit your organization more than you need to hire the skills that your headcount requires.
Rating fit above skill is the hard part for a lot of people to swallow. This might be in part because it's a lot more nebulous and therefore is more difficult to measure. It's not even all that easy to adequately assess the technical skills of a candidate but at least you're capable of measuring something and having some idea about their qualifications. Anyone who objects to this statement hasn't really tried to write a test or set of questions to give a high level of confidence of the actual practical appliable skills of a candidate and then matched them to the results down the road.
It's kind of the holy grail. A test that shows you that they'll be able to do the work that you put in front of them at the level that you desire. Either they test well and implement poorly or test poorly but might implement well, but you'll never know cause you didn't hire them based upon the test.
On the other hand, if you start by attempting to match for culture and personality fit with skills secondary (but not unimportant) then you stand a much better chance of getting where you're going. If you can figure out that a person is someone who wants to achieve, will work hard, will mesh with your team pretty well and is capable of achieving shared vision with your organization then you should be able to train them to whatever level you need them to occupy. Granted, the closer you can get to the skills you want/need will shorten this amount of time.
The next question might be to ask how you assess this fit. It's not easy. When i go into an interview i have a few questions written down, about 20, that i like to get ask. Not really necessarily because i like to know that they have the right answer to the question but rather how they tackle the question and the process they use to achieve an answer and then what they come up with. One of my favourites was discussed in an earlier post about usability. The two-parter asking the candidate both, 'who in their experience owns usability' and 'who should own usability.' There isn't a correct answer to this question, there's barely even a wrong answer if you can give me reasoning that makes me believe that you can think coherently about things. But even in the way that you deal with left field questions will help me to figure out if you're going to fit in. do you have a good attitude about it, tackle it positively, don't fill your answer with too much bullshit etc. I know there's a lot of science behind interview process but in the end the assessor, or interviewer, has to figure out the fit thing on their own personal level.
Here's one of the good things about bringing in someone to interview who's not really qualified for a job; they don't hold back. Generally they have nothing to lose, so they really put themselves out there. there will be some that are too nervous to make that work but that's the thing with someone who's not qualified, if they can't shine in the interview you really don't want them. In a lot of ways the decision becomes easier because you only care if they really shine. In tech, sometimes you have to consider people who are fully qualified but have quietness issues or smell weird or whatever because you're hiring for an odd skill set and your price range is fixed. That doesn't work with the under-qualified. If they don't impress the pants off you in the interview you know that they're not going to have the go-gettum-ness to learn the skills to do the job.
I've had a lot of success in hiring for fit and ability to learn for Jr positions. Especially in QA. QA's a tough one for finding qualified jr's though. Generally they only stay a Jr for a couple of years and they won't really be looking during their first job for something else until it's time to move up. So you have a choice, you can hire fresh out of training, and frankly i've never ever been particularly impressed with the candidates i've seen coming out trained for QA or you can hire someone with an obvious aptitude that you can train. a person who's shown that they want and need to learn things can not only learn the skills they can learn to adapt to your culture faster, easier, better.
And here's the clincher; I'm not just talking about social/work culture. I'm talking about culture of quality. You get to take a receptive, clean (so to speak) mind and imbue them with your quality goals and concepts. it's a very powerful way to help your team grow in quality the way that fits your quality vision. Top down to the bottom and then bottom back up. Having people who are ready, willing and able to achieve shared vision with your rapidly is very powerful and can't be discounted.
In summary, no matter your skill needs, always try to hire for fit but don't discount the under-qualified because longer-term they might be the best choice for the job.
The articles in question are "Why you should hire like a rock band." and "The case for hiring 'under-qualified' employees," You can read them as you will but essentially the first talks about hiring for culture and the second talks about hiring for hunger. Both of these articles struck a similar chord to me, both have the same goal in the end. You need to hire people that will fit your organization more than you need to hire the skills that your headcount requires.
Rating fit above skill is the hard part for a lot of people to swallow. This might be in part because it's a lot more nebulous and therefore is more difficult to measure. It's not even all that easy to adequately assess the technical skills of a candidate but at least you're capable of measuring something and having some idea about their qualifications. Anyone who objects to this statement hasn't really tried to write a test or set of questions to give a high level of confidence of the actual practical appliable skills of a candidate and then matched them to the results down the road.
It's kind of the holy grail. A test that shows you that they'll be able to do the work that you put in front of them at the level that you desire. Either they test well and implement poorly or test poorly but might implement well, but you'll never know cause you didn't hire them based upon the test.
On the other hand, if you start by attempting to match for culture and personality fit with skills secondary (but not unimportant) then you stand a much better chance of getting where you're going. If you can figure out that a person is someone who wants to achieve, will work hard, will mesh with your team pretty well and is capable of achieving shared vision with your organization then you should be able to train them to whatever level you need them to occupy. Granted, the closer you can get to the skills you want/need will shorten this amount of time.
The next question might be to ask how you assess this fit. It's not easy. When i go into an interview i have a few questions written down, about 20, that i like to get ask. Not really necessarily because i like to know that they have the right answer to the question but rather how they tackle the question and the process they use to achieve an answer and then what they come up with. One of my favourites was discussed in an earlier post about usability. The two-parter asking the candidate both, 'who in their experience owns usability' and 'who should own usability.' There isn't a correct answer to this question, there's barely even a wrong answer if you can give me reasoning that makes me believe that you can think coherently about things. But even in the way that you deal with left field questions will help me to figure out if you're going to fit in. do you have a good attitude about it, tackle it positively, don't fill your answer with too much bullshit etc. I know there's a lot of science behind interview process but in the end the assessor, or interviewer, has to figure out the fit thing on their own personal level.
Here's one of the good things about bringing in someone to interview who's not really qualified for a job; they don't hold back. Generally they have nothing to lose, so they really put themselves out there. there will be some that are too nervous to make that work but that's the thing with someone who's not qualified, if they can't shine in the interview you really don't want them. In a lot of ways the decision becomes easier because you only care if they really shine. In tech, sometimes you have to consider people who are fully qualified but have quietness issues or smell weird or whatever because you're hiring for an odd skill set and your price range is fixed. That doesn't work with the under-qualified. If they don't impress the pants off you in the interview you know that they're not going to have the go-gettum-ness to learn the skills to do the job.
I've had a lot of success in hiring for fit and ability to learn for Jr positions. Especially in QA. QA's a tough one for finding qualified jr's though. Generally they only stay a Jr for a couple of years and they won't really be looking during their first job for something else until it's time to move up. So you have a choice, you can hire fresh out of training, and frankly i've never ever been particularly impressed with the candidates i've seen coming out trained for QA or you can hire someone with an obvious aptitude that you can train. a person who's shown that they want and need to learn things can not only learn the skills they can learn to adapt to your culture faster, easier, better.
And here's the clincher; I'm not just talking about social/work culture. I'm talking about culture of quality. You get to take a receptive, clean (so to speak) mind and imbue them with your quality goals and concepts. it's a very powerful way to help your team grow in quality the way that fits your quality vision. Top down to the bottom and then bottom back up. Having people who are ready, willing and able to achieve shared vision with your rapidly is very powerful and can't be discounted.
In summary, no matter your skill needs, always try to hire for fit but don't discount the under-qualified because longer-term they might be the best choice for the job.
Saturday, June 9, 2012
Hiding in the Corner
So i'm working a new job now, with a new team. I've been here just over 3 months at this point and while i have a good handle on the culture here, i'm still learning some of the ins and outs.
This week something happened that demonstrated to me that there are things about the culture that are impacting our ability to be successful and upon noticing these i found myself giving my first lecture to my team.
Everyone knows that tech folks tend to be a little more socially awkward, on average, than your standard human being. But that said they do cross a spectrum of personalities and trends for interpersonal communication. But as is true with any group these personalities come together, combine with the traditions of the organization and form your culture. The culture of the technology folks at this place trends towards quiet and insular. My team gets along with each other pretty well on a quiet respectful basis and interacts with the other eng teams similarly. The other eng teams kind of fit the same description. It's not that we don't laugh when we're together but it's more that laughing only happens when we're together and not with others at the company.
This description does not fit the other groups at the company. As you might expect sales, marketing and client services are a lot more social, interrelate, participate and etc. That's pretty natural.
Well fast forward to this past Wednesday where the office admin sent out a couple of emails asking the employees to come in on Thursday wearing red and white or wearing something that says Canada on it. The CEO became a Canadian Citizen on Wednesday and they wanted to have a little informal surprise celebration in front of his office.
So the next day i come in, wearing a bright red t-shirt and a white over-shirt. I enter through the back way so that if the boss is there he'll not see me and start to have suspicions. I notice that not much of engineering is wearing red or white but i naively assume that at least a couple of my guys would have done something. I see the first guy and i mock him a bit. I feel that mockery is a very strong tool for behaviour modification, especially when it's an informal change that you're looking for. Not too long after that i'm in a meeting room having my morning scrum with my team and not a single member of my team in that room is wearing red or white. More like, their clothes seem to have been chosen for the opposite because there's not even any random bits of white on anyone's clothes.
I think about doing a little good natured chiding but then i decide that this simply isn't good enough, that there's a really important point here that they are missing. So we laugh a bit and then i go into lecture mode.
There are two reasons why not conforming to work events like this are bad. We've already talked about how engineering is a little insular in our company. This is causing some problems. At least due in part to the fact that the teams in engineering haven't really been building any relationships with the other teams at the company. This has made it easier for other teams to play the finger pointing blame game rather than the 'let's be a team and figure this out' game. Relationships are one of the key things that help reduce the blame game. It's way harder to point finger's when your brain is going, 'Frank's a good guy, he wouldn't do anything on purpose to cause this problem.' By standing back and not participating in these events it's encouraging the 'us' and 'them' mentality. There's the people who are cool and interesting and care enough to be involved and the 'weirdos in the corner' who don't.
The second reason is a little more self serving. The CEO's office is pretty much in between our two groups. So i asked the team what they thought he would think when he steps out of his office and looks to the right and sees a sea of white and blue and then looks to the left and sees an ocean of not even remotely red and white? And better yet, what if he looked to the left and saw a little island of red and white in the blue and grey group and knew that that island was QA. I'm not saying he'd rain cash down on us or anything but it's really important to stay both in the mind of of your CEO and while in that mind to be thought of positively.
Then my boss showed up not wearing a lick of the right colours...sigh.
You don't have to play politics to be a good manager but you have to understand relationships, what they do and what they mean.
I think the team got it.
Maybe.
This week something happened that demonstrated to me that there are things about the culture that are impacting our ability to be successful and upon noticing these i found myself giving my first lecture to my team.
Everyone knows that tech folks tend to be a little more socially awkward, on average, than your standard human being. But that said they do cross a spectrum of personalities and trends for interpersonal communication. But as is true with any group these personalities come together, combine with the traditions of the organization and form your culture. The culture of the technology folks at this place trends towards quiet and insular. My team gets along with each other pretty well on a quiet respectful basis and interacts with the other eng teams similarly. The other eng teams kind of fit the same description. It's not that we don't laugh when we're together but it's more that laughing only happens when we're together and not with others at the company.
This description does not fit the other groups at the company. As you might expect sales, marketing and client services are a lot more social, interrelate, participate and etc. That's pretty natural.
Well fast forward to this past Wednesday where the office admin sent out a couple of emails asking the employees to come in on Thursday wearing red and white or wearing something that says Canada on it. The CEO became a Canadian Citizen on Wednesday and they wanted to have a little informal surprise celebration in front of his office.
So the next day i come in, wearing a bright red t-shirt and a white over-shirt. I enter through the back way so that if the boss is there he'll not see me and start to have suspicions. I notice that not much of engineering is wearing red or white but i naively assume that at least a couple of my guys would have done something. I see the first guy and i mock him a bit. I feel that mockery is a very strong tool for behaviour modification, especially when it's an informal change that you're looking for. Not too long after that i'm in a meeting room having my morning scrum with my team and not a single member of my team in that room is wearing red or white. More like, their clothes seem to have been chosen for the opposite because there's not even any random bits of white on anyone's clothes.
I think about doing a little good natured chiding but then i decide that this simply isn't good enough, that there's a really important point here that they are missing. So we laugh a bit and then i go into lecture mode.
There are two reasons why not conforming to work events like this are bad. We've already talked about how engineering is a little insular in our company. This is causing some problems. At least due in part to the fact that the teams in engineering haven't really been building any relationships with the other teams at the company. This has made it easier for other teams to play the finger pointing blame game rather than the 'let's be a team and figure this out' game. Relationships are one of the key things that help reduce the blame game. It's way harder to point finger's when your brain is going, 'Frank's a good guy, he wouldn't do anything on purpose to cause this problem.' By standing back and not participating in these events it's encouraging the 'us' and 'them' mentality. There's the people who are cool and interesting and care enough to be involved and the 'weirdos in the corner' who don't.
The second reason is a little more self serving. The CEO's office is pretty much in between our two groups. So i asked the team what they thought he would think when he steps out of his office and looks to the right and sees a sea of white and blue and then looks to the left and sees an ocean of not even remotely red and white? And better yet, what if he looked to the left and saw a little island of red and white in the blue and grey group and knew that that island was QA. I'm not saying he'd rain cash down on us or anything but it's really important to stay both in the mind of of your CEO and while in that mind to be thought of positively.
Then my boss showed up not wearing a lick of the right colours...sigh.
You don't have to play politics to be a good manager but you have to understand relationships, what they do and what they mean.
I think the team got it.
Maybe.
Wednesday, June 6, 2012
How Quality Tools Present Value
So during my lunches i'm studying the Certified Manager of Quality/Organization Excellence Handbook in order to hopefully take my test for my CMQ/OE certification in the future. I'm still in the pretty early stages and it's going to take a while since i essentially dedicate 1/2 hour per day to it. Today i was reading about Change Management in the Leadership section and I came to a conclusion that, while it can't be generalized over all Quality Tools, i think holds for a large number of them.
The generalization is that these tools maximize their value mainly for the participants in the creating of the forms and not so much for after-the-fact consumers of them. I came to this conclusion while looking at an Interrelationship Digraph. The interrelationship digraph is a method of representing multiple elements of a process and capturing how they interrelate. Below is an sample of one that i randomly found via google.
 |
| sample interrelationship digraph (random) |
The thing is, a picture like this probably has some value to everyone who understands it but the value is going to be on different scales. When i look at many of the tools that make up quality, like the DFMEA, or a Pareto diagram or this diagram the way to maximize the quality of your graph by far is to be one of the participants that are in the room while you're working together to produce the content. When you sit in a chair and actively contribute to the analysis that produces the diagram you're not only part of the discussion that draws each of the shapes on the diagram you're likely also coming up with some of the ideas yourself. There's simply no better way to learn and understand than to be involved in the creation of the idea.
As with any model, it's the reduction of a large pool of contextual and factual information into a simpler form. But for a person who reviews the document later, if they were in that room, their brain still retains remnants of that context and can bring it back up. To a person who wasn't in the room, even if they are highly involved in the subject matter, a diagram like the one viewed above loses a dimension. I think that's a good way of looking at it, it really does flatten out to the 2 dimension you can capture on the page but for a person with a personal involvement to the creation, there's enough collateral information floating around in their thought processes that it really lifts up off the page to become multi-dimensional.
In the example i've been using, the interrelationship digraph, in the text of my book, they showed how it was utillyzed to come to a number of conclusions about the best process to use in implementing a suggestion system. As i read through the conclusions i realized that if you stepped away and tried to use the digraph itself to build your argument for the conclusion that it really didn't support it very well. It pointed in the right direction, for sure, but it was only skeletal support at best. However, by taking into account the user stories mentioned in the creation of the digraph, it really supported the conclusions well. The book provided the context to bring the digraph into the extra dimension for the reader.
So what am i trying to tell you? Am i trying to tell you that you shouldn't review the outputs of Quality Tool investigations? Certainly not. What i'm trying to instill in people, managers especially, is that the higher the participation you put in utilizing these tools does not only result in a higher value for the output of the tool but it also results in a much higher personal value. You will never get the value as a consumer of this output as a non-participant as you would for being there and contributing. Don't sluff off those meetings because they're boring and your team can handle them...by being a member, not only do you bring value to the process but you bring value to yourself.
Subscribe to:
Posts (Atom)