As you work with other people, you will experience resistance when you suggest changes and want to implement something new.  Why is this?

One podcast listener shared an experience where a problem was occurring.  They suggested a solution.  The idea was rejected.  No solution presented itself and the idea was submitted various times.  When nothing else was working, the idea was finally implemented.

The suggested change successfully helped the situation.  Victory!

Later, another issue arose and a similar suggestion was made.  The expectation was the suggestion would be well received; however, this was not the case.  The idea was still met with hostile resistance.

Have you faced a situation like this before?  Why wasn’t there a trust built because of the first recommendation?

Our conversation for today’s episode centers around the idea of building trust in the teams you work with.  As most of our listeners are in the data platform space, we thought it would be a good idea to reach outside our community to folks we might receive the most push-back from–developers.  We are happy to have Richard Campbell on the show with us today.  Richard is the co-host of the .NET rocks podcast and you might recognize him from one of his many Channel9 videos.

We chat with Richard about how we can build trust and how some common ways we attempt to show authority can backfire on us and actually cause more problems.  We talk about some of the ways those we trust have gone about earning our trust.  I know you’ll enjoy this episode.

Episode Quotes

“Mandates are one thing, execution is another.”

“Being successful is about persuading people to want to do it in a way that is usable by everyone”

“Position or power actually undermines your ability to persuade.”

Listen to Learn

04:07 What makes up trust in a team?
05:07  DBA’s responsibility in keeping the data safe and aligning business goals
08:37 Setting team standards, collaboration, being flexible to the needs of the team
11:52 How to be effective and create influence by giving value to the people in the team?
13:35 Becoming a consultant that takes away the tension of the problem inside the team
15:20 Understanding the whole person, the whole effort, the whole team
17:01 Attitudes when encountering failures
19:35 Other ways on how do you save yourself from quitting?
20:06 Why lunch is the most powerful moment of the workday in terms of improving trust?
25:30 Understanding the other team’s workflow
27:00 Discussion on best practice, showing the work, and getting an effective team
31:45 Team building activities and time together in strengthening the team
38:28 No level of position or power enhances the ability to persuade people to do something
40:46 SQL Family questions

About Richard Campbell

Richard the co-host of popular podcasts .NET Rocks (www.dotnetrocks.com) and RunAs Radio (www.runasradio.com).  Richard  is the founder of the Humanitarian Toolbox (www.htbox.org), an organization designed to let developers around the world donate their skills to disaster relief organizations by building open source software.

Today Richard is a consultant and advisor to a number of successful technology firms as well as the co-owner and content planner of the DevIntersection (www.devintersection.com) group of conferences.

*Untranscribed introductory portion*

Carlos: Richard, welcome to the program.

Richard: Thanks guys. I’m happy to be on board. Thanks for inviting me.

Carlos: Yes, all the other podcast that you’re hosting and have been on we’re happy that you came to our side of the pond and if you will and willing to chat with us a little bit today.

Richard: Hey, it’s nice to just be a guest because I know from some experience that hosting is hard work. You got to remember and keep track of a lot of things. I just have to answer questions like this is luxury.

Steve: Nice.

Carlos: How many podcast episodes would you say you’ve done?

Richard: Like little over 2,000.

Carlos: Wow, I was thinking closer to 1,200.

Richard: There are 1,465 .NET Rocks! episodes. But I came on board at show 100 so there is 1,300 and something. There are 545 RunAs episodes so that gets us up into the 1,800 range, and there is about 150 Tablet Show episodes.

Carlos: Oh, there you go. That’s right, I forgotten.

Richard: Yeah, so we are coming right around 2000. Now the Tablet Show was this little interval in 2011 to 2014 when it didn’t seem like .NET rock that much, and we hedging our bet but we were still doing .NET Rocks! but we are also building another show, just in case because it seems like Microsoft was moving away from .NET for awhile there. And then it was clear they weren’t, we just rolled the Tablet Show back into .NET Rocks!.

Steve: Ok, interesting.

Carlos: Well then we’re happy to announce this is your 2000th episode.

Richard: Yeah, ok, I’ll let you have that number. There you go.

