Home > Community, Prof Dev > Working with Principles to guide you in IT Part 1

Working with Principles to guide you in IT Part 1

This is the second post in a series of at least 16 that speaks to the way I’ve come to practice DBA and Sys Admin work while meeting the cultural expectations set by my workplace.


Do what you agree to do.

Those have to be some of the simplest words in the English language to understand.  It certainly seems like a basic enough statement to me, however I’ve come to realize that this statement, like many others, is easier said than done.   There are all sorts of reasons why someone can’t, won’t or didn’t do what they agreed to do yet the end result is always the same.  Someone feels disappointed, a business goal is missed, a personal goal is missed, or confidence and trust is broken.

So, what does this simple statement mean to me as an admin?  It means that I have to think very carefully about what I agree to do at any given point in time.   Any time a request is made of me I go through a quick checklist in my head:

  1. Do I fully understand the scope of the request?
  2. Do both the requester and I have the same understanding of the desired end result?
  3. Do I have the time and capacity to fulfill the request at this time?
  4. Do I have the expertise and/or tools needed to fulfill the request?
  5. Am I the best resource to complete this request?
  6. Does this meet a business need  (critical or otherwise)?

If I can’t give an honest answer of ‘Yes’ to all of these questions I will continue the conversation with the person making the request of me and strive to either turn any of those no answers into a yes, or to find a more appropriate resource for the task.

It took me a long time to develop this list of questions, and honestly, prior to having them I often bit off more than I could effectively chew both in expertise and capacity.  I also found myself spinning my wheels trying to accomplish a task that didn’t meet a business need.   It’s not a great place to be as an admin (DBA or otherwise).   You wind up working late nights and weekends, loosing out on social events, family time, sleep, and personal time only to have your efforts fall flat because you provided functionality that wasn’t needed or wanted by the business.  Or, worse yet, someone in a leadership role notices that you’ve spent the time on a project or task that was essentially a waste of time and wants an explanation.

By working through this checklist each time I am asked to accomplish something I am able to ensure that the work I take on is meaningful, and is also something that can be accomplished.  It also gives me a little bit of extra credibility with the people I work with.  By asking these questions I am forced to evaluate my current workload on a daily basis in order to answer question number 3.  By knowing what I have on my plate at any given time, and by fully understanding what each task will take to accomplish I am able to set reasonable expectations with my co-workers.  I don’t have to guess about how many days or weeks it will be before I can get a new development instance stood up because I know how many other tasks and projects I’ve already committed to and approximately how long each one will take.  By setting expectations and being able to tell a requester that I will be able to complete their request, and that it will take a week because of the requests ahead of theirs we are able to either talk to the folks ahead of them in my queue to either re-prioritize, or worst case a reasonable deadline has been set and no one has to wonder when something will be done.

I will caution you that this type of scheduling and setting of expectations takes experience and time – give yourself some pad time if you’re not used to working this way.

The end result of all of this is that I ultimately meet more deadlines than I miss, my co-workers are happy with my performance, and I don’t feel stressed by deadlines most of the time.  Also, after a length of time working like this I found that I didn’t get nearly as much push back when I wasn’t able to commit to a request, or I suggested a different resource.  My co-workers had come to learn that if I was truly able to accomplish something I would do so, and otherwise I would let them know up front.

Now, I know, at least one of you out there is saying under your breath that this all sounds well and good, but we work in IT, and our workflow is not always within our control – and you’re absolutely correct.  Seemingly unpredictable things happen in IT, particularly on the Operations side of the house.  Machines experience failures of one type or another, partners don’t deliver code on time, or as expected, our customers (users) can have unexpected impacts on our systems.  All of that is absolutely true, and also absolutely manageable when it comes to adjusting expectations.  Communication is key here.  If you have issues arise that put one or more of your deadlines in jeopardy it impetus is on you to advise the folks depending on you of that.   It takes far less time to jot off a quick email letting someone know that their request is going to take a day, or week longer than expected because of a situation outside of your control than it does to deal with the consequences of missing that deadline to begin with.   And hopefully, you have padded your deadlines just enough that you might still be able to hit your original deadline – it’s a WIN\WIN situation if that happens.

Some side effects of working by this principle

There are some (for me) unexpected side effects of striving to work by this principle.  The first one is that I find myself asking a similar set of questions before taking on tasks in my personal life as well.  This causes me to evaluate what is important for me to accomplish at home and with my friends, and that’s a good thing in my opinion.  I know what I am capable of, and what is going to leave me feeling stressed so I feel like I have better balance in life.

I also am finding myself assuming that every one places as much importance on this principle as I do, and when others don’t meet their commitments to me it leaves me feeling more disappointed than I did earlier in life.  I find this side effect less okay than the first, because my confidence and trust in others seems to be more fragile than it reasonably should be.  I go into each interaction I have with other people expecting them to do what they agree to, and like it or not, many people just don’t – for many reasons.  I’m still figuring out how to moderate my reaction when other people miss deadlines, or just plain don’t do what they agreed to.  If you have any sage advise on ways to handle that please leave it in the comments – I’m all ears!

Related posts: It’s Confession Time

Categories: Community, Prof Dev
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: