Setting mentoring ground rules

One of the things I always recommend in the first newsletter of each year is to try to get a mentor. On the flip side of that is that one of the most rewarding things you can do in your professional life is to *be* a mentor to one or more people. I mentored more than 50 people back in 2015, and I think I’m going to do some more mentoring, starting in the Spring (watch the blog for details – but definitely not 50 again!).

If you’re going to be a mentor, I think it’s very important to set ground rules. One of my mentees from 2015 just sent me email saying he’s going to be mentoring this year (*so* cool to see people paying it forward!) and asking about the ground rules I set. I’ve been mentoring people for almost 20 years and I think you need to cover at least:

  • How communication will work, and expectations on both sides for how long a response may take
  • How to end the relationship
  • Which areas are fair game, and which aren’t (e.g. I wouldn’t answer SQL Server questions with the 2015 group)
  • Statement of confidentiality and trust
  • What actions will cause the relationship to end
  • How not to react to things I’ll say (e.g. I’m very blunt and honest – the whole point of a mentoring relationship is clear feedback)

That way there’s no ambiguity and you both know how things are going to work.

As an example, here’s the set of rules I sent to all my mentees to ‘ok’ before I’d move forward with them:

Lots of housekeeping, ground rules, and expectation setting in this email so PLEASE read through this email and let me know whether you’re comfortable with everything I say below. If not, for any reason, just say so (you don’t need to say why) and we’ll walk away with no hard feelings. I also need to know that you’re getting my emails. Once I hear back from you, I’ll send the kick-off part 2 email.

As I mentioned in the original blog post, I do all mentoring over email. I have two reasons for that:

It makes the whole process asynchronous, which means there’s no immediate pressure to respond and so is easier on us all. It also means we can think about responses for a week or two, and that’s especially useful as I’ve got several long trips without Internet this year.

I really don’t like talking on the phone. Phones are a necessary evil, but they don’t make for well-though-out discussions.

Once I’ve had a response from you so I know my email’s getting through, whenever I send an email out, I won’t chase you up to reply to it. If you go dark for, say, a month, I’ll assume you’re no longer interested or you’re done with mentoring. I’d appreciate a note to that effect if you decide that though, so we get a positive closure.

You can expect responses from me within a week or two. If a longer response will be delayed, I’ll let you know. If it goes more than two weeks and you haven’t heard from me about a reply, please ping me as your email might have been lost or (rarely) I might have accidentally deleted or mis-filed it.

I take all mentoring relationships seriously, and I expect you to as well. You’re going to be opening up and telling me things about yourself that you might not share/have shared with anyone else (such as hopes, failures, negatives, positives, weaknesses, strengths, work problems, family problems, whatever). Anything you tell me will remain strictly between us, and only us.

You can publicize whatever you want about the mentoring relationship and any advice I give you, unless I (rarely) tell you something is in confidence.

Do not tell me anything that is illegal or unethical (e.g. you cheated on a certification) – that will cause me to end the mentoring relationship immediately. No second chances on this. If there’s something we’re discussing that is making me uncomfortable, I’ll let you know.

I will not discuss politics or religion 1-1 through email. Sheep, diving, and electronics are fair game though :-)

We’re going to get to know each other better over the rest of this year. Feel free to Facebook friend me if you want – no pressure – I don’t care either way, but some people don’t like to presume to ask.

I will be blunt and honest with you; I don’t sugar-coat things. You’ve probably already seen that from me on Twitter and on my blog. Getting straight to the point in any discussion is the easiest way to get a point across clearly and with little or no ambiguity. Please don’t ever take anything I say to you as trying to be nasty, belittling, or destructive criticism – that’s not how I work or who I am. The whole point of a mentoring relationship is to be constructive, so please take everything I say with that in mind. If you find yourself having a hard time with that, let me know and we can work on that too. And feel free to disagree with anything I say too, you won’t offend me.

As I mentioned in the original post, this isn’t about me answering SQL Server questions for you. That’s what forums, Twitter, etc are for. Although I can help you figure out how to grow skills, this isn’t a mostly technical conversation.

This may seem like a lot of rules, but I’m very easy going. At the same time I like to have expectations set and ground rules agreed to so we all know where we stand – this is a big time investment from all of us, so it pays to get everything out in the open right at the start.

If that all sounds cool to you, let me know and I’ll send the second part of the kick off.


Feel free to use any or all of this if you’re going to be a mentor, or ask for something like this if you’re going to be a mentee.

The main thing to bear in mind is that both mentoring and being a mentee should be rewarding, and not feel like a chore or a slog. Setting some rules up front will help define the relationship and provide a clear way to end it if things aren’t going well.


TSQL Tuesday #96: Folks Who Have Made a Difference

It’s been almost three years since I wrote a T-SQL Tuesday post (shame on me!), but this is one I definitely want to contribute to. It’s hosted by Ewald Cress and is about “the opportunity to give a shout-out to people (well-known or otherwise) who have made a meaningful contribution to your life in the world of data.”

There are three people I want to call out, in the order that they came into my life and helped me out.

