A couple of weeks ago, I was saddened to learn that someone that I had worked with many years ago when I was a sales associate at Foley’s Department Store, one of the first jobs that I had worked while going to college, had passed away of bladder cancer.  When I started at Foley’s, Ralph was an older gentleman who had previously taken early retirement from a middle management position back East and had decided after moving to Tucson that he was not ready to be completely retired.  So, he embarked on a second career at Foley’s and I was fortunate to have him be the one to show me the ropes when I started my position there.  Ralph was a pretty amazing fellow in that he always saw the bigger picture.  Thus, when we he went to train me to be a sales associate, he took time to not only train me on what I needed to know to do the job at hand, he also took it upon himself to impart wisdom that he had learned over the years that he thought would be useful to me way beyond this sales position, which he knew I wasn’t planning to make my career.

As I reflected back on my friendship with Ralph after I had learned of his passing, one piece of advice that he had given me came to mind.  This was a piece of advice that I had used constantly throughout the 25 years since I worked at Foley’s and it was Ralph’s mantra.  The advice was “plan your work and work your plan.”  Oh, how simple that advice seemed at the time it was given to me, but that simplicity is very deceiving.  Almost every time that I have screwed something up over the course of my career, it can be traced back to a failure to follow this simple piece of advice.  It is not enough just to have a plan; you have to make sure that you actually follow it.  How many times do we have processes or checklists that we fail to follow because we think we know how to do the work faster or we think we know the process by heart only to have that come back and bite us because we left something out.  This advice has become golden to me over the years and constantly keeps me from doing stupid things.  I still find it amazing today that sometimes the simplest advice that we are given can be the most prolific.

In honor of Ralph, I wanted to share this story and bit of advice in the hope that someone might reap the benefits from it that I have. 

Rest in peace old friend, you deserve it.

Ralph Pennacchio 1930-2013

In the same way that the finest presentations involve much more than the simple relaying of information, the finest software demos are much more than just presenting features.

REMEMBER: The goal of a demo is to INSPIRE the audience to use the software/technology, not to teach them every nuance of software/technology.

I’ve spent the last 10 years learning how to give good presentations and to give good software demonstrations. Here are several tips to take your software demonstration from informative to masterful:

1. Know your audience

Whenever you start a demo, make sure you have a good idea what the audience is interested in. That way you can focus the attention of the audience upon things that actively engage their imagination. You really, really want the audience to be thinking about how they’re going to use the software that you are presenting. If it if you’re not presenting on something that they’re interested in, they’ll mentally disengage. In some cases you’ll even see them open their laptops and start to answer emails. That’s the last thing in the world that you want to happen.

In many cases, I’ll begin a presentation by asking my audience to tell me more about themselves. I want to know how much of their time is spent as a developer, as a DBA, as a designer. If nothing else, I can change the sort of examples that I use to be tailored specifically to the audience that are presenting to.

Truly bad software demos have problems. The code doesn’t work. The beta software crashes. The screen shows the dreaded blue screen. But that’s one thing. What you really want to avoid, is the truly mediocre software demo. The quickest path to a mediocre software demo is to simply show every feature and explain each in as much detail as you can. It’s like those games that sit in our closet that no one likes to play. Most all of these games are ones in which one person takes a turn while everyone else waits. No one has any fun except for the three or four minutes in which it relates directly to them.

2. Start, but only start, with an agenda

It’s always a good idea to inform your attendees of what you would like to present. What you present the agenda it’s a great idea to confirm that this agenda is what the audience is looking for. Before I learned to do this on a regular basis, I found that my presentation might contain two or three lengthy sections of my software demo which were completely uninteresting to the audience.  The customer is really numbed by this waste of time. It’s far better to tell the audience what you are going to tell them.

Here’s my routine when I start a demo. Confirm that your agenda is of interest to them and recheck the time constraints of the meeting. Then, get to what they are interested in. This flexibility also provides you the opportunity to inject other software demonstrations that are much more pertinent to your audience. Audiences love a presenter who can think on their feet and are flexible to the interests of the audience.

3. Skip the lengthy intro

