Thursday, May 31, 2012

Quality in the music industry? Huh, where?

Back to my history.  When BC Rail was sold to CN i was given the option of being offered a job with CN and moving to Montreal or getting a severance package.  There were a number of things against my going to montreal, for one the IT dept with CN was 600 people, for another i had a new girlfriend here that i really liked, montreal has actual winters and the worst thing was that CN was a hegemony of evil to work for.   It's ok to work for evil and it's ok to work for a hegemony, but never both at the same time.

so i dodged that bullet and took the severance.  turns out it was the very right thing to do at the time.  i mean i had a 8 years into QA at the time, was a lead, did some pretty solid BA work and i was pretty sure i could get another job but i was a little afraid of it all.  But as with most things in IT, to really move up, you generally have to move on.

I took my severance and had a beautiful summer of no pants.  it was planned, i ended work at the start of the May and i told myself i wasn't even allowed to start looking for something else until sept.  and i didn't.  best. summer. ever.  i learned that as long as you plan and do one thing each and every day, your relaxed carefree time will seem like a very real, no wasted, vacation.

when i started looking again i had two decided paths.  I was looking for QA lead or manager work or i was looking for intermediate BA work.   I think at that point my passion was a little more focused on becoming a solid BA.  I felt that i had very solid grounding in the QA world and what i needed was a broader experience base in the BA world.  i had nibbles and interviews in both paradigms and then after a month and a half of job search i took a QA-BA role at a start-up that evolved into a Product Manager role, still responsible for all things QA and BA at the small company.

The start-up company was making a kiosk product that would allow the user to browse the million song music catalogue, start a collection and then burn it to CD as they waited.  there was a goal to do MP3 player loads as well but that was a phase 2 product that never actually got released.

There were a few wonderful evolutionary parts for me at this company:

  • Wiki - it was my first introduction to the usage of a wiki for documentation.  it wasn't the best thing ever for my BA documentation but it was an innovative solution for test cases, plans and results.  I loved the wiki for that.  the ability to organize and maintain this information was quite powerful.  when i went to my next job it was one of my first questions about tools to be used. 
  • Standardization of process and documentation - going into a startup with a clean slate of process and documentation allowed me to rethink all of the process and documents that i'd put in place for BC Rail and give it a fresh shake.   having standardized templates that could from the start encapsulate what i'd learned in my previous roles was superb. 
  • Usability - The difference between the usability expected for a retail facing kiosk product was so different than the usability concerns for the in-house used industrial/transportation products that i had no choice but to really start building a wider perspective of usability and how it fits into the development process.  I felt i really matured in this arena there. 
  • Self-motivation - as start-ups go, we were very loosely monitored and controlled.   i was responsible for my two spheres of influence and had to get the other team members to interact with my spheres productively.   
The biggest thing about the job however is how insane dealing with music labels and their data is.  They have a million draconian rules, a million different data types/structures, hundreds of rules about updates, take-downs, enable dates and etc that are so complicated they have immense amounts of trouble holding to them themselves.  More than anyplace else i learned in this job that complexity is the enemy of quality.  If you need to be complex, then you need to figure out ways to spend the time and effort to maintain quality.  

With the music labels there is simply no way that the amount of complexity that has evolved is even remotely necessary.  It's a track, here's it's price, here's when you can sell it, here's when you can't.  move on.  but no.  the single most amount of time in the company was not spent developing a system that could handle all of this complexity, rather it was negotiating a contract with the labels.  they have hundreds of such contracts, how do they maintain any semblance of tracking or quality when they can't even standardize on how they deliver their core business?

In the end there were endless problems with the content and threat letters on a regular basis as the interpretation of this rule or how this data was handled incorrectly as far as a particular employee of that label was concerned.  Now multiply that by the fact that we had 5 major labels to contend with.  Not partner with, not deal with, contend with. 

My new rule of thumb is anything where the contract takes longer to negotiate than it takes to develop the software, run like hell. 

