Friday, February 08, 2008

Why I Wear My Car for 2.5 Hours A Day

In case you didn't know, I am an aspiring crusty old fart. I've been in the workforce for a fairly long time, and I've been through the wringer (several times) we all go through as we're figuring out what we want to do when we finally grow up. I've had a number of very cool opportunities open up to me over the last several years, and I've had a bunch of great choices to make for career direction.

So with those opportunities in mind, why do I drive back and forth between Dayton and Columbus each day? As my 3.5 year old son would say, "Lemme tell you."

I joined Quick Solutions back in April, 2007 because I'd long wanted to work for Brian Prince and all the smart folks he's rounded up in his posse. Smart folks like Alexei, James, Jon, Arnulfo, Monish, and all the others who I'm not listing because I'm too lazy. I was of the opinion that the environment at Quick must be a great one because those folks are all smart and accomplished enough that they could work anywhere in Columbus, yet have been at Quick for some time now.

The last several months have only confirmed that opinion, and have cemented in my feeling that commuting 2.5 hours back and forth each day to work is a Good Thing when you're driving to a company with a supportive, enthusiastic environment. While things like Quick's amazing support of CodeMash and the developer community in general carry great weight with me, the absolute nail in the coffin has been the backing and help I've had while trying to rescue a project gone badly wrong.

If you've worked on more than one project in your career you've likely had some variant of the same situation: difficulties communicating with the client, changing expectations, technical issues on the delivery side, etc., etc., etc. All those add up to a bad spiral. You get in a spot where you and your team are working as hard as possible but still can't get things on the track needed to satisfy the customer. (Be clear: as with all death spiral projects, problems were on both sides of the aisle here.)

Things on this project were at a point where the client relationship was, at best, uh, difficult. I was working exceptionally long hours trying to meet a moving target and get the technical side of things back on schedule and it was wearing me down. Neither the PM nor I were having any success trying to get the relationship with the client calmed down, and it finally got to the point where we needed to escalate and get higher-level involvement.

That involvement came in a form I never expected: management immediately assembled a team to jump in and give us exactly the help we needed to get the project back on track. A high-level director took over all client communication, giving the PM and I a much-needed respite from a nearly poisonous environment. He also insisted on concrete direction from the customer, enabling us to focus on a clear goal instead of shifting expectations. When things were calming down he handed off all communication and PM responsibilities to our delivery manager who kept things clear and on track.

Additionally, a group of QA folks were handed off to us, filling a bad gap since the client hadn't been fulfilling their responsibilities in that area. The QA folks nailed down user and acceptance testing, helping us devs to shore up weak technical areas. (Never, ever let anyone tell you that good unit testing eliminates the need for a solid QA team. Ain't so.)

It took a couple months of hard work, and there were a number of difficult sacrifices made, but we got things nailed down and back on track. The client got back in Happy Face mode. The dev team finally got a commitment to a firm, unchanging set of features and was able to complete them well ahead of our estimates. The system, a complex technical manual viewer, got finished and rolled out to the pilot phase. That last point is especially important to me since years ago I was on a multi-year technical manual viewer effort which ended up getting shelved because of politics at the client's organization. (There's a long story around that one, and why I was so emotionally invested in it, but I'll save that for a different venue. Like over a beer if you're interested some day.)

Yesterday one of the devs and I had a successful handoff of the last bits for this phase. My sales manager forwarded on a mail from the client indicating they've accepted the system and are closing out this phase. That's just huge.

So here's one of the biggest things about all this: Not once, notonce, was any blame ever directed at anyone on my team. Management, all the way to the top, simply said "Mistakes have been made on both sides. Move past that, get the job done."

I have no doubt that at several prior employers I would have been thrown under the bus. Instead, what I got was calm and rational support, with never even a hint of finger pointing.

So there you have it. Companies like this are few and far between. That's why I drive 167 miles round trip each day. I wish it was less, but I'm happy to make the drive when I go to work with and for such great folks.

(While this post wasn't meant as a recruiting pitch, contact me via the sidebar link if you're interested in working at Quick. Especially if you work in Dayton and want to carpool...)

As Arnulfo said, your post echoes my thoughts and gives credence to my claims to friends that "Quick Solutions is the best consulting company to work for in Columbus", but that could probably be re-phrased as "best consulting company to work for in Ohio." Well done.

About Me

I'm the owner/principal of Guidepost Systems. I help lots of great folks figure out what works and what doesn't in the world of delivering quality software -- something I'm very passionate about. I'm also a Father trying to remain sane while trying to build great software, herd my kids around, fix school lunches and handle the yardwork. (And roast great coffee!)