This is a aspect of demonstrations and presentations that I struggle with. I worried a lot that I hadn’t demonstrated enough credibility with my audience. And so for many years of my technology evangelism role, I spent a lot of time telling the audience about myself and about the company. What I found over time though, is that audiences actually give you an initial dose of credibility. It’s up to you to maintain and even enhance that credibility through a strong demo and a good presentation. Better to have a very short introduction and get straight to the meat of the presentation.

Call out – Mouse Cursor Movement: It’s especially important to remember in online demos that there is usually a great deal of latency between what you do on your screen and what your audience sees on their screen.  So it’s important to remember to MOVE YOUR MOUSE SLOWLY AND THOUGHTFULLY! I’ve sat in online webcasts, and even in in-person events, where the mouse literally disappeared on one section of the screen and reappeared elsewhere because the presenter was moving their mouse cursor here, there, and everywhere.  If you want the audience to see what you’re doing with the mouse cursor, keep it slow.

4. Show what is pertinent

One of the most important things a software evangelist can do is to show the most important and pertinent take away of their software. Let’s you are trying to teach an audience about the extreme ROI (return on investment) of a particular kind of business intelligence strategy, it’s crucial that you figure out in advance what are the key takeaways that you would like your audience to remember. Typically in audience will only remember two or three very salient points about your demo. If the BI presentation spends the first 30 minutes showing how to build a report but never once mentions ROI, what do you think the audience will remember? Once you know what is pertinent to your audience and what you want the key takeaway to be, you should focus the rest of your energies on building an airtight demo that supports those takeaways.

You will see the inverse of this many times in a mediocre or poor demo. At the end of the demo the audience will feel like they have sat through product training, rather than a call to action that inspires them to use the product. I’ve sat through demos in which the presenter carefully walk through several different menus, tabs, and wizards. And after 30 minutes of that, I now knew HOW to use the software, but I still didn’t know WHY I would use the software.

In the worst cases, showing everything that your software can do may leave the audience feeling that it is too complex, too detailed, or too overwhelming for them to use effectively. Remember that a software demo is not design to train the audience. A software demo is designed to inspire the audience to use your products.

5. Don’t get sidelined

We usually get sidelined in our demos by two things: questions from the audience and “technical difficulties” a.k.a. bugs.

Questions from the Audience

It’s usually a good sign if your demo is provoking questions from the audience. However, you don’t want to demo to turn into free consultation to solve one person’s problem. Nor do you want to turn into fact-finding for one very narrow set of interests or to become the arbiter of some sort of political dispute between factions in the audience.

When taking questions, remember to repeat the question to the audience. This ensures that you fully understood the question, that the questioner asked for what they meant, and that if there is any recording going on the question will be picked up by the recording system.

But my typical rule of thumb is to only spend a couple minutes on a single question and questioner. Once a single questioner goes beyond a couple minutes, you can usually tell if you’re heading for the sidelines. It’s at that point that I asked the questioner if we can take the question off-line and come back to it afterwards so that everyone else can benefit from the time that we have set aside right now.

Technical Difficulties

Another form of sidelining are bugs in the software and outright crashes of your demo environment. Many times this simply can’t be avoided. This is especially true if you are demoing a beta version of the software. But there are couple important things to remember if you are sidelined by a bug or crash.

First, mention if you’re using a beta and that it might not be fully stable. Also, be sure to mention that the software WAS stable when you prepared the demo. Second, test your demo after conducting a full reboot of your demo environment. I’ve seen many demos crash because the presenter made other changes in the environment but only tested for the software demonstration itself. Third, Don’t draw attention to bugs that you encounter during the demo, especially if they’re just cosmetic. It’s important not to do things like slap your four head and exclaim “what the hell is that?” If it’s a bigger bug that hampers or interferes with functionality, you might state that it’s normal functionality is… XYZ. Finally, if you experience a major bug or crash, immediately disconnect the projector or the desktop sharing application. There’s nothing worse than seeing a presenter struggle with the bug in front of the entire audience.

6. Hit the jackpot

All good jokes have a punchline. All good action movies have a climax. All good newspaper stories have a headline. Your demo needs to have a jackpot, where the audience can clearly and immediately see how your software pays off.

