How to Provide Great Feedback

July 1, 2010 by John Sansom 13 Comments

As a DBA you will encounter processes, code and design decisions within your environment that require change for the better. The most common driver for such change is performance improvement. Oftentimes the changes you wish to drive will require design and implementation by someone other than yourself.

Proposing changes(improvements) to an authors existing code/process/design can be a prickly subject (See: The Politics of SQL Server Performance) and it is important that you approach such discussions effectively in order to achieve the result your desire.

"Avoid getting Sumo Slapped"

Here are some tips I have found to be helpful when considering how to provide effective feedback:

Approach with finesse

Meet and or discuss the change directly with the author.
Ideally discuss on a one-on-one basis, at least initially.
Choose an appropriate time for your discussions.
- If the author is busy troubleshooting a production item choose a more suitable time, when they will be more responsive to your approach.

Be clear and specific about what the current issue is

What process, stored procedure, design decision is it?
Identify any undesirable qualities
- Slow query performance
- High index fragmentation
- Excessive CPU utilisation
Touch on business level implications briefly and lightly.

Praise the good points of current work/implementations

Show that you can see quality in the work of the author.
Highlight what you currently like about the existing implementation.
- Design
- Problem solving approach
- Feature usage
- Anything…………..
Perhaps something similar could be incorporated into the solution?

Put forward your proposed change

Briefly highlight/summarise your proposed change/improvement.
Avoid technical details and proof of concept at this stage unless they are invited specifically.

Set them up for success

Offer to be available to provide support and assistance if desired but leave the next action in the hands of the author.

Put yourself in the position of the author

Consider things from their perspective
How would you wish to receive the feedback you are providing?

"I thought I told you no Cursors"

Providing great feedback in order to effectively promote change can a tricky task sometimes and incorporating these tips will assist you on your way.

Do you have any tips for providing great feedback? Feel free to share them using the comments section below.

We’ve looked at what we should do in order to provide great feedback but what about what not to do. It would be great to get some of your thoughts on this. Perhaps you can think of a time when you or a colleague received some not so well thought out feedback. What do you consider to be things to avoid when providing feedback?

Next time, How Not to Provide Feedback…….just kidding.

Be sure you don’t miss out on future posts by Subscribing to the Blog Feed. You can also receive this Blog via Email.

About John Sansom

I’m a Microsoft Certified Master(MCM) of SQL Server. I’ve been working with database technology in a variety of flavors for over fifteen years. I absolutely love what I do and genuinely feel privileged to be a part of our tremendous technology community. Got a question about SQL Server or being a DBA? Ask me!

Pingback: SQL Server Performance Tuning Politics | John Sansom - SQL Server DBA in the UK()
Pingback: 10 Character Traits of Outstanding DBA’s | John Sansom - SQL Server DBA in the UK()
S.E.

Well, what I did recently in theme response is the following (not quite like you have recommended):

I had the SP that was (among others) the cause for excessive blocking. The developers rewrote it so it became better (say, initial state was 1 on a 1-10 scale, the modified solution was about 4).
I analyzed the SP logical block by logical block (there were only 4) and at the end of my mail I proposed a brand new solution which would have no cursors at all, and I proposed a new – covering – index to avoid the table scan.
I was not unfriendly, nor friendly. I was objective.

The reposonse was: “you’re right, that SP would be faster with your recommendations, but at this time we are working on rewriting some other SPs that are more frequently used. The SP you analyzed had en execution time of 200ms and it runs only a few times a day”.
Well, they may be right, but that few times when it ran, in the problematic timeframe it ran not for 200ms but for 576 secs (due to blocking).

At this point I got angry and replied: “OK, do what you think you must do, I’ll moderate myself with my
recommendations. Let’s go!”

Maybe I was wrong.

What do you think?
Michael J Swart

I’ve been in that situation too. And I hear you loud and clear. If I listed my top ten frustrations for the year, then unimplemented recommendations would leave them all behind.

The best I can do is make sure the business maker understands the risk. And at last resort – get them to repeat back to me. “I am choosing deadlines over quality”. I do it tactfully and it’s not always black and white. And I’m lucky that I got co-worker’s that trust me.

But it sounds like you have people that actually don’t believe you. (Whether it ‘s personal or they’re hiding their heads in the sand) That’s the worst and I wish you luck. I’d shy away from snarky emails, but I don’t have any alternative.

I am curious about what others think.
r5d4

Have been there too. More recently than I would like.
A developer I’ve been working with has ignored everything I’ve explained about sql server.

As a result >

1) We still have a ton of adhoc sql (stored procs, user defined functions etc are ‘too much work’)

2) We have little Normalization (the clue is in RELATIONAL database). It is too much effort apparently, meaning –
a) We have lots of duplicated data.
b) A lot of it is large text data (meaning the data cache has NO chance and the page life expectancy is very low).
c) Reporting on the data is painful.

3) H/A technologies are near impossible. Try implementing replication and a reporting environment when your schema gets repeatedly ‘tweaked’…

The individual always listens, but then does exactly the opposite.

The most recent example is implementing Linked Servers for retrieving large results set and putting the code live (against my advice)

Due to small company politics and the individual’s seniority (8 years loyal service), they frequently ‘work on live’ and retrospectively update dev & uat with db changes.

My auditing skills have improved no end and I have automated checks of object changes to see ‘ what ‘x’ has done today ‘.

It’s not a nice way to work though, and is very stressful.
- r5d4
  
  I’m moving forward with my feet. right out of there.
  In a few days in fact :)
  r
Keith Mescha

Nice job on this, very good advice and something that I see happening on a regular basis. Sharing with the team here as I think your approach to sharing advice is great.

Keep up the good work.
Pingback: Seven Reasons You Should Attend SQLBits 7()
Pingback: TSQL Tuesday 13: Managing Unrealistic Expectations()
Pingback: The DBA Ultimate Fitness Workout Plan()
Pingback: Stop Asking and Start Making Decisions Today()
Pingback: Something for the Weekend - SQL Server Links 31/05/13 • John Sansom()
Maria B.

This is a great artice. Thanks for articulating one of the key skills we need to develop as a DBA – optimal communication. Just as important as optimal queries!

How our information is received is a different story. But it’s still our responsibility to pass the information on.
And if that information isn’t valued by the business or development teams, then perhaps it’s not the right business for us??