Firstly, Dave Campbell, who left Microsoft as a Technical Fellow last year after 22 years in Microsoft’s world of data. When I joined the SQL Server team from DEC in 1999, Dave had already been there 5 years and was the Development Lead of the Access Methods team in the Storage Engine. Dave has always been a brilliant engineer, a calm and insightful manager, and a willing mentor. He taught me a lot about engineering, managing crises, and being a manager. I was amazed in late 2003 to find myself becoming the Dev Lead of the Access Methods team and stepping into his shoes.

I’m sad to say that over the years I’ve lost touch with Dave, but I’m forever grateful for the influence he had on my professional career.

Secondly, my great, great friend Bob Ward. I first met Bob a few months into my tenure at Microsoft and continued to meet and swap emails around Product Support matters but I didn’t start working closely with him until a few years later. Bob was the inspiration for me to want to help customers: to help them find why SQL Server was broken for them, to fix bugs, and to make sure that people in Product Support were saying and doing the right thing for customers. He inspired me because that was his passion, and his entire job. We’d spend many hours on the phone each week and through emails discussing things and sorting stuff out. This led me to champion adding an entire pillar to the new engineering process that came 2/3 through SQL Server 2005 development: supportability, making sure all facets of the SQL Server box could be understood and debugged by Product Support. This involved driving and coordinating all development teams to build and deliver training materials on how SQL Server worked, how to debug it, and how Product Support should approach it AND build into each area the tools, messages, and hooks to allow such investigations to be done.

Bob and I (and Bob’s lovely wife Ginger, plus Kimberly) continue to be close friends and we get together whenever we can (which is a lot more frequently now that Bob’s in the product group and up in Redmond regularly). Of all the people I met at Microsoft, Bob made the greatest contribution to who I am today by inspiring me to help people.

Thirdly, my wonderful wife Kimberly, who helped me develop my speaking skills and made me ‘less Paul’, as she puts it (learning humility, presenting with empathy, and removing a lot of the arrogance with which I left Microsoft). I’d just started presenting when I met Kimberly at TechEd 2006 in Boston and I had a *lot* to learn. I quickly adopted her style of presenting, which works for me. This involves going against one of the central things people are taught about presenting – few bullets with few words. We both (and all of SQLskills) have dense slides with lots of bullets. This is so that people can read the deck and tell what we’re talking about, rather than having pictures of kittens, trees, race-cars, whatever, which tell you nothing several months later. Some of you will disagree – each to their own. The central theme though is making sure that people have learned and understand how and why things are, not just what the answer is.

The other thing (among so many in my life since meeting her) that I want to thank Kimberly for here is for SQLskills. Kimberly’s been a successful business owner since the early 1990s and since she started in 1995. It was incredibly cool that I could leave Microsoft in 2007 and walk straight into a thriving business with a stellar reputation and start teaching and consulting.

You’ll notice that I didn’t say ‘lastly’ above – I said ‘thirdly’. There are two more groups of people I want to give a shout out to.

Firstly, the incredibly-talented group that work with us at SQLskills (Erin, Glenn, Jon, Tim, and previously Joe Sack – another great friend). I continually learn new things from them and I’m sincerely thankful that they chose to work at SQLskills for so long (Jon for 6+ years, Erin and Glenn for 5+ years, and Tim for almost 3 years). They’re all experts in their specialties and immensely capable people, who keep me on my toes and who are all wonderful people and friends.

Lastly, and most importantly, the people who’ve had the most influence in my data world are the SQL Server community; my fellow MVPs, all the MCM community, everyone who’s come to a class, attended a session, read a blog post or article, watched a Pluralsight course, posted a question, or tweeted on #sqlhelp. A huge part of my personality is helping people understand SQL Server. It’s what drives me to blog, to answer random email questions, put together the waits library, teach, and more.

You’ve all helped shape me into the person I am today in the data world, and I thank you sincerely for it.


50 online SQL Server training courses and a free trial

With the publication of our most recent Pluralsight course last month, we now have a whopping 50 online training courses available through Pluralsight, totally more than 150 hours of content. If you’re unable to come to one of our in-person Immersion Events in the US this year, these courses are a great way to learn from us. And for only $29.99/month, with access to over 5,000 courses in total, you there’s no more cost-effective way to gain new skills for yourself and your company.

You can even get a free trial of 200 minutes of listening over 10 days by going here.

Our top-5 most popular courses so far this year are:

  1. Communications: How to Talk, Write, Present, and Get Ahead! (Paul)
  2. SQL Server: Installing and Configuring SQL Server 2016 (Glenn)
  3. SQL Server: Optimizing Ad Hoc Statement Performance (Kimberly)
  4. SQL Server: Transact-SQL Basic Data Retrieval (Joe)
  5. SQL Server: Performance Troubleshooting Using Wait Statistics (Paul)

And we have courses in the works already for 2017 on:

  • Query Store (already published)
  • Azure SQL Database
  • Understanding and Using Backups
  • Indexing for Performance
  • Query Plan Analysis for Developers
  • Building Multi-Instance Asynchronous Applications
  • Building Scalable Asynchronous Applications
  • Upgrading to SQL Server 2016
  • And more!

Here’s the full list of our courses, grouped by area:

DBA/Systems Admin: Installation, Configuration, and Hardware

DBA: General

DBA: High Availability and Disaster Recovery

Developer/Architect: Writing T-SQL

Developer/Architect: General

All Roles: Performance Monitoring

All Roles: General Performance Tuning

All Roles: Query Plan Analysis and Tuning

All Roles: Career Growth