Let’s say you’re doing a demo of the new columnstore features in SQL Server 2012. You could spend a lot of time showing the conceptual underpinnings of a columnstore index. You could show the state was to create columnstore indexes, to modify them, to drop them. You could admonish the audience and ways to build read-write systems so that they can easily get data into and out of columnstore indexes.

But what’s the real payoff of a columnstore index? It is incredible fast for a particular kind of scenario on SQL Server. So in this example, your jackpot is to show how difficult that scenario is under normal circumstances and then immediately show how easy and fast it is with the columnstore index. Bingo! Your audience is hooked. They immediately see why they want this. There inspired to start using it. Now, they want to figure out how to use it and want to know when and under what conditions they should use.

Are you an SC, technology evangelist, or technology presenter?  What are your tips for a better demo?

-Kevin

-Follow me on Twitter

I just got this email from LinkedIn about my profile (that’s http://www.linkedin.com/in/kekline in clear text).

Hi Kevin,

Recently, LinkedIn reached a new milestone: 200 million members. But this isn’t just our achievement to celebrate — it’s also yours.

I want to personally thank you for being part of our community. Your journey is part of our journey, and we’re delighted and humbled when we hear stories of how our members are using LinkedIn to connect, learn, and find opportunity.

All of us come to work each day focused on our shared mission of connecting the world’s professionals to make them more productive and successful. We’re excited to show you what’snext.

With sincere thanks,

Deep Nishar

Senior Vice President, Products & User Experience

P.S. What does 200 million look like? See the infographic

What does that mean? Two things: 1) that the much more famous actor of the same name is not very good at social media, and 2) I’m better at social media than I thought.

It means one more thing – I should be grateful for your support and interest.  THANK YOU!  Please let me know what else I can do to help you grow in your SQL Server technology skills, database & SQL skills, and IT leadership & professional development path.

-Kevin

-Follow me on Twitter!

So, January came and went, and no post from me.  I continue to suffer from writer’s block, but I’ve finally cobbled together enough ideas that I feel like I can put a couple of quick posts out there.  I’m still struggling with learning how to manage a technical team (MaTT) as opposed to being a technical person, but here’s another concept I’m beginning to grasp.

You have to start somewhere.

When I began managing my team, I was tempted to rush in and save the day.  I know where a lot of the problems are, and I know which ones are big, and which ones are not.  I kept thinking that if I could just motivate the team to start attacking the problem, then we’d be sitting pretty in a year.

I was wrong.

Most people are already motivated to do their jobs; if they’re not, then they’re in the wrong position, and it’s hurting them as well as hurting the company.  What a team is usually looking for in a manager is to help them make priority decisions, and to back them up when they need things to change.   Here’s the conundrum: Technical people often (logically) focus on changing the things that hurt them the most.  Your DBA may say “I keep having to babysit this query for the boss because it’s slow, and it’s slow because the developers don’t know how to normalize a database; can we refactor everything?”.  Your developers may say “If we had more time to rebuild everything, we could fix that query; can we hire another person or put these features on hold so we could tune everything?”.  Your boss may say “We need to make a profit; what’s the most cost-effective way to manage our database architecture moving forward?”

If you focus your energy on addressing the technical issues without giving consideration to the profitability of your company, you’re spinning your wheels.  However, you MUST figure out a way to ease the pain of your technical team by addressing their concerns.  It’s no secret that I’m a Lean/Agile kind of guy; I truly believe that these philosophies can help balance the scales between support/development/operations, but you have to start somewhere.

“Somewhere” for me is the small fixes; don’t tackle the big projects head-on.  Focus on being successful at a couple of small things (e.g., reduce the number of support calls in a measurable fashion, or refactor some small but essential bit of code).  Make sure that these changes are measureable, and make sure that you report the changes to your boss AND to your team.  This accomplishes two things:

1. It shows measurable progress (in my experience, bosses love metrics), and
2. It encourages your team by giving them a couple of quick successes.

If your team doesn’t see progress, then in their mind, “nothing is being done”.  Your boss wants to know how you’re improving efficiency and effectiveness in terms of dollar signs; your team wants to know that they’re solving a technical problem.  Make sure you can address both of those needs.

More to come.

