More on the Relative Value of Projects


A while back, I blogged about the importance of recognizing database values.  If you’ve got a dozen databases on a server, and one of them is hogging resources, how much is that database worth to the business?  If it’s a database housing low-value data (like employee web surfing habits) and the other databases are much more valuable (like incoming sales) then that guides your fix.  Move the low-value data to a lower-value server, or move the higher-value data to a higher-value server.  Don’t make your high-value apps suffer at the expense of poorly written low-value apps.

Saturday on Twitter, I was talking with another DBA (who shall remain nameless lest this come off in the wrong way) about a project.  He needed a free or low-cost way to monitor a free server with low-priority applications.  He said the company didn’t see the value in spending money to monitor those apps, so he didn’t have a budget.

I’ve been there myself, and I feel that pain.  I remember being a DBA and saying that every database was important.  Just because a server is development doesn’t mean it’s unimportant – if it goes down, the developers can’t work.  I like the developers, so I need to protect their server, right?


Come back to the most basic part of the problem: the company doesn’t see the value in spending money to solve that particular problem.  It’s tempting for us to want to be the hero, to save the company money, to accomplish something they ordinarily would have had to pay money for.

Sleepless in Seattle
Sleepless in Seattle

But it’s the weekend.

They don’t call it free time because it’s free to the company.

Don’t get me wrong – I love working on the weekends.  People who love what they do, love doing it every day of the week.  I can say this with absolute certainty because it’s a bright, sunny day outside in beautiful Seattle, 9am, and I’m sitting in a Microsoft office studying.  But on the weekends, take a step back.  Step away from your day-to-day priority list and think about doing things that:

  • Things that energize you
  • Things that will pay off for your career long-term
  • And if you’re gonna work, pick things that the company sees the most value in

If they won’t give vendors money to solve a problem, they probably won’t give you a raise or a promotion for solving it either.  Go solve things that make your company executives drool with anticipation.  Follow the budget, solve the problems they see value in, and they’ll see value in you.

Previous Post
SQL MCM Day 3: Thieves and Clerics
Next Post
SQL MCM Day 7: One Week Down