Carlos: Well, so Richard, I think many listeners are going to know from the .NET Rock show. We actually have and one of the reasons we want to have you on the show today was a listener chimed in and had a question about trust and we thought that we might role play a little or talk a little bit about how this idea of trust works in teams in our environment. The reader actually goes to say, “I’ve been listening to your podcast, collecting best practices and I’m the DBA in an organization. I’ve only been there in a couple of months.” But they had the SQL Server, it was having problems. I was recommending changes to the SQL Server based on best practices, right, things we’ve been talking about in our program and others. The developers were like, “No, no”, because they’ve kind of managed the database, were responsible for that environment. Well, finally they relented because they were having so many problems and they had an improvement in that server.

Richard: Wow.

Carlos: That’s right, so everybody goes happy. Well, then he said, “Ok, well hey let’s adopt this as best practice and let’s go put this on server #2.” And they say, “Whoah, whoah, whoah. Time out!”

Richard: Don’t get crazy now.

Carlos: That’s right, and so his question was if I was able to show value and demonstrate that I could be of assistance why didn’t that apply to a more general trust of me and my recommendations ultimately. And so this kind of becomes then the basis of our conversation today, right, building trust among teams and particularly our audience is our SQL Server folks, and how they can work with developers like yourself to build that trust and to kind of move the organization forward. And so I guess we’ll start there and what do you think makes up trust in a team.

Richard: Well, looking at your particular scenario my concern always is folks look at one win and call it random chance. It kind of takes three wins before folks really like, “Hey you keep being right.” Like maybe there is an actual trend here.
Carlos: Sure. There is that saying that I like, “A data point of one does not a trend to make.”

Richard: Yeah, right. That’s kind of a narrow curve you’re looking out there, so it’s usual to build more points. I think it takes a lot of patience to be kind enough to allow people to learn themselves. So let them collect empirical data around their own mistakes. The challenge is to sit down your hands and not say, “I told you so.” At the same time I think it is also important, I think it is a trap we followed to is tech people is to keep talking about the practices around the technology rather than practices around them. The responsibility of a DBA is to protect and curate data irrespective of the technology involved. In the end this is an asset of the business. The developers are building software to allow us to bring that data in and perhaps to do some analysis on it, but ultimately the hat you really wear is the one that says, “I am responsible for making sure this data is safe and thriving and useful.”

Steve: Yup, and I think with that data that you’re keeping safe and thriving and useful is oftentimes considered by many of the organizations like their crown jewels. I mean without that they would have significant business impact if it was damaged or gone.

Richard: I hope that folks see that although a lot of folks don’t. That’s where, you know, when you talk about breaking down walls between teams. It’s not talking about technology; it’s talking about business goals, and so being able to speak in those terms so that people get aligned. When we really talk about that alignment we’re all pulling in the same way. It’s that we recognize, “Hey, our data storage is worthless without your software being able to feed into them.” So I don’t want to be an obstacle to your ability to put that data in. That data is only valuable if it’s usable and it’s safe so that’s why we have security and why we care about organization of the data and whatever form that looks like. It’s about making sure that data is actually valuable. You can’t succeed as a DBA without allowing your developers to be productive, that’s a necessary part of the equation. But vice versa if they are writing software that doesn’t store data effectively their software is not that useful either.

Carlos: We’ve talked about this on the show before kind of going from the CIO perspective or the managers they want the technology team to understand that the business value, what problems are we trying to solve and I think to you point sometimes we get sidetrack a bit by the technology and fighting over. You know, what we are or not going to implement when really we should be aligning what we do with those business goals.

Richard: And often we have pain too, scars. We’ve had a data corruption, or we’ve had a failed recovery, or we’ve had a badly behave piece of software where we… on a table. And so you can be a little jumpy.

Steve: Yup and I think some of that too comes from history, and I think with the example of this listener I think it was someone who was new to an organization. They probably had someone there before, I don’t know anything about the background but there is obviously some reason the developers were a little bit shy of making changes. Maybe they had a bad experience before that and it might take a lot of successful wins before that trust will be regained.

Richard: Yeah, and one win does not a trend made. Like, congratulations, you are walking the path but you got to keep walking it. And at least now you get to refer back to some success that’s already happened in the organization, some talking points. Blanket concepts around overall practices, those take longer to grow, and I think especially development organizations, you need to look at that from the perspective of how do you folks normally set standards around your practices because often we have a lot of teams where there isn’t a standard set of development practices. Essentially you’re going have to work from team to team to see how they like to interact, how they want to work with data, how they want to work with the system as a whole and essentially tailor a data access solutions to the team.