2.5 years later the funding dried up, we had  product in about 100 locations that were making some money but the profit margins in music are very minuscule and start-up blew up. 

I certainly learned a lot about a lot of things.  I hadn't dealt with the concept of retail before and it helped me think in some pretty different ways.  The team i worked with was intelligent, young, interested and fun.  Above all it was fun.  We worked in an excellent part of town, Granville Island, in a hundred year old dock warehouse.  Lunch every day at the market.  Very casual atmosphere.  Dart breaks twice a day.  Long hours.  Shorts and the dog whenever i wanted.  Start-ups are great in a lot of ways.   There's never even the concept of 'that's not my job' because everything that needs to get done needs to get done by the people available. 

As rebound jobs was a good one. 

Tuesday, May 29, 2012

Quality is a Forever Quest

Need a reason to ALWAYS strive for quality and never give up?  my chair has been mildy uncomfortable since i took this job, i fiddled some but never achieved happiness and just decided the chair couldn't be altered in that way.  i resigned myself to always sort feeling like i was going to slide forwards off the seat, at least until  found a new and better chair. 

today i found that a lever worked differentely than i'd assumed before and in two seconds the amount of comfort possible from this site changed drastically.  

I count these 3 months of relatively unfomfortable seating as my fault. 

Sunday, May 27, 2012

Own your embarassment

So this past week something rather amusing happened to me.

My company has an attachment to this management training consulting type company.  The lead guy for this company, a rather amusing guy who can categorically be called a wingnut, gives seminars on some management topic or another as part of his business.  As part of our attachment, when they sound topical we bring him in to present them to our managers. 

This month he was giving a talk on how to run efficient useful meetings. Well there ain't no one anywhere who can't use some help in that regard and as such we brought him in.  It was a well attended meeting as well, there were over 20 people crammed into our main boardroom. Which had the 10 seats around the boardroom table and then something like 10 or 15 more sitting around against the wall.  They brought in sandwiches and drinks and we worked (in quotes work should be) through lunch and another hour too. 

As we ate our lunch he proceeded to give us a talk about meetings.  His presentations are very heavily injected with anecdotes from his own personal life, about his wife, his daughters and just about everything else.  He's German originally and has a very in-your-face way about him.  He is very much a hoot to watch and listen to.  A couple of us in the group, myself included because that's the type of people that we are like to give him a bit of trouble but he's a good sport and gives it right back. 

There are group exercises where he stops and has us think up some answers to questions about points he's either just made, wants to make again or is about to make.  he is a pretty good presenter/trainer.  Pretty much any answer ever given him is wrong because he has a curious method of answering his own questions in a way that make you think that you've answered a slightly different question than he did but even that leads to information trading. 

So due to the very intelligent fact that i had another meeting in the boardroom just before the seminar i got a seat, not only at the table but at the head of the table.  he's at the other end in front of a screen presenting.  Before we start he kind of makes a joke about how imposing my straight on look at him is but we laugh it off.  

The seminar goes well. i enjoy it, i participate and so do many others.  Especially the group right behind me that includes the CEO and a couple of directors.  So fast forward a bit, to the last 10 minutes of the presentation.  He's wrapping up and giving one of his longer speeches sailing through a bunch of bullets that kind of recap his ideas.  So i've uh been at meetings for 4 hours straight at this point, haven't been out of that chair in 3 hours and have eaten a higher carb lunch than i'm normally allowed.  During his speech my eyes close.  

I'll fully admit it. My eyes closed.  shut. like midnight.  but i wasn't' asleep...yet.  In fact, truth be told, this actually happened twice in the last 15 minutes of the presentation.  Only, he missed it the first time.  And i didn't fall asleep, i drifted a bit.  Second time though...he didn't miss it. 

