Is enough ever enough?

When should you give up on an employee and give them their walking papers?

It can be really hard dealing with different people in the office.  I mean, there are so many different types of people that there's no way it can always go smoothly.  And then when you throw everyone's agenda into the mix then it becomes even worse.  So the question I'm going to explore today is, when is it to the point when it's too much?  Because the problem is that managing these personal relationships is fine, but when it starts to take up the bulk of your time and you're spending more time on that than you are on your job then it's time for someone to call it quits.

Let's take an example of a SQL dev.  I'm not picking on SQL devs, it's just the first thing I thought of.  So you have this dev who's been allowed to do anything in prod for years.  He's always been the one to go in and run scripts to fix prod issues, and he's always been the one to put in new code, etc.  Well, the problem is that now the company is going through a change and getting some bigger projects and more customers so having the uptime and everything working perfectly is essential.  Your reputation and your income stream have to be maintained at all times.  The problem is that sometimes the dev puts stuff in that either isn't fully thought-out or isn't fully tested and stuff breaks.  It's the whole cowboy approach that we're all so fond of making fun of, right?  So the company agrees that there need to be some procedures in place to catch some of these things and they make the mandate that it has to start happening.  So everyone plays along because they're getting tired of getting the calls in the middle of the night... everyone except our cowboy.  While he publically says the controls are a good idea to stabilize the environment, he means it's a good idea for everybody but him.  He's way too busy to be bothered with code reviews, or change control processes and therefore he fights it at every turn.  He goes out of his way to stonewall the effort and to do things to make sure the process breaks down.  He constantly whines to the bosses that he doesn't have the access he needs to make changes in prod on the fly (even though that's the goal), and that the business will crumble if he doesn't get his changes in right now. 

So the bosses have a talk with him, and he reiterates the need for him to have complete access to the prod systems.  And no matter how high the boss is (he could even be a Sr. VP), he always falls for it and says he'll release the restriction for him.  See guys, it's not an emergency because the business has been up for many years now w/o this fix so another day or 2 isn't going to bring anything to its knees.  And if it really were that big of an emergency, they would actually shutdown the website until it were fixed.  So don't come crying to me that some user request needs top priority.  Anyway...

So then the boss meets with the DBA who tells him that these processes need to be in place so that the system is stable.  And he even shows the boss written verification of the things that have been messed up by cowboy bug fixes.  The boss agrees and says he didn't really see it that way and says ok, continue with what you were doing.  He goes back to the dev and says the processes have to stay in place. 

Now, the dev fights it even harder and does nothing but go around the office complaining to everyone about how busy he is and how he doesn't have time to fill out the 5mins of documentation it would take to be compliant.  He needs that access now.  He's got all these user requests that he can't fulfill unless he's got those sa rights.  And he goes around and around with the DBA and with other devs, and with managers, etc.  So the boss calls another meeting, only this time he calls in a couple others from IT as well so they can hash it all out.

In this meeting the dev brings up the fact that he's got all these requests and they have to be done right now.  The DBA says, but these are low-level requests.  They can be done anytime, there's no sense of urgency here.  The dev then says that all requests are the same.  The other dev says, no they're not.  The DBA says, no they're not.  The boss says, no they're not.  The dev says he doesn't have time to fill out all the paperwork it takes to do the push.  The DBA says, you don't have 5mins to fill out a simple form, but you've got 35mins to go complain about it to everyone who will listen.  The dev says he just doesn't have time to do everything he needs to because he's way overworked and can't be bothered with stuff like that.  There's just too much to do.  The DBA says that's because you don't know how to work smartly.  You do everything by hand instead of using your tools.  The other dev agrees.  The boss doesn't comment, and the dev storms out of the meeting.

A couple more days go by and there are more complaints and more and then more.  The dev just won't fall in-line.  The boss calls another meeting to set things right between him and the others.  In this meeting they come to an agreement on how things are going to go from here on out.  So all's well, right?  Nope.  The dev leaves the meeting and ignores everything they agreed on and goes right back to complaining.  The boss calls another meeting to workout the problems but the dev insists that the issue is that he just can't do his job like that.  And the problem is that he hasn't documented anything and he's the only one who really knows what's going on from the coding side.  So you need this dev. 

Then the boss calls a couple meeting with DBAs, and other devs to talk about what to do.  The decision is made to give the man what he wants and let him have sa on the prod box.  Nobody else can have it cause they're not complaining, so back to business.  Problem solved right?  Well, not really.  The issue could easily crop up again if he gets put on another project or has to touch a different system.  And if people start wanting the same level of access it'll be harder for the boss to say no.

But do you see how much effort has been spent managing this situation when it wasn't necessary?  There's no work getting done at all because everyone is concerned about what the dev is going to complain about next... and they're constantly in meetings about it.  Something has to change.  And while I'm all for giving someone a chance, sometimes you need to see the writing on the wall and someone has to go.  And who should that someone be?  Well, I don't think it should be the devs who are playing by the rules.  And I don't think it should be the DBA who's trying to do what you told him.  So when should someone be let go for an issue like this?  Well, like I said up top, when it becomes more to manage than it's worth.  When you're doing more management of this one person than you're doing work, then it might be time to consider changing them out for someone else.

Because it's not just an issue of someone not wanting to follow a new process.  The issue is can someone work in a new world with a new way of doing things.  There are so many ways to make your job better, and to handle a ton of requests and if someone isn't out there looking for them and trying them, then they're not the one you need in that position anyway.  You want someone who will be on top of things and always strive to push in the new technologies so things are running smoother.  The rule I usually follow is if after a year, if I haven't been able to increase the productivity of my dept, then I'm not doing a good job.  I've often preached that there's a different between being busy and being productive, and most people just don't know the difference.  Being busy is answering requests and knocking out the tickets.  Being productive is actually making a process better, or making the dept better in some way.  Running tickets is what you do to keep the lights on.  Being productive is what you do so you don't have to work 90+ hrs/wk.  And frankly, if you're working that much you're just doing something wrong.

This also has a huge impact on the DBA in this situation... or it could anyway.  If he's in a big shop and he loses a big battle like this, then it's just one group that gets to do what they want, big deal.  But if he's in a really small shop then he's had all the things that make him a DBA taken away.  Now all of his processes, and code review, and added value of having a DBA on staff have gone out the window because the devs can do whatever they want and they'll just fix it on the fly.  The DBA is now just a backup monkey.  So I don't know... maybe it's time for the DBA to leave in this situation.  By caving in to the dev's demands, the company is saying they're not ready for a real DBA.  They're not ready to have a solid business built on data.  They're not ready to be up 24/7 in a global marketplace.  If they don't see the damage this type of cowboy mentality will ultimately cause then they're just not ready.

And you may recall a while back I blogged that if you don't stay on top of technology then you can't expect your DBAs to stick around.  We don't want to do the same thing every day.  We want to be challenged and we want what we do to matter.  And in smaller shops where devs are allowed to do whatever they like then the DBA is all but useless.

Copyright © 2012 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022