Carlos: So that sounds like something that might have to be, I don’t know, maybe not mandated but ultimately you have to be a little bit flexible. I guess maybe the first component of trust is being flexible to the needs of the team and ultimately being, which maybe against your traditional idea of a DBA, but being flexible to their needs rather than being quite so rigid in certain instances.

Richard: I think you need to be aware of how those teams currently work. If you do have an organization with say a strong enterprise architect group that does want a press standards upon everyone then talking to an individual team about a standard doesn’t make sense. You do want to go talk to those architects about how they developed those standards, how those measurements have done and how they are implemented so that you work within the system rather than inventing something new. And if it is team based, if we’ve got an environment where “agile” or we’ve got a variety of teams working in different ways there’s many ways that happens and works that way then it’s more of a team based. So I think there should be an awareness of how everybody works makes a huge difference in your ability to convince one way the other. I really want to emphasize this idea and you said this like, “Mandates are one thing, execution is another.” I’ve seen plenty of cases where we have a set of documents of this is how we build software and this is how we interact with data except for that part where nobody actually writes that code that way, those are great documents. You’ve got to actually look at how the organization actually functions as well as what it says. And being successful is about persuading people to want to do it in a way that is usable by everyone. That they are productive, you are productive and you achieve that real goal of delivering the data, so I would much rather persuade than mandate.

Carlos: Right. I think and so we kind of almost get into a soft skills discussion because this is again not about technology but this is about how to make friends and influence people.

Richard: I don’t disagree and I’ve done this long enough now in one form or another. It would basically come into conclusion that there is no situation where the technology can’t do this. This is invariably can the team do it? Yeah, this is marriage counseling.

Carlos: As a database administrator we think that we have kind of add some value to the team. First thing we want to do in establishing trust is really just getting away of the land and asking the questions, what are the problems people having, how do they go about doing things and then determining whether or not you can influence or make a change in some of those processes.

Richard: Absolutely, and so this is an old Stephen Covey’s 7 Habits of Highly Effective People thing. If you want to change anything, you want to influence anyone; first you have to understand before you’re going to be understood. So spending that time understanding how the team actually works. What motivates them, how they build their code, how they interact with data first and foremost that’s the first step because once you have a grip on that you can finally speak a language about how data is handled inside of the team and reflect that back on how you see it arriving in the database. That understanding is a step in trust too. The first hurdle to get over is this idea that they matter, and that they know you see them as people that matter.

Carlos: And that they are more important than the problem. It’s just kind of an area where the internet kind of fails us in the sense of we can publish this information out there, best practices, this is the way you “should” be doing things. But then we try to force that on people and say, “Hey, this is crazy. This is the worst environment I’ve ever seen. How do you guys work like this?” You’re not making any friends there.

Richard: Well, I’ve seen plenty of consultants where their names actually come from con game and insult. It is super easy to tear down other people’s work. The reality is nobody goes to work with intent to ruin things like today is the day I’ll make a mess of everything. That’s not the goal. I start with the fact that people generally have good intentions and then make the best decisions they could with the information they had at that time. Invariably when we look back we have more information and so we’re always going to see it differently. But if you recognize that you made the best decision with what you knew at that time and the constraints that you’re working in, some of which are going to be visible and some of which are not, then you’re a little bit kinder. I think the number one thing I’ve said most of the time when working with teams as an external is, “Guys, what I see here is very normal.” I have the good fortune to work with lots of different teams, there are always problems. The question is how well do we recognize them and what do we want to do about them. It’s just super normal. And just take that energy out of you’re not a disaster, this isn’t the worst thing I’ve ever seen. Like suck the air out of that talk about. We are all trying to do the best we could with what we had, here is where we are. We know we can get better. We can’t do it all at once. It doesn’t have to be immediately. These are incremental improvements overtime while maintaining the requirements, whatever they has to be productive and continue to ship features.

Carlos: Sure, right, so kind of taking out the Facebook approach if you will. Facebook everybody always post the best things, all the highlights and then you compare yourself to that and you’re like, “Ahh, I’m not good enough.”

Richard: No, and you always, out of the 150 store procedures you wrote you’re going to show me your best one but the other 149 exist. I think that’s part of this being a trusted team is a group of people that know we have good days and bad days. We have our strongest work and our weakest work but as a whole we deliver. Understanding the whole person, the whole effort, the whole team, that’s the value proposition. It’s hard to get there. We want to only look at shiny but we have to look at the hole.

Steve: And I think really the key to what you said there was understanding the team and understanding what the team is expecting. An example of that is doing consulting. We’ve work for a lot of different teams and some team I’ve work with, their number one goals is stability in uptime and if you’re pushing out a new feature and something goes wrong they would rather you abort the deployment of that new feature that means it’s going to give stability in uptime versus whether the new feature goes out on time. Others I’ve worked with, it’s all about we got to get the new feature out on time, and if you don’t get the new feature out, well there’s a problem.

Richard: Well, and often you’ll see those two positions inside the same team. The person who gets rewarded for shipping new features is really not worried about uptime and the person who gets rewarded for uptime features other worst thing that could happen to your uptime.

Steve: Right, and I think that you may get an organization and I’ve seen this where you say, “We try to do this but something unexpected happened. We rolled back and aborted that project or that deployment and here is the plan of how we’re going to take it on next time.” And some people respect that and other people look at it as, “Wow, you just slowed me down. You got in my way.”

Richard: Yeah, and you also find places where any kind of failure at all is such a big deal you never want to talk about it again. We cover up the fact that roll back happened.

Steve: Yup.

Carlos: Right, then we get into situations so analysis paralysis, so people are so afraid of making that mistake that they just don’t do it.

Richard: Yeah, deploying more software, making those updates would be the worst thing that could possibly happen which is just not worth the risk.

Carlos: Exactly.

Richard: I think it’s a challenge to get to a place, you know, we talked about modern environments. What we’re really pressing on is not know failures but minimum pain from failures and rapid recovery. Fail but don’t fail catastrophically that you’re able to be able to test it in the field. You know you can get back quickly. And it’s not a big deal to do that recovery that you know when you fail. It’s not like science pop out of the server going, “Opps.” How do you actually know there is a problem? If you have to wait until a customer complains then you know it’s been going on for way too long, so how are we measuring success or failure? Do we actually know when we’ve done it right?

Carlos: So thought around, let’s say again to our audience say database administrators we do have a couple that maybe managing other database administrators or team leads something along those lines but most of them I’m going to say maybe don’t have the authority if you will to start again say, “Hey, this is the way we should start doing things.”

Richard: And let’s be clear you are never going to have that authority. Get over it. It isn’t going to happen, so don’t count on it. Don’t wish for it, find other ways. You need to be able to get to that end goal of being able to have safer, reliable data that’s valuable to the organization. You’re never going to get it with the stick of power so you’re going to have to do it in a different way.

Carlos: Yeah, so I guess let’s talk about some of those other ways. Obviously we talked about reaching out when you’re on a team that is dysfunctional. I guess thoughts around how do you save yourself from just throwing up your hands and saying, “Yeah, we were not moving forward. I’m out.”

Richard: Well, and lots of people you either quit you go somewhere else, or you check out. Just tell me what you want. I will do whatever you want then nothing is my fault. And if you want to be more positive than that, more constructive than that
you have to start establishing some relationships and some trust that you have inside. And I would argue, you know, we described a very simple thing, understand the development process. Well, turns out that’s really hard to do because understanding development process needs interrupting a lot of people that are working, and they will be annoyed with you. You can’t do it during the workday. You have to do it around that and at the simplest level. The one window you’ve got is lunch. You know, when you give it workday the only time you really can talk to people where you won’t be take them away from work is lunch. And on top that, humans are hardwired to trust those they break bread with. Lunch is the most powerful moment of the workday in terms of improving trust. We just don’t take it seriously enough because we’re hungry.

Carlos: And how frequent it is that we meet people consulting for the first time over a meal. I think it would apply, I feel like maybe I have applied this in other scenarios but it takes them getting used to. It can be awkward, right, the first couple of times.

Richard: Absolutely, so just go and ask, “Can we have lunch together?” One of my measures of sort of the health of an overall team is to say who’s having lunch with whom. If devs are only having lunch with devs, and DBAs are only having lunch with DBAs, and ops guys have only lunch with ops guys. That’s an isolation. You actually want to encourage folks eating with each other. A lunch and learn where we talk through broad concepts on software and not a particular technology. More of where we want this application to go, where we want ops and data and dev to be together in a room. You want an interesting experience you put together three lunch and learns for each one of those team, all teams go to it as long as you’re buying pizza people are going to show up, right? Each team presents their view of an application, so developers are talking about the feature they’re building the stuff that they’ve deployed so far, the DBAs are talking about how data goes in, how data goes out, how data it’s currently organized, how it’s backed up and restored, operations talking about network traffic, how security works, how it goes to the firewall, because generally speaking the other team just don’t know what those guys do all day. I don’t understand why your job is hard. And so just having a moment where each of the other teams gets to see the folks that do the other piece and go, “Oh, that’s tricky.” The average dev has never seen a network diagram. Their network diagram is client, cloud, or internet server, maybe database behind it, so they reduce the operation guys entire job to a couple of lines. And the DBA guys to that cylinder on the drawing. There is more to it than that, and so actually starting to understand it a more deeply that’s the beginnings of trust, of some insight into the system.

Carlos: Can you think about all the effort we put in to just learning technology, you could take a lunch or a couple bunch of lunch, you mentioned three, to go to the pains of actually learning what your environment looks like.

Richard: And learning what your data storage environment looks like and what a recovery looks like. I want you to get to a place, I’m trying to banished the concept of that’s easy to everybody because everything is easy once you know how to do it. I want you to understand and remember these things are hard. And the side effect of that would you say to someone, if somebody ask you about a tech, oh that’s easy. You hurt yourself in two ways. One is you’ve undermined your value. Clearly you can do it because it’s not hard, and then same time you’ve also harmed the person you ask because this like, well you might be stupid because this is easy. Saying easy is just a terrible thing to say. There is no upside to it. Now, you don’t want to go, “Oh my god, that’s so terribly hard you’re going to die.” But it’s like this takes effort but it’s worth it. It’s a much more reasonable thing to say. All of our jobs take effort.

Steve: You know, I can remember being asked recently about a specific test that I have done and they phrase it as, this is what we want you to do. That’s going to be easy isn’t it? And how much does it take you to get it done? The administrator at a very high level without even exploring any of the details on it, and as soon as they said it’s going to be easy that makes it very challenging to be able to come back with anything that’s going to be realistic to their expectations.

Richard: Yeah, it’s terribly undermining, and not actually constructive. Either you lie or you lie, like you don’t have any good answers at this point. And even the process of estimating effectively is going to force people to actually understand more which often they don’t want to do. So just this encouragement to try and understand more to see what’s easy and what’s hard. I mean, there is another interesting truth which when we start poking at each other’s workflows there are skills that each team has that can make those other workflows simpler. Devs tend to solve stuff with code so often what they really understand a workflow on a DBA side there is like there’s some things we could do in code that would simplify that process for you now that I understand it. So there is often low hanging fruit between the teams that until we have some understanding of how everybody does their work, you don’t see that. We do have different view points on the same project. Once we see each other’s viewpoints you pick some simple things.

Steve: I think the key there is seeing the other person’s viewpoint, and almost like you’re in their shoes to understand what they are trying to say. And so often that’s what’s lacking. People just say this is what I’m going to do because I’m a DBA, or this is what we do because we are developers.

Richard: Well, we hide behind phrases like best practices. I don’t have to think about your need because I’ve got best practice. And again, it’s the other form of easy. You’re undermining the other person’s work, so why are you surprised when they resist you?

Carlos: Alright, that is an interesting question.

Richard: Let’s tackle it this way. We will only get to call it a best practice when all of us agree it is.

Carlos: Right, so the team itself has to agree on what the best practice is not you bringing in some external source and deciding for everyone, “Hey, this is the best practice.”

Richard: And it’s not like you have to invent from scratch. There is no problem with bringing something externally and saying, “Hey, I read this from this credible source. They recommend these things. How would this fit with our plan? Do you see value in it?”

Carlos: Right.

Richard: I hate coming with such certainty, and it’s a disease we have as technology people. We’ve had careers. We’ve had our time in school where we liked the result. We want the answer. We hated showing the work. Remember that, how much you hated showing the work. Here’s the bad news, when you actually want to influence people you got to show the work. And we keep coming with solutions and people want to understand the path. That’s why you present the best practice rather than a set of ideas that get to a result. One is showing the solution, the other one is showing the work. And without the work you can’t influence.

Steve: Yup, interesting. I can think of this specific example where I ran into that, where I was debating with a development team on the use of GUID as primary keys and the clustered index. Of course these were random GUIDs not sequential GUIDs, and I went and I found some blogpost from Paul Randall and Kimberly Tripp talking about this. And I went and examine them, wrote up an example that showed exactly what they’re article said and showed it to development team and then they came and said, “Oh, that’s just some blogger talking about it.” I mean everyone out there got an opinion on it. And the mistake I made was I didn’t set who Paul and Kimberly were in that example. They were just two unknown bloggers to this developer.
Richard: Not the guy who wrote DBCC.

Steve: Yeah, exactly. And I completely blew it on that one because I didn’t set the stage for where the data was coming from that I was using in my proof there.

Richard: And you can leverage that blogpost to map it to the problem, we’re seeing these issues. Let’s face it, like there is lots of controversy around randomly generated GUIDs. It’s not free. It has certain advantages for certain circumstances and it has a certain cost. Sort of upfront by looking it both, so the things to say, is this a cost we’re willing to pay to get this benefit. I do simply don’t believe in the one right way. I’ve had too many years writing too much software to actually believe there is a right way. There is the way that works at that time with the tools and skills that we have. We can get better but if there was one way through these journeys we’d all be taking it. The fact that a bunch of us have been successful in a bunch of different ways is sort of proof, and that no tool will save you. You take the same set of tools in a different problem and fail.

Carlos: Yeah, we look at that in data all the time, maybe like to make fun of the reporting tools. This new reporting tool is not going to help you unless you’ve got good plumbing, good infrastructure underneath. How many times do we try to do the same thing like what we’re talking about, the best practice or some other solution to say, “Hey, this new thing is what’s going to save us.”

Richard: Yeah. No, I want the big red button and then when I hit it, everything goes well.

Carlos: Exactly.

Richard: It’s a lovely dream, it’s just not true. In the end the tools cannot save you, it comes down to people in practices and since people make the practices it’s only the people. That’s all there is, you have to deal with the people that you’re working with. And if you understand them and see what their strengths are, value those strengths and put that puzzle together, put those pieces together so that everybody’s strengths are emphasize and their weaknesses are compensated for. That’s when you get an effective team.

Steve: So one of the things that I’ve seen in organizations were like management will try and get cross functional teams, operations and developers to work better together is they’ll do some kind of an outing that involves trust exercises and team building and that stuff. What do you think? That does kind of thing help or is that?

Richard: Yes. I’ll tell you why. It’s almost not the activity, it is the time together. In fact, the more mundane the activity, the better in some respects. Packing boxes at a food bank is not intellectual work. And the good news is then you don’t have to focus on it, maybe you’ll start talking to each other.

Steve: Or even if you took the whole group for an afternoon of bowling. It might have the same effect.

Richard: Yeah, same effect for that very much the same reason. And again, introducing food into the equation because it does plug into our brains to connect more, time together without the pressure on the work. Now, I’ve gone an angle on this as well. A few years ago help setup a charity called Humanitarian Toolbox where we build open source software for disaster relief organizations. In my mind it was, I know developers want to volunteer their time in a constructive way and use their skills. What I realized was it was also a very powerful team building exercise because yes we’re still writing codes but we are not writing the code from the office and we’re not on those deadlines. We’re in this volunteer mode. And so the dynamics of the team shift around and you sort of see each other differently. All of those exercises external to our regular day to day work, so the pressure of delivery, the pressure of a 40-hour work week are off and we’re in that different mode, that invariably can strengthen a team.

Steve: Ok.

Carlos: And I think some might complain now that you’re asking to do extra things.

Richard: Without a doubt, and this is part of understanding people. Look if you’ve got a 3-year old and a 5-year old at home you probably too busy to take a weekend off. Those kids need care. I think it is part of a good organization to recognize where our team members. How do we support them? On the other hand they love to have a weekend when they didn’t were constantly managing kids. So the fact that you’re offering some child minding as part of that equation at the bowling alley? Brilliant! How do I actually get the whole team to show up and be engaged? Well, if I understand them, I know what motivates them. I know what challenges they have so we can work on those things.

Carlos: And I think if we take the approach of I am making an investment in the team, I am trying to form those relationships and not, “Oh my gosh, another meeting,” just something I have to slug through that’s not helpful either.