He saw it.  As soon as his voice stopped my eyes popped open. i could have told you the last two sentences he'd just read but that didn't really matter.  he made eye contact with me and he tried to recover.  Tried really hard to recover.  He failed.  Then he started talking to me, but in a sort of vague esoteric kind of way that didn't give people context. 

"If only you hadn't been directly in front of me...if you'd been off the side i could have made it."
"Going right along doing great and then i see you"
"i couldn't were one and i couldn't...

Now everyone else on the room except for him and i are completely confused.  They have no clue.  Slowly though, especially when he mimics a person shutting their eyes and sort of slumping over in sleep (that second part never did happen mind you) the crowd figured out what he was talking about.  But they made an assumption.  He kept looking directly at me as he talked but what they saw him to be looking at was the CEO sitting directly behind me.  

The entire room is starting to believe that the CEO had been caught sleeping.  It was very funny for the room, although they weren't super sure how to take it.  the CEO was completely confused though.  he was paying proper attention (probably, how could i tell, he was behind me).  I could find the humour in the room begin to build and decided that i'd best defuse it before the poor CEO had to carry this on him in some way (not to mention permanent damage or mockery, that i was the cause of). 

so i spoke up loud and clear that it was me he was talking to, that my eyes had closed and it derailed him.  and it worked. owning up to the eye closure let him say a couple of more things, let the crowd smile and laugh, at me, and we moved on. 

i don't embarrass easily, i still got what i needed to out of the meeting and everyone had some good laughs.  and in fact, 10 minutes later the HR person who brings him came to my desk and said that he'd asked to be brought in to me to apologize for putting me on the spot like that but she'd assured him that i had such a good sense of humour that it would be fine.   which it was, and i was.  And i love that in 3 months a person i've talked to a dozen times got that right about me. 

The next day, in my scrum with my team i used the little story about what happened as a bonding moment with my team.  One of the things i try to watch with my teams is not to seem to, um, high functioning or unapproachable.  I really prefer a management style of authoritatively approachable.   I like to know more about what's going on than any member of my team, i like to be able to build firm opinions fast enough that there's never any doubt what I think the right course of action is.  But i also like to be approachable so such things can be discussed.  

My relationship with this team is new.  Having this laugh, owning the embarrassment without showing that i believe it degrades from my respect at all, this is part of that.   For the most part it works really well for me.  Have to watch though, you become too much of a clown and the respect goes out the window.  

One positive...i think the only manager at my company who missed the manager. 

Friday, May 25, 2012

Funny Thing Happened on the Way to the Blog.

So I started this thing about a week ago.  I wanted to get a few entries under my belt before I let anyone know about it.
Today at lunch I put up my 4th and 5th entries and thought that was a reasonable time to make it a little more public.
So I posted a note on my Linked-In suggesting to people there that they could check it out.  It seemed pretty innocuous since so few people actually read the feed on L-In.
Apparently, however, at some point something I did or didn’t do, unbeknownst to myself, (or potentially unremembered) my Linked-In account got attached to my personal twitter account.   

So it picked up my post and put it to my twitter feed.  It decided, however, that my post was too long and trimmed a bit of it.  Now it is true that my personal twitter account is attached to my facebook feed such that anything I tweet goes straight to my facebook.  So the post was picked up and transferred there.   Any guesses what was trimmed off?  Right, the tail end of my URL for the new blog that I was inviting people to check out.  Within 3 minutes I had three comments to that FB post.  All three commenting about the validity of the URL.  One making comment about the quality of the QA associated with this quality blog.

Now, I posted the blog entry on my lunch at work and sent out the note to linked-in from my phone at the same time.  I couldn’t see things happening on FB because it’s locked down here and I don’t go to see what’s up there.

It’s really a lesson about never making assumptions about the end product of your work product because you aren’t really in control of all interactions.  But from the QA standpoint it also highlights the lesson that you have to be careful, you can’t guarantee what might happen to things.   You can’t always know all the factors and the higher the level of complexity the larger the possibility of problems.   You can’t plan for every contingency, but you have to have a system fault tolerant enough to handle it.  In this case, my FB readers will likely forgive my bad URL and go to the new one that I’ve put up in a comment under the first one.