I always seem to get a question or two along the lines of “What’s it like on a SQLCruise?” as I present at various conferences, SQL Saturdays, and user group meetings.  Since we just finished up the 2013 Miami SQLCruise, I thought it’d be a good time to recap so that you can judge for yourself if you’d ever want to do it yourself.  Personally, I think that Tim Ford (Twitter | Blog), together with his wife Amy, are doing better than ever in making the cruise both a top-quality learning experience and fantastic social experience.  I’ve heard from many attendees that they learned enough in the first day or two to make the whole trip worthwhile and, keep in mind, some of these attendees paid for the trip out of their own pocket.

Update 05-Feb-2013 at 7:22 PM: Loads of pictures at http://sqlcruise.com/cruise/past-cruises/sql-cruise-caribbean-2013/.

SQLCruise Experience

Now that I’ve told you about the grueling educational side of SQLCruise, did I mention that we do all of this ON A CRUISE SHIP IN THE CARIBBEAN?!? The cruise ships are, if you will, an enormous Vegas hotel on the water.  There are casinos, a constant parade of entertainment, live music, comedy, pools and water slides, discos and dancing, live game shows – the works.  Ask Neil Hambly (Twitter | Blog) about the dancing!

SQLCruise Cost

Another, less tangible benefit of the expense of the SQLCruise is that the instructors are never unable to answer your questions, compared to many training centers whose trainers have never actually had a career built around the topic they’re teaching.  It’s a huge difference.

It was early one morning and I was working on a production deployment to add a new Subscriber to an existing Publication. A routine task and one that I had performed many times before.

With SSMS open in front of me, I highlighted the relevant portion of my deployment script (sp_addsubscription …), double checked my query window had the correct connection and hit F5 like a boss.

Whilst I waited for the SQL magic to happen, I reached over and grabbed my still fresh coffee, proudly basking in my hard earned seconds of freedom. Glancing back at SSMS my query was still running. More coffee then….

Checking again, the clock read 15 seconds. This is strange I think, staring intently at the output window anticipating those beautiful words “Query executed successfully.” at any moment.

20 seconds, still nothing.

25 seconds. Okay, something is not quite right here but what? This has never happened before. Dumbfounded that anything could possibly be amiss I decide to simply give it some more time whilst I think on it.

Suddenly I’m interpreted by a bombardment of instant message pop-ups and the sound of my desk phone screeching at me like a siren. I grab it and ignore the IMs.

“Good morning John speaking”, I say calmly, although bricking it on the inside in anticipation of what’s coming.

“Hi John, we’re seeing a drop in the booking trend….”, states the caller from the operations team.

Instantly my world freezes. I become strangely aware of my own heart beating, accompanied by a sinking feeling in my gut.

“Okay, looking into it now”, I reply.

I open a new query window, type “sp_WhoIsActive“ and hit F5. I stare as the results pane grows before my eyes revealing several hundred blocked spids. They are all customer booking related(think people trying to buy stuff), queued behind my replication query. WTF!

Customer experience is our number one priority and so I immediately make the decision to terminate the lead blocker by hitting the red stop button(Cancel Executing Query) at the top of the first query window. It stops immediately, good.

I execute sp_WhoIsActive once again and am greeted with even more blocked spids than previously. Why is the replication spid still open, and blocking? Blast!

I flip back to the replication query window, type ROLLBACK and execute it.

“Command(s) completed successfully.”

Okay good and I confirm the same via sp_WhoIsActive, this time no blocked spids reported. Excellent, all previously outstanding activity had completed successfully and normal business operation had resumed.

When A Good Result is Not Good Enough

Some of you may have read my story and be thinking well done old boy, good job there getting things sorted but you’d be wrong!

A lot can happen in a couple of minutes and I was unprepared for what did play out on this occasion. Sure it was an unpredictable event that I responded to quickly, avoiding any loss of revenue. The business folks may have chalked it up as a win but I sure have not. If you ask me, I got lucky.

I was overconfident and this lead to my being complacent. It never even occurred to me that something could potentially go wrong. I’d performed the task so many times before that I simply assumed this time would be no different.

My overconfidence on this occasion had caused me to ignore one of the most vital DBA survival skills, Thinking Defensively.

How You Can Adopt a Defensive Mindset

Both as a reminder to myself and so that you too may avoid this particular trap of overconfidence(complacency), I want to share here with you my key points for adopting a defensive mindset.

