Some days blogs just write themselves...
...and today is one of those days. :)
First, if you don't already receive Steve Jones' excellent daily editorials (from SQLServerCentral.com), click the link immediately and sign up. It's a free site and there's lots of good stuff there. I enjoy the afore-mentioned editorials a lot - Steve does a great job.
Today's editorial is about making IT better. If you are an IT manager, stop what you are doing and read this editorial and the articles to which it refers. It's that important.
Go ahead - I'll wait.
Ok, back now? Weren't those articles interesting? I thought so too.
Second, an email was waiting in my Inbox this morning from Fernando G. Guerrero - CEO of Solid Quality. It was in everyone's Inbox, addressed to all of us at Solid Quality:
Go to http://maps.google.com
Select "get Directions"
From "Madrid" to "Seattle"
Click on "Get Directions"
Look at step #40
:)
Cheers
I've had my share of experiences with PHBs (as Frank likes to call "Pointy-Haired Bosses") and remember how it feels to identify with comments made in the eWeek article. Having those experiences makes me really appreciate working with Solid Quality because, frankly, that crap doesn't happen here.
From what I've seen it only takes one individual in an organization to spread groupthink. And once it takes root, groupthink spreads like weeds in a garden.
Joel Spolsky's Two Stories illustrates the benefits (including profit) of empowering employees.
Although I can sympathize with people interviewed for the eWeek article, like Joel I'm no longer in that position career-wise.
I think the experience of having-been-there made me a better manager when I managed DBAs at a large company. I remember my first review said something like "Team members will take a bullet for Andy." I appreciated that because it was something I cultivated. I wanted to be a "follow me" leader and not a "go and do that" leader.
The eWeek article contained quotes from folks who lamented being reactive - the "fire-fighting" role their jobs had become. The DBA Team I managed was in that spot when I became manager. The situation was indeed dire. Not only was the team spending an inordinate amount of time fighting fires, we were losing the fight. The amount of time required was increasing.
The stratgey I proposed sounded simple: First we will fight fires better. Second, we will engage in fire prevention.
As a team (I cannot stress this enough) we brainstormed ideas about doing a better job fighting fires. We hit on a couple key concepts - communication and cross-training. Individuals on the team were experts in certain applications. When something "bad" happened with Application "A" the go-to guy was "Joe". When Joe fixed the issue, he started sending an email to the group explaining the fix. The plan was to post the fix on a SharePoint portal, starting a Knowledge Base. The email soultion worked well enough (Outlook is searchable) that we never implemented this fully. Communicating worked - really well. We expanded the knowledge among the group and everyone felt better about being on call, etc.
Doing a better job of fighting fires gave us some breathing room to address fire prevention. We implemented a suite of light-weight tools that allowed front-line support personnel to make changes to data. It wasn't a perfect solution, but it allowed us time to fix underlying bugs in database code, instead of spending all our time correcting the bad data generated by bugs. Yes, we had to admit we made mistakes. Test Engineers had to admit these mistakes weren't caught by testing. But that challenged our Test Engineers to write more robust custom tests - and these tests found their place in the regression suite so it served to strengthen quality overall. And quality improved - but that wasn't all:
The paranoia and threat level disappeared when we all admitted mistakes were being made. The walls dropped and people loosened up. It went from being an ok place to work to being fun.
Most importantly (for the business anyway) was the fresh attitude allowed more freedom, and developers love freedom. Freedom was channeled directly into creativity, which developers (database and application) used to produce applications that literally blew management's mind! All of a sudden we had applications doing things they weren't slated to do for months. Performing, scaling, the sorts of things that applications do to make a company money.
What happened at this company? Where are they now? Apologies for a sad ending...
IT management - the PHBs - were threatened by a technology they did not understand: .Net. Their paranoia expanded and they literally "stopped all development" within three months of the application setting new corporate records for electronic processing. I honestly believe they would have pulled the application out of production had it not performed around 100 times better than the old application. As it was, they clamped the screws on the team that built it and, understandably, that team dissolved within six months.
But hey, the threat was mitigated.
It doesn't have to end this way. There are still cool companies out there. Sadly, they will not all stay cool, but you can enjoy the coolness while it lasts. You can use this time to grow yourself, become better at what you do, more valuable to another cool company. Or you can start your own cool company!
IT managers would do well to pay attention to Solid Quality. Solid Quality attracts MVPs and authors and treats us well. All businesses face challenges and SQL is no exception. What is an exception is how they handle challenges.
Whether you're a CxO or shift supervisor, you can treat people fairly, communicate more / better, and - for goodness' sake - do what you can to see those in your charge are allowed to do their job unencumbered by stupid rules.
:{> Andy
Technorati Tags: business software PHB pointy-haired boss SQLServerCentral Steve Jones Frank La Vigne