As a humour aside, I went and removed the connection from Twitter to my Linked-In for that account and will add it for the QAisdoes twitter feed (@qaisdoes).  At the same time I grabbed the post and having deleted the original twitter post, I cut and pasted the same post into a new tweet.  The entire text of the post fits with 2 characters to spare!  Which means that if twitter hadn’t had weird rules about trimming entries from Linked-In, there would have been no problem at all.

Ah well, live and learn. 

Thinking About Usability

Earlier this year I wrote the following article for a newsletter at Annex Consulting.
(the original published version is here:

Thinking About Usability

By Mike Hrycyk
I’ve been in the IT industry for some 14 years now.  My experience has spanned quite a few different roles, from QA to BA to assorted manager/lead types.  Throughout my time I’ve noticed that there’s one term that everyone likes to talk about but few people can define in any consistently meaningful way.  Usability.  What’s the big deal you might ask, it’s not like we don’t all have an idea about what usability is.  When you’re put on the spot, it can be pretty easy to break it down into some simple terms.   Just looking at the word gives you the out of saying that it means things are easy to use.   But have you ever seen tacked onto the end of a set of requirements for a developer to make it usable?  I’ve seen that more than once.   How useful are those words to a developer?  What does it really mean?  Who could say?

There are people out there who purport to study usability.  Some of them even claim to be usability experts.  I’ve worked with a few of those so-called usability experts.  As far as I can tell, if their success rate is significantly beyond that of anyone else that seems to have a knack for usability, then I am not the type of person who can really detect the difference.  There are methods that can be set up to measure it, such as needs analysis, efficiency measurements and focus groups but in the end it’s an entirely subjective term that you can try to nail down.  I am however, significantly dubious that there is really anything even remotely scientific about the knowledge to be attained.   You’d almost think that this would depress me in some way, coming out of QA and BA where we like to have everything quantified or qualified in some manner, but I’ve come to a conclusion.  It’s not important so much that you’re good at measuring usability.  It’s sufficient that you consider usability on an ongoing basis and that it’s one of your core goals.  Thinking about usability, considering it important enough to stop your development plan to fix things when they aren’t usable, that’s the simple path to success.

In the past few years I’ve picked up a lot of responsibility towards recruitment and interviewing people to join our organization.  To the extent that I’ve put together some question lists that I use for different roles that I’ve been looking after.   I rarely actually record the answers to these questions, just jot down notes about the responses that I’ve been given if they are interesting in any way.  Unless the question is particularly technical I generally am not targeting a particular response but rather want to see how they think about things and how they put together an answer for me.  Gauging how people think and approach thought problems is really important to my assessment of them.   I came up with one question for my QA hires that I quickly extended to my other interviews because I found that it gave me some critical and useful insight into the applicant.

The question is a two-parter, that in and of itself is difficult enough to give the applicant some difficulty just trying to get past the standard interview hurdle of figuring out the right path between the answer you’d like to give, the answer you think the interviewer would like to hear and what you believe the correct answer to be.   The question:  “in your experience who do believe has been the owner of usability and in your opinion who should be the owner of usability?”   I generally explain as I ask the question that there is no correct answer that I am looking for and that’s true.  For I’m not sure that there can be one correct answer to this question, nor am I expecting one.  The way to succeed in answering this question in a way that is going to impress me is to prove to me that usability is something that you’ve considered in the past and that can think cogently about.

For sure I’ve had some bad answers but even those could be well mitigated if they are backed up by some consideration and obvious thought process.  I’ve had people why had no idea what usability is, never heard the term.  Most of these get it when I explain it in other words.  Invariably people for whom the concept is too difficult to explain are dropped for consideration for the role.  All of the software that I’ve been involved in producing has user front ends.  If you’re producing front ends without an eye to usability you just don’t care about things like productivity, efficiency, return customers, word of mouth and etc and you’re simply not worth my time.  I had one person insist that the owner of usability should be the end-user and without a doubt, if you don’t pay attention then they de facto become the owner of usability. They will speak with their mouse and stop using your software.  By insisting that the end-user should be the owner, this candidate demonstrated to me a vast misconception of the system and the business.

Only once has an interviewee given me the answer of developer as the one who should be the owner.   I believe I was slightly incredulous when I asked for more details for this one.  I grant you that there may be developers out there that have a talent for design and can produce quite beautiful user interfaces all on their own but honestly they have the deck stacked against them when they go up against this hurdle.  Their day starts and they are already under the influence of a number of disadvantages.   They are generally reading twice converted requirements, if not more, and if they’re not being given designs then they have to themselves convert this into something both functional and usable.  Then there’s the perhaps debatable notion that developers just don’t think like the rest of us.  Developers are just too darned logical.  When you give them a flow to produce they go ahead and produce it, and they might even test it.  And it will work for them.  It will be logical and make sense…to them.  But users are incredibly complex (this is my nice article-way of saying what they are) and their sense of logic has a life-time of reasons to think differently.   No matter what else you might think, your average developer does not have your average brain, experience, notions, upbringing, etc.  Asking their logic to conform to the norm when their very business is assembling logic for a machine makes absolutely no sense.

With the person who answered developer, it would have been very difficult to make the decision to hire them.  Not so much because they had come up with the answer that they did but rather in discussing their answer and what I consider the answer to be they didn’t really come around to thinking about it from the larger picture.  That usability is largely about perspective.  About trying to find simplest most common perspective that will be understood the fastest by the most people and figuring out a way to translate that into a user flow.  It doesn’t have to be the fastest way through a dialogue, it doesn’t have to be the least clicks or the prettiest, it simply has to be the one that is most successful for the most users with the completely immeasurable side-effect of creating the least headaches.

For the record, the answer that I would give to the two part question is as follows.  For the most part I have seen the owner of usability become QA, but QA is the wrong place to hold usability.  If QA is not catching something as being unusable until their testing starts, then the mere fact that you are nearing to a launch date (schedules being the way they are) and usability often being so core to the development that the things that you find to change will not have the time to be altered without delaying the launch.  I think the way that my current organization has bestowed usability jointly between the BA’s and the creative design group is the most successful.  They are doing their work at the beginning of the project and therefore have all the time in the world to screw things up and then make them better.  The BA brings to the table the voice of the customer, the person funding the software, so that whatever you build has a good chance of maintaining the requirements.  The creative design group brings to the table the concept of what is good for the end user.   But you might not have a BA, or a creative design group, or even QA…but you can still think about it.  Thinking about it will always make it better…you know unless you over think it.

QA vs QC

(we'll try to intersperse my personal/professional history with some more real posts to keep things interesting)

I've been in quality for years, depending upon how you define it.  But that entire time has been in Software QA.  It wasn't until i came to work at my current company that directly manufactures product that i really learned what the difference between QA and QC really was.  

The answer used to be pretty easy.  QA is what software quality insurance folks did, finding bugs in software, reporting them and being a productive part of the process.  QC is what that inspector on the line who got to put his/her sticker on each pair of underwear promising that there are no defects in that particular piece of product.  Sounds similar but different.  QA looks for bugs in the system, QC looks for bugs in one specific iteration produced from the system. 

Turns out that the way that software development has co-opted the term isn't really correct. 
As i've learned to understand it, QC or quality control is indeed the searching for individual defects in a product.  It doesn't limit itself to a specific product iteration.  In looking for bugs in software, you're likely doing QC. 

QA or Quality Assurance, on the other hand, when you look at the use of the term across industry at large is looking at the process that produces a specific, or many product iterations and figuring out how to guarantee that there will be a generally acceptable level of defects at the end of the process.  Ie that may mean putting checks and balances along the process, that may mean doing some measurement at different stages so you don't have as many defects making it to the end.  it might mean revamping all of your lead-in stages so that things work better.  

If you look at software testing, QA would include ensuring that requirements are funneled correctly, get maintained through the life-cycle properly and get tested at the end correctly.  That development process produces reproducible high quality results.  

To people outside of software QA these definitions seem pretty rigidly understood and utilized.  To people in QA they might as well have not existed.  QC is what other people do, QA is what we do. 

As i consider the experience that i've grown over time though i realize that in actuality what has happened is that when i was a Jr QA i mostly did QC but as i grew more senior i tried harder and harder to determine what was causing the problems to occur much more than just finding the problems.  Root Cause investigation became one of the important parts of my days.  Finding ways to get people not to make the same mistake twice became part of my windmills. 

I say windmill because in software QA isn't listened to very strongly for the most part.  QA trying to suggest that project or development methodology should be updated is generally not well received.   Of course i'm generally, loud, obnoxious, argue well and can even be persuasive so my points probably get heard more than most. 

I'm not certain that most QA people are ready to actually do QA work in the external definition but it is without doubt for me that it's needed in software every bit as much as it is in manufacturing.  

That said, i will continue to respect the terminology differences and try to quietly educate people as to what they really mean.  Not the words as much as the concepts. 

Tuesday, May 22, 2012

Quality...the early years

The term quality itself has certainly gone through some changes within my professional lifetime. 

 If you’d asked me 6 months ago, I might have told you that I understood what it meant.  And experientially I probably wouldn’t have been particularly wrong but what I’ve learned in the past few months is that while I understood quality on a number of intellectual levels, I had never really tied them together in a sort of lattice work of interconnected ideas.   In essence I’d never really grokked it.

This all began to change about 3 months ago.   But before we get there, maybe we’ll add in a bit of professional history so we can see my evolution.   15 years ago, in 1997 I was working as a supervisor in Operations at BC Rail, a Class 1 railroad spanning the province of BC.  I had left university a year and a half before and had taken this ops job back to pay back some of my school debt.  My unfinished Materials and Metallurgical engineering degree wasn’t getting my anything, nor was the philosophy degree I moved into from there.   But playing with trains was a very interesting job mentally and it made each day a new and challenging hurdle.  I didn’t mind so much that it was hyper stressful either.   Having trains heading at your terminal from 3 different directions at the same time and a local yard crew to factor into the mix just made things that much more interesting.   What I didn’t like as much was living in small town northern BC (in spite of the fact that I grew up in such towns) and working with so many guys that were determined to do as little work as possible and whine, wheedle or negotiate their way out of even a 6 hour day (paid for 8) let alone those striving for a 4 hour quit.

I decided at the end of 1997 to head for Vancouver, look at going back to school and just be out of small towns.   Somehow between leaving the north and arriving in Vancouver I ended up with two new jobs at BC Rail down here.  One was quite similar to what I did up north and the other was in special projects.  In special projects I did a number of things.  I took on owning the business requirements for a rail car usage metric system, I became a trainer in the field of the same system and travelled around BC teaching all the yard people how to use our systems.  I also became a user tester for BC Rail IS department for the same project.  After a few months of that, the IS dept, so amazed by the difference that someone who was analytical, could repeat their steps and could understand the software could make in tracking down your issues decided to take me on.  
Taking a bit of a pay cut i was hired from operations into IS.  Actually hired into the computer operations department because they were happy to maybe have someone that knew the outside operations but i never actually worked for them.  I was their headcount but i instead started up BC Rails first QA dept.  
I learned on the job, set up some documentation and test standards, made testing much more rigourous and made people get it.   Over time I became the test lead but wasn't reduced to just that.  after a few years the dept did some salary and skills reviews and my title was changed to Systems Analyst.  This was because i was spending about 40% of my time doing QA lead, 40% BA work because i understood rail operations and how to talk to railroaders and could translate back to geekese and 20% 2nd tier support.  I could figure out where problems were coming from to target the best dev support resource faster than most. 

During my time at BC Rail i started to get some pretty strong ideas about quality.  I knew bugs sucked, i could find them like i could find a mosquito on my nose but that wasn't enough.  Figuring out ways to let fewer bugs through to me became important to me.  Getting the guys to write code to stop having so many bugs was a giant hurdle that i never really accomplished.  Still haven't really accomplished.  But it didn't stop me from pursuing theories about mocking developers heavily enough to make them really take stock of their work before they pushed it out the gate.  Early nibbles at controlling quality through process.  i knew that i was the final gate before we could ship something without quality.  It was met with limited success. 

That wasn't the only start i had though...i also got my first real taste of the power of process. We had a great PM come in and run a project for us.  She taught us what a trained and useful PM could really accomplish.  What true cross team standardization of process and documentation could be used for.  That started me down the path of becoming a bit of a process junkie.  More on that later. 

it was pretty sweet but by the time CN took over and closed down BC Rail i was ready to move on. 
next time we'll talk about the summer of no pants and my foray into the world of licensed music distribution. 

Quality Is as Quality Does

Quality Is as Quality Does!

My name is Mike Hrycyk and this is my quality blog.  I wanted a space to start talking about the evolution that quality is taking in my life.  Mostly in my business life, but who knows, it could thread through my entire life.  I’m reasonably sure that if I start injecting a high level of importance of my own opinion of quality into my personal life that I’m going to start having some pretty large issues with my family and friends. (There’s a topic for a future entry right there, ‘what is quality – objective or subjective,’)

I looked around for a blog title, theme, vision, mission statement, etc for a while that would properly encapsulate the way that this evolution has been progressing within my own personal sphere and in the end it kept coming back to, ‘quality is as quality does.’  It didn’t really fit the cutting edge coolness quotient that I’m sure everyone goes for when naming their blog and my wife seems to think it’s a little bit quaint (which is I believe her way of saying it sounds like an old person’s blog).  However, what it kept coming back to was that it really is on point for me. 

I wanted a title that highlighted a few things that the blog is going to tackle as time goes on.

  1.        Quality – really I want the concept of quality to be at the core of everything that I’m going to talk about.   Well right there, the word quality is in the title twice, I have that requirement met in spades.
  2.        Process – in the past few years I've discovered that I’m a bit of a process junkie. I don’t like process for process sake even a little bit but I like digging into processes to find out how they work or don’t work.  What can be improved?  What would work better if it was just written down?  Simple processes followed regularly can solve almost every quality issue but without understanding the processes contributing to the issues you can’t find those solutions.  I think that the title as a whole contributes to this feature.
  3.        Management – I’m really a student of the environment that I live in and one thing I've found as I’ve moved around through management at different companies is that it really isn't something that people learn in a standard manner.  Managers are grown in so many ways and the quality of the way they interact with their jobs, their people and their companies suffer for this fact.  I think the least reliability to be found in job skills out there is in management skills.  I’ll be exploring this a bit as we go as well.

So that explains the title.  It doesn’t necessarily explain the url.  QAisdoes.

I, being myself, is probably the truest explanation for explaining but I’ll try to make it clearer anyway.  Most of my career has involved QA in some way or another and that’s where I identify the strongest.  And to me QA is does, pronounced ‘q. a. is does’ quickly, sounds cool to me.  And really, what can trump that. 
Well, it was also available when I went looking for that ID out there on the web.   I was able to get the url and the twitter name of qaisdoes without any issues.  Now the fact that my wife, when she reads the word, auto-tranlsates it in her brain to ‘QA-isodes’ as in a blog about QA episodes, didn’t help so very much, but still…it sounded cool.

So, in the next entry I’m going to explain a bit more of where I come from and where I’m going but for today, I’m signing off.