Richard: The team building exercise will continue until morale… Really, we’re going to mandate that? One of the organizations I worked with, there was several people that were very bent out of shape about leftover food. They would take it down to the soup kitchen they would make sure utilize, and that to me was cute. Like there’s a strong social conscience in at least a portion of this team and so when you put energy into that, let that be more visible, it was very easy to say, “Hey, most of us care about this stuff. What would you think about doing an afternoon at the soup kitchen packing sandwiches?” It was already a thing where we’re
aware was important to many of our team. So validation there, add some time away, a good practice, doing a little corporate citizenship were our company did something collectively, you know, that was important. And the side of that was increased trust in the team, a shared set of values outside of today’s work. And some time to finding out who’s really good with plastic wrapping and who sucks at it.

Carlos: And then all the inside jokes that come along with that.

Richard: Exactly. You know, everyone of those inside jokes is a reminder of trust. Every nickname kindly given is a reminder of trust. That’s what good teams are built from.

Steve: Right, ok good stuff.

Carlos: Yeah, now I feel like we need to go to the soup kitchen, Steve.

Richard: Well, you’ve got to find the thing that works for your team, whatever that may be. Part of this is exploring the values that exist within your team outside of the day to day work. I’ve done Habitat for Humanity as well. My father was electrical engineer. I know how to do wiring so I was wildly productive and enjoyed myself. And everybody was surprised, I’m kind of a geeky guy. And then you give me a pair of lineman strippers and some rowmax, and I’m putting light switches in, surprise.

Carlos: Yeah, that’s right. And I think I guess, and again we’ve kind of been coming it from the vantage point while you may not have the ability to put those things together in your interviews and your annual interviews or when you’re asking for feedback, right, these are the type of things you should probably pushing for and making those suggestions. Even going back to the lunch and learn, I’m a huge fan, I don’t know why more organizations don’t do it, and I guess they look at this like a cost but again for a couple of pizzas. I mean, it’s well worth the investment.

Richard: Sure. You can do this ROI. My goal here is to make a stronger team; team is more productive for the price for a bit of food, it’s ridiculous. There is an argument about wanting to take a break, time away. But taking a break to think about something else is still a break. So it’s just what does that look like. I know a group of developers that what they did on their break was cycling. They loved riding their bikes. And so the fact that we would help organize for them a place for them go riding over lunch maybe huge difference to them. Again, valuing the distinctive aspects of those teams so that they can get stronger and get that level of validation that we care about the whole person, not just the 8 hours.

Carlos: There you go.

Steve: Yup. Good point.

Carlos: Yeah, Richard thanks for those insights. I mean so great points. Again, no easy button, right? But there are ways to go about.

Richard: And I guarantee you it is very persuasive in your own mind that someday I’ll get this promotion I’ll be able to make this happen. There is no level of power that will make it happen. CEOs all the time throw up team building exercises and nobody shows up. Just because you’re the boss doesn’t mean it’s just going to happen. You will never do this from a position or power. And I would argue that a position or power actually undermines your ability to persuade.

Steve: Yup. I would completely agree on that one. I’ve seen people get into that position or power where they believed they had the ability to command and totally loss the ability to persuade anyone to do anything.

Richard: They were probably more persuasive before they got the promotion because they actually try to persuade. Leaning on your title it’s never going to work. Just actually care enough to understand and help people understand you, you’ll get results. Nothing is fast, nothing is simple, it just takes time and it’s worth it because the improvements last. Once you get into this righteous cycle of a stronger team adding new members to the team, it’s easier to hire. People recognize a healthy, happy team and want to be a part of it. When you already have a culture that people value more people adapt to that culture. This is a righteous cycle, it gets easier over time. The first steps are the hardest steps but further down the path, you wonder how you were never there before.

Carlos: Right, I think using that title again, if the approach is different like you mentioned that idea, so there’s that saying, “People don’t care how much you know until they know how much you care”, kind of going back to the title right. If the approach then changes from caring about people to kind of getting things done, “Hey, I’m going to implement this thing”, then again you’ve lost, you’re kind of coming with the best practice again and you’re back to square one.

Richard: Well, it’s amazing how much people build like that because nobody uses this like, “Wow, that’s really well built. I’m sure you’re enjoying it all alone.”