Our database environments are business assets and as DBAs it is our responsibility to guard and protect them.

Before you implement any administrative tasks whether it be deploying a set of database patches to your environment, modifying table data or creating new objects, whatever changes you plan to make, I advise you to always adopt a doomsayer’s frame of mind before carrying out the implementation.

We all spend a lot of time bolstering our knowledge and developing our skills. It’s natural to reach a comfortable place in our assessment of our own abilities but don’t let this develop into overconfidence, which can lead to complacency if not careful.

Adopting a defensive mindset such as answering these questions, together with keeping a look out for signs of overconfidence both in yourself and your team, will help you on your own path to being an outstanding data professional.

Thanks for Reading. Make sure you don’t miss my future posts! Subscribe and get posts delivered direct to your Email inbox for Free.

Check out the Professional Development category on my blog for similar posts.

As a former mentor Christian is used to me asking him all sorts of random questions, but this time it’s going to be published online. I’d also like to thank you for allowing me to be a technical reviewer in your latest book: Professional SQL Server 2012 Internals and Troubleshooting.

Before we start on the main part of the interview around being an established author, tell us all a little bit about yourself.

I’m 35 years old, married with two great kids, and I run the consulting practice at Coeo — a Microsoft Gold Partner based in the UK with a great deal of expertise in SQL Server. I enjoy supporting SQL Server community events and I’ve co-authored five books on SQL Server.

How did you start in SQL Server?

Sometime around 1998 I was a young, confident contractor focused on optimising NT4 domain environments.  I’d transitioned from Novell Netware over the previous couple of years as Microsoft was the new, cool kid in town for managing directory services but I started to feel like I needed to specialise further and Microsoft Exchange 5.5 was the natural evolution of my skills.  A contractor friend of mine already knew Exchange and convinced me to pick up SQL Server instead so we’d have all the bases covered — back then the application tier was only really Exchange and SQL Server so I bought a book on SQL Server 6.5 and never looked back!

So, you’re an MVP, MCM and an MCA! Which if these would you say was your biggest accomplishment?

MCA was certainly the hardest so if I had to pick one it would have to be that but it’s definitely the least well known.  I’m a big fan of the MCM though and encourage all my team to pursue it which has had a really positive effect for the team and for the business because we now have more SQL Server MCMs than any other Microsoft customer or partner in the world. The best bit about that though is that they all passed the MCM because of the job they do at Coeo every day. Being an MVP is an honour and a privilege but I don’t see it as an accomplishment because I don’t do anything specific just to be an MVP, it’s an award for doing what I do anyway.

How did you first become involved in a book project?

A good friend of mine had been involved in a BizTalk book 6 or 7 years ago and I approached his publisher to say I was interested in writing about SQL Server. A few months later I was invited to join the authoring team for Professional SQL Server 2005 Performance Tuning and that became my first published work. My mum was very proud!

You have been a lead author for a number of books now, how does the role of lead author compare to that of a contributor?

It’s really, really hard and you never appreciate the role of the lead author until you’ve been on both sides of the fence or you write with someone that isn’t good at it.  The lead author owns the structure of the book so the chapter titles and themes come from them but a good lead will take a very active role in all the content of the book.  If a multi-author book reads like the authors worked on it all together, it’s usually because the lead author has done a good job in editing the chapters to ensure consistency and to add helpful cross-references. The lead author is often the only technical person that reads and edits the whole book.  It’s a tough job that has very little visibility but it’s the only way to ensure the project stays true to the original vision.

Being a co-author or contributor also has a lot of challenges as your role can leave you feeling isolated when you’re only involved as you need to be; you might write a chapter early in the project and then not have anything to do for 6 months when all of sudden you get a load of work back on a tight timescale.  Technical feedback can also be hard to take during the project when you’re an expert in your field and it takes practice to emotionally detach yourself from it and edit your work to make your points clearer. A technical editor represents the intended audience and while you might disagree with their feedback there’s a good chance your readers might feel the same and you now have an opportunity to pre-empt those concerns by editing your work before it’s published.

How do you go about building a crack team of authors for a book such as Professional SQL Server 2012 Internals and Troubleshooting?

