I know this thread is officially supposed to be finished. However, I hope you'll indulge me a chance to state my opinion. I've been away from email in Rødby DK since Thursday, so I hadn't seen this thread until last night. It was somewhat overwhelming to see what seemed like 100+ messages dedicated to a topic started in our book. Here's how I'd like to answer Mladen's questions:
<mg>1) This book is meant for performance analysts. Do you plan on writing one for management, as well? If performance analysts are held back by the damagement, they cannot perform any of the good work you described in your book. You have been both a DBA and a VP, so you have the credibility in both roles.</mg> There are a couple of ways to answer this. First, as I mentioned in the "Structure of this Book" part of the Preface, I tried to write Parts I and III in such a manner that managers and project leaders might read them. Second, I don't know long it usually takes a performance analyst with leadership ambition to make it to a project or department leadership role, but I would expect that many people reading this book today will be leading projects and people within the next three years. ...Not because of the book, but because of normal career progression, which I think goes very quickly in our Oracle segment of the IT industry. As I wrote the book, I hoped I was providing ideas that would help not just technicians but decision-makers to do better work. Frankly, I think the first step for a lot of people is to expect more, which is what a good bit of Chapter 4 is about. <mg>2) Do you foresee a change for the role of a performance analyst in an organization to be more of a technical manager and less of a computer geek?</mg> If by "computer geek," you mean a person with poor "big-picture" skills, then I don't think computer geeks have ever been particularly useful as performance analysts. I've certainly met performance analysts that have started out as geeks (I think I fit that category). But I've never met anyone who could successfully perform as a performance analyst who wasn't excellent at other things like communication, empathy, the "relevance thing," and so on. So your question requires some three-value logic for me to answer satisfactorily. Within the confines of your question, I have to say no I don't foresee that much of a change; I think we're already in the post-change state, but not really because we've been through a change. I do think that in the future, fewer customers of performance analysis services will be tolerant of mere "computer geek" responses to questions about how to improve a system's performance. I hope that the book will help more customers to distinguish between effective performance improvement work and ineffective performance improvement work. If awareness does improve as I hope, then it will raise the bar of quality that we have to cross in order to be perceived as producing deliverables of acceptable quality. I think that this whole notion of heightened expectations and better result quality represents improvement in our professional community. <mg>3) What will happen to the "traditional DBA"? Are we an endangered species? Should I be wary of the poachers?</mg> :) First, I'm not sure whether you've intended it, but I think moving from a question about performance analysts to a question about DBAs is a big shift in context. Performance analysts must necessarily have some DBA skills, but a Venn diagram of the two roles would have a very small overlap relative to the size of each role. I think more and more customers/clients/managers are starting to believe, as I do, that a lot of the labor hours that DBAs have expended in the last 15 years really aren't worth the money they cost. I'm talking about things like reorgs, I/O load-balancing exercises, hardware upgrades, hit-ratio chasing, and so on. I think a lot of this stuff was never economically sensible, but until recently, we hadn't figured out a good way to prove it. I think that in spite of the presence of several factors that are reducing the demand for DBA staff (economic austerity, data centralization, better product self-management, etc.), in the long run, the DBAs who will succeed the most in their careers will be the ones who are flexible enough to reinvent themselves as their environment requires reinvention. I expect that the DBAs who try to charge money for doing things that are ineffective (or just inefficient) will be the ones who feel the most pain. In these times of the shamans and snake-oil dealers to whom you refer, Mladen, I think that the indicated reinvention is to make yourself able to communicate at a level that is meaningful to the business with which you expect to engage. The difference I hope that Jeff's and my work makes is that it finally enables you to prove whether you're able to make more of an impact than the person you're competing against. One of the many motivations I had for writing this book is a similar problem to the one that you've described in your note below. I've worked in the shop where I proposed the Right Answer, only to have a drill sergeant tell me that no, his shop's not going to do it that way because a big copper and red book says you should do it differently. That day was a big splash of cold water. I have tried to react productively to it. :) Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com Upcoming events: - Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney - Hotsos Symposium 2004: March 7-10 Dallas - Visit www.hotsos.com for schedule details... -----Original Message----- Mladen Gogala Sent: Friday, October 03, 2003 10:15 AM To: Multiple recipients of list ORACLE-L I enjoy immensely reading Cary's book, but I have some questions that I want to ask publicly. Recently, I made a comment about Chris Lawson's book being a "Dale Carnegie book for a DBA" and now I see that Cary is also advising feeding the hungry business users ("buy him a sandwich"). It is true that many problems are consequences of inadequate communication, general lack of business knowledge in the "computer geek culture" and even disdain for it, but, in my opinion, many problems are also a consequence of incompetent managers ("damagers"), office politics, and hard times. Hard times present problems because people do not want to pay for a competent DBA but frequently hire a shaman or a witch doctor who "improves" on the system based on snake oil type techniques. If I cannot get more money then some bozo after a performance tuning course (example from Chris Lawson's book), why bother reading and investing into myself? A cynical geekish attitude and the "old boys" network will do just as well. Characteristics of the "performance analyst", as described in the book, are the ones of the field general (has the overview of the whole problem, motivates, manages the problem) but performance analysts frequently work for the drill sergeants who mostly care how are they dressed (you guessed it, I hate neckties) and did they show up early enough. Now, after having indulged into lengthy preamble, let's ask the questions: 1) This book is meant for performance analysts. Do you plan on writing one for management, as well? If performance analysts are held back by the damagement,they cannot perform any of the good work you described in your book. You have been both a DBA and a VP, so you have the credibility in both roles. 2) Do you foresee a change for the role of a performance analyst in an organization to be more of a technical manager and less of a computer geek? 3) What will happen to the "traditional DBA"? Are we an endangered species? Should I be wary of the poachers? Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Cary Millsap INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