17 Comments. Leave new

  • This is a lesson I’ve had to learn the hard way. It’s also about priorities. If it’s not a priority to the business, why should it outweigh your own personal priorities, even if that’s sitting in an overstuffed easy chair watching March Madness?

    • You got it. If you look around the office and you’re the only one there, or nobody higher-up in the org chart is there, then you’re taking your work more seriously than your supervisors take your work.

  • In the real world there is a discrepancy between the business decision makers and the IT personnel. For an example, I have seen quite a few work environments, in which the business is navigated by non-technical people which dictate the budget and the decisions of the IT department. And when it has been up to me I have never let it go “just like that”. And not because I like to work out my muscles by swimming upstream, either.
    In a situation where the management would decide not to maintain (or not to pay attention) to important part of the system it is best for the IT people to step in and to do their best to enforce the logical flow of things.
    And yes, running after the dreams of the executives in the real world brings mediocre IT environment and semi-happy employees.

    • Feodor – I’m going to say something that might be a little hard to take, but hang in there for a second.

      If you and your manager aren’t aligned on what’s important, both of you are at fault.

      I can’t just say, “My bozo manager doesn’t understand how important ___ is.” If I believe something’s important and he doesn’t, then either I’m not doing a good enough job of selling him on what I believe, or he’s not doing a good enough job of selling me on what he believes, or one of us is being stubborn and selfish.

      If you believe something is very important, and you do your best to explain it to management, but they still say it’s unimportant, it’s not the manager’s fault. It’s yours. You’re not understanding its unimportance to the business, or you’re not doing a good enough job of explaining it, or you’re not understanding how few resources the company actually has.

      • Brent, here you are absolutely right and I utterly agree with you. I guess I just might have misunderstood the last sentence of your blog post: “Go solve things that make your company executives drool with anticipation. Follow the budget, solve the problems they see value in, and they’ll see value in you.”

        The bottom line is that the well-being of the company is really the result of collaboration between the business decision makers and the IP people, and especially the quality of communication between them.

  • Malathi Mahadevan
    March 20, 2010 1:25 pm

    “Go solve things that make your company executives drool with anticipation. Follow the budget, solve the problems they see value in, and they’ll see value in you.” Yes, absolutely. The only exception perhaps is if you are wanting to learn something and the work environment offers the potential, but not the recognition. I have put in the extra hour for many mean companies like this before, i didn’t get anythign in return from them but i took that as a recognition of their stupidity than anything else and eventually moved on. The skills i learnt did help me in further jobs. Not everyone has servers at home or other means to learn and if the work environment offers that potential there is nothing wrong in taking advantage of it as long as you know what you are doing and dont end up a victim. Yes of course selling them what they are looking for is by far the most important professional skill there ever is, there is no understating that.

  • Their are similar situations on the database development side with those low value apps/databases:

    –The proc you know that would run 2-3 times faster if you just put a few hours into reworking it.
    –The tables that are missing primary/foreign keys or indexes that you would like to add.
    –The ugly report that would look so much better with a little clean up.

    As much as I like to fix up my databases so they hum along sweetly, I often need to remind myself to stay focused on the needs of the business and my end users, even though it may not be the work I want to do (or the most exciting).

    Now, if you will add to your skill set by taking on some of these low value projects, by all means do so. But not at the expense of the very real business needs of your company.

  • Great post Brent and great comments as well. I have a half written blog post regarding a time when I didn’t follow this advice and was burned.

    I would like to add though, in your efforts to educate your manager on the importance of a task, you need to document that you informed him/her of the risks of not completing said tasks.

    In the test server example, if you don’t document that you warned the decision maker that a development server outage will cost X thousands of dollars in lost productivity, then he/she may “forget” your verbal recommendations in the face of scrutiny from upper management.

    Been there, done that.

    • I have mixed feelings on the documentation thing. I agree that it’s good to have in your back pocket, but the instant you take it out, you’re screwed. Taking it out means there’s a divide between you and management, and it’s about to get worse. When you prove they made a bad decision, you’re marking yourself as a troublemaker. So what if your boss gets fired over the mistake? His boss isn’t going to trust you, because he’s going to know you’re the kind of guy who will cover your rear and throw him under the bus to protect yourself.

      The only way the CYA approach has worked for me is when I’ve taken my boss aside, shown him the proof, and said, “You can still blame me in public, and I’ll take the flak because I don’t want you getting in trouble, but I want you to know that we made this decision together. I wouldn’t have gone off and made a decision like this without your help, because I know I need input from a senior person like this on these big decisions. I’m not off going rogue.” That way, the boss knows you’ve got proof and he can’t fire you, and he knows you’re a team player. He may let you take the flak, but he’ll fight to make sure you’re not disciplined too seriously.

  • Excellent post, Brent, and I agree regarding your comments that if you and your boss are not in alignment about what is valuable, you’re both to blame. And taking off on that just a little bit, in these economic times, I have found that sometimes there are things that I feel are important to do or cleanup as a matter of professionalism or pride in my work that the business may not value as much. If I’m not able to sway their decision, then when it comes to those things, I will either put in the time on my own to take care of it, not expecting any recognition/reward for it, or I will log it in our item tracking system (we use it for DBA stuff just like we do for developer stuff) so that we don’t lose track of the issue and can readdress it later when perhaps conditions have changed.

    On a similar note, given the possibility of corporate takeovers and professional audits, I like to log things that I know should be done but have not been able to (or have not been valued highly enough yet) so that I have a record backing me up in case of audit/change of management, that, yes, I do know how to do this job professionally, and while some things may not have gotten done, it is not because I’m ignorant or incapable. Sometimes I just have to recognize that I value some things more than my company does, and we have to “agree to disagree”.

  • Great post Brent. I think everyone who’s been in IT for any length of time has encountered the incredibly frustrating issue of trying to reconcile our client’s (i.e. the businesses we support) priorities with what we feel is the “right” set of stuff to be working on.

    Recently my team took a survey of our clients and asked them “What do you want from your DBA team?” We gave them several choices and asked them to rank how important they felt each was. The choices included (among other things) stability of systems and rapid response to new releases. Not surprisingly, the latter came out on top, despite the fact that we, as DBAs, felt very powerfully that it should be the other way around. Sure, we’ll argue it a little and try and show them some good, logical reasons why we think their priorities are wrong, but ultimately they sign the check and it’s their call.

    Once you hit that point, I think you have two ways to go: you can continue to play the role of the a-hole that is always arguing and complaining that he has to work on weekends to get his “important” work done, or you can accept that your client’s priorities are what they are, and try and work within them. Well, I guess there’s a third choice: quit and start blogging about SQL Server full time, but most of us probably aren’t that brave in this economy. 🙂

    Keep up the good content.

  • One way I have found to handle things like your fellow DBA dealt with concerning monitoring is to call it our in a repeatable fashion.

    For example, if you have to submit a status report, create a section for risks that you observe. I use this section to put in things that I see as major risks to our day to day operations. I also color code them the basic green, yellow, and red. I also have a suggest fix section, and then finally a ETA. If there is no ETA I just put “TBD.”

    This allows me to get visibility every week in a consistent, but non-confrontational manner. It is also a great CYA excercise. It’s private between your manager and you, but still documented.

    Now, the other thing is to not to sweat the small stuff. This low priority DB may not have been worth the cost of the monitoring agent. Managers are in a tough spot, and often have to deny things that might really be needed. The important thing is to make sure you are selling it properly.

    Lastly, save weekend work for challenging problems at work. I build a CMDB on weekends because it was something we needed, and it was a good challenge. Otherwise when I have some time on weekends when I am bored I usually catch up on paperwork, and the mundane stuff. That leaves time at work to take on interesting challenges during the workday when everyone is around.


Leave a Reply

Your email address will not be published.

Fill out this field
Fill out this field
Please enter a valid email address.