Carlos: That’s right. Well, awesome. Richard, thank you so much. Shall we go ahead and do SQL Family now?
Richard: Absolutely.

Steve: Yeah, let’s do that. So what was your first experience using SQL Server?

Richard: Well, I’m the old guy, right, so I actually had the 421 installation on NT3 1, the non GUI version of NT. It was bomb proof, man. That was a solid piece of hardware. I think it was probably 486, maybe a 386 and just ran every day, all command line, total vintage; and the app I was writing was Visual Basic 2 with VBX library called SQL Sombrero.

Steve: Oh, I hadn’t heard that one.

Carlos: I like the name.

Richard: SQL Sombrero, that is like some vintage stuff. When we got to VB3 then we’d actually have RDO which was a data objects layer for talking to SQL Server, remote data objects but before that it was third party to actually get to SQL Server. But that’s old, that’s original client-server stuff, man. It was great great software to run. It was very straightforward but getting all the pieces put together and getting it working. That’s actually pre ODBC, that’s how old that is. It would be later that I would have ODBC errors.

Carlos: Oh man!

Steve: Yeah, there were no ODBC errors then.

Carlos: No ODBC.

Richard: There was no ODBC. Microsoft developed ODBC because they were trying to get traction to SQL space and everybody has their own drivers. The whole idea of ODBC was a universal driver. I had a customer once tell me, “I want you to get ODBC up all these machines because all it does is generate errors.”

Carlos: Wow, so all that time working with SQL Server and with .NET, right? SQL Server has changed quite a bit since those days, right?

Richard: Oh for sure, yeah.

Carlos: If there was one thing that you wish you could change about SQL Server, what would it be?

Richard: Well, even though I understand why .NET existed inside SQL Server I really wished I didn’t. I’m happy that it’s off by default. You should leave it that way. The number of scenarios where running .NET inside of SQL Server is a good idea are so vanishingly small. And of course Microsoft can never take it away because people have taken dependencies on it now. Like that’s going back to 2005, and their justification was this was a big data problem long before big data was really a thing. And today we would solve it in much more coherent ways but here we have this feature that just persists and it’s painful. It’s so dangerous. And anytime I have some a pop on the head, maybe I’ll just to turn on .NET. Don’t do it!

Carlos: Step away, step away.

Richard: Step away from the process, don’t touch it.

Steve: And I’ve never seen that work well by using .NET in the database.

Richard: It’s a very tricky thing to do and honestly I get so old now I don’t know it makes sense. There are so many better ways to solve problems that that was supposed to address than with .NET inside SQL Server.

Steve: Ok, so what is the best piece of career advice that you’ve ever received? You are not your customer. And I mean that from a perspective of your developers are not a DBA, and you’re a DBA, so just presume they are not thinking like you do. You’re not the customer, and so every time you think you know you’re wrong. You have to ask the question. You have to be influenced. You don’t use the software the same way the customer uses the software. You don’t operate the database the way that anybody else looks at the database. Your viewpoint is unique to your space. You might be able to talk to peers but your peers aren’t your customers either, so just stop fooling yourself. You have to ask questions.

Steve: Sounds like good advice.

Carlos: Richard, our last question for you today. If you can have one superhero power what would it be and why and why do you want it?

Richard: Well, I guess I want to fly. Doesn’t everybody want to fly? It’s almost a cut out
00:45:00 really. That way I could tell the airlines where to go and fly myself. I’m in metal tubes in the sky a lot and I’d like to do less of that and still get the chance to work with the people I get to work with, go to places I can go.

Carlos: There you go.

Steve: Isn’t that your superhero power Carlos, that you wanted?

Carlos: It is, yeah.

Richard: Fly or invisibility. I don’t want to do time travel because I don’t want to be responsible for anything, right? It’s really those three, that kind of great superpower.

Carlos: It depends on which plane I’m in, how much I can work with my laptop or my tablet right but that would be the one thing, the next thing to figure out once you can fly is how do I get to get some work done flying around.

Richard: Well, obviously that’s going to be enjoyable enough that we don’t care to do anything else. Never that simple.

Carlos: Well, awesome. Richard thank you so much for being with us, today.

Richard: Guys, tons of fun. Thanks so much for having me up.

Steve: Thanks Richard. It was a great time.

Richard: You bet.

Carlos: Yes, we do appreciate it.

Richard: My pleasure.