You have to know a lot of good guys that you can trust to work hard and weather the up and downs that are a part of every authoring project.  The success of the SQL Server 2008 version of the book helped a lot to recruit the team but the fact that the author list changed so significantly from the last version of the book reflects just how emotionally challenging it is to be an author outside of your day job.

You’ve worked on a couple of different kinds of technical books, is there a particular type of book that is easier to write than others?

No — I think you always feel like the grass is greener.  When you have a blank piece of paper you yearn for some structure to help guide you but when you’re given structure it can feel restrictive and less creative.  When I wrote for an exam guide it was hard to make basic concepts sound compelling when they didn’t excite me anymore and writing sample exam questions was a horrible experience; creating valid wrong answers is a long, painful process that produces a very unimpressive output.

On a more positive note, I think writing about something you don’t know very well is probably the easiest from a motivational perspective because you’re learning as you go and your enthusiasm seeps into your writing.

Do you think you’ll take a leaf (or possibly a page being a SQL interview) out of Mark Russinovich’s book and write a fiction book?

It’s funny you should mention that, I have a passion for historical fiction and narratives and renaissance Italy is a particular interest of mine. I have an idea for a series of books set in that period that I’m slowing developing but it’s a long term project and doesn’t have a compelling event that is driving a timescale so I think it will be 5 to 10 years before anything solid comes from it.

We’ve spoken at great length before about your writing style and how easy you make it to break down and comprehend complex solutions. What process do you go through to make this happen when explaining a concept?

I like to think it’s because I need things to be simple for me to understand them and once I’ve broken something complex down for myself, writing is just the process of passing it on for other people to benefit from.  It works for me and people seem to respond positively to my writing so that’s the process I try and reproduce as often as possible.  I also use the “would my Mum understand what I’ve written” test to measure the readability of my work; if you need to be an expert to understand what I’ve written then I’m not doing it right.

I remember you telling me the story of your daughter drawing you a picture of a Princess to put in your book. How do you cope with running a company, having a family and on top of that a major project like a book?

It’s certainly not easy to juggle those priorities. I’m lucky in that writing SQL Server books has a value to my business from a marketing perspective so that helps to justify some of the effort but the hardest part is managing time with your family.  Its manageable if you’re very efficient with your time but I find that inspiration for writing comes in bursts and I have to keep going when I’m in the zone so getting your family to buy-in to the end goal is absolutely critical. Ultimately, a writing project has a fixed timescale so it’s not like a hard job that has no definite end but it does take about a year to create and finalize the content which is long time to lose so much free time.  I’ve had to write during two family summer holidays which is a really hard thing to do so I try and involve my kids as much as possible and we hunt for Daddy’s book whenever we see a bookshop. If they don’t have it on the shelf, then it “must have sold out”; my kids must think it’s the most popular book ever written

If somebody such as myself wanted to take the jump and go from blogger to author what would you recommend?

Approach a publisher for books that you like and tell them that you’d like to become an author.  I’d definitely recommend being an author on someone else’s book for your first project to get a feel for the level of work that one or two chapters requires. Writing severely impacts your free-time and it’s vital that you complete whatever you commit to so start small and give yourself the best chance of success.

Without giving too much away what are your ambitions for the company in the New Year?

I enjoy developing people and helping them to discover and use their strengths to do their best work so I’m looking forward to doing more of that as we continue to grow Coeo this year and hire more great people.

From a company perspective, we’re usually associated with Mission Critical SQL Server platforms but we also do a lot of great work in other areas like Private Cloud and Business Intelligence which we’re less well-known for, so I really want make those projects more visible this year.

Thanks for your time Christian it’s been a pleasure as always, all the best for the New Year.

You can find out more about Christian Bolton at his blog http://sqlblogcasts.com/blogs/christian/

You can find out more about Coeo’s services at http://www.Coeo.com

Following this post from a syndicated source and want to read other interviews in the series? The anchor post for this series can be found here.

Follow Richard here:

Related posts:

1. New Year Aspirations – Gavin Payne – MCA
2. New Year Aspirations – Annette Allen – WiT
3. New Year Aspirations – Jonathan Allen – DBA

Posted in Professional Development, SQL Server Bloggers | Comments Off