July 15, 2015

Nine Years - And That's All

Nine Years - And That's All Folks!

I recently marked my nine-year anniversary at my current company. Actually, it's now my former company. After nine years, I left.

It was a difficult decision, but for me, it was the right one. It was time to move on to the next phase of my life.

It's hard for me to believe that I was there for nine years. Yet when I look back at all we accomplished, it sometimes seems like far more:

  • When I started, there was no real Quality Assurance Team. Whatever small bit of testing occurred was being performed by Product Management folks in their spare time. Since then, we created a terrific team in the US, augmented by some good contractors, and a small team in India as well. copyrightjoestrazzere
  • Bugs were not being tracked in any central system. There were a few emails floating around, and an occasional spreadsheet, but no place where people could go to find the status of bugs. Most recently, we used Bugzilla, and people grew tired of me asking "Do we have a bug report for that?"
  • Lots of people came and went over the past eight years. Initially, the biggest change was the prior CTO being replaced by my boss.  Since then, many other folks left.re
  • We changed a significant portion of the infrastructure behind most of our applications. It became far more scalable and sustainable, although we continued to make changes.
  • We formalized many of our development and testing processes, and created the necessary processes where none existed before.
  • We went from fighting fires every day, to a much more stable, dependable set of systems. Where before many of our systems needed manual, hands-on attention every day, most ran in a much more automated fashion.
  • The product lines changed over time. We weeded out some products that were single-customer, poorly funded products. We created some new products, and retired others.
  • A few years ago, we were purchased by a much larger corporation. It wasn't all bad, and it wasn't all good. The volume of big-company administrivia started out small, but increased, and it continued to increase.
  • My QA Team was reorged a few years ago. At that time, my current boss reported to someone in the corporate office, rather than the local General Manager. She also had responsibility for more than just our local division. That meant we had even less contact with my boss than before.
  • As part of reporting up into corporate, we were required to use all of the formal corporate time-reporting, project management and metrics systems. For me, it was a lot of time spent on administrivia, rather than more productive work. I tried hard to minimize the impact on my team, but I couldn't eliminate all the overhead.
  • We recently completed a massive project to move our production infrastructure into the corporate facility. We purchased new hardware, new software, database upgrades, etc, etc. We embraced new processes for security, administration, installation, and support. And of course we often "improved the applications" as we migrated them. With almost all the variables being changed at the same time, this was a big task for everyone involved, and a very big testing task. It was "interesting", and a huge drag on our time for building and testing revenue-producing applications.
  • We experimented with a few Agile projects. They took many wrong turns, took longer than anticipated, and didn't end up in viable products. Still, we learned a lot.
  • Last year, my QA Team was reorged yet again. This time, I reported directly to someone in the corporate offices in New York, rather than into the local Development group. The new boss had no real background in QA at all - he was primarily concerned with Governance. That was rather different than any other place I had ever worked. No time for any testing - for me it was basically all project management, all the time.
  • Eventually, it became clear that the role of a QA Director in this company no longer fit with what I believed in or what I wanted to be doing.

Lots of work, lots of changes. All in all, it was a pretty good nine years. But now that company is behind me.

I'll really miss all of the local people I worked with over the years - they are a great bunch of smart, hardworking people who care about quality. I'm sure they will all continue to be successful.

But I won't miss the administrivia, the many processes, the long string of estimates that were required, the ever-growing number of metrics, all the purported "Best Practices", and the seemingly-endless series of reorgs.

I'm going to take a step back for a while, to relax a bit, to evaluate things, and to spend more time with my grandchildren. I have a lot of projects I want to try, a lot of reading to do, and a lot of writing ahead of me (I hope). Stay tuned!

This article originally appeared in my blog: All Things Quality
My name is Joe Strazzere and I'm an experienced Quality Assurance professional.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://AllThingsQuality.com/.


  1. Hi Joe

    I would like you to tell us more about the point "We experimented with a few Agile projects. They took many wrong turns, took longer than anticipated, and didn't end up in viable products."

    What went wrong exactly and why it was not a good idea? From what process/methodology did you embrace before agile, and what process did you end up embracing?

    Thank you!

    1. Seems like a reasonable thing to do. I'll write a new post talking about our "Experiments in Agile".