Archive

Archive for the ‘Prof Dev’ Category

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

It’s Confession Time

June 9, 2011 3 comments

I have a confession to make.  I’ve been working for the same company for just 3 months shy of 13 years, and I’ve been a part of that same company’s IT Operations team for just shy of 12 years.  I know, I know.  That simple fact makes me a dinosaur in the IT world, and it also means that I’m likely underpaid and that I likely have a limited set of experiences from which to draw from.  While I recognize why IT folks hop around from one company to another I have a handful of reasons why I’ve stayed in the same place for so long, and why I have no intention to leave any time soon.  This post and subsequent ones will share some of those reasons and hopefully show you that it is possible to find a perfect fit where employment is concerned.

I have my reasons.

The first thing I want to share with you is that the company I work for and I have shared values.

No, really, we do.

I place a high value on family, friends, and local communities that I exist in.  So does the company I work for.  It is a privately held corporation that has been run by the same family since the beginning in 1944.  The sons and daughters of the founder sit on the board of directors with the addition of a few close, long-term friends.  I know that for some the idea of a medium sized corporation being run by brothers and sisters is a bit scary, but trust me – it works in our case.   The company I work for participates in both the local community via charitable donations to local groups and allowing and encouraging employees to take part in local efforts like Junior Achievement.  It also participates in the community we serve with our business by donating to groups like Jewelers for Children, assisting with sponsorships to events like The Santa Fe Symposium, and processing scrap precious metals for efforts like Jewelers for Japan.

The company I work for and I both place a high value on our impact to the environment.  I am able to recycle at work almost more easily than I can at home, there are efforts to reduce energy usage, reduce waste, and in general be good citizens of this planet that happen on a constant basis at work.  I know that these things all make good economic sense in the long run, but they do take effort to coordinate and maintain and that time and effort can all but eliminate any cost savings you might see as a corporation, yet the company I work for still does it.

The company I work for takes a principle-based approach to guiding behavior rather than being bound by rules that have no flex or give.  This is a big one for me.  Nothing makes me more frustrated than a rule that doesn’t apply to the situation, yet must be enforced because it is the rule.  By allowing principles to guide the behavior and our decision making process we are able to be more agile, make quicker decisions, and adapt to situations more quickly than a business that is bound by a rule book full of policy and procedure, and that suites me just fine.  As my family and friends can attest I stopped seeing the world in black and white a long time ago, and working in a company that recognizes the multiple shades of gray, while maintaining ethics and remaining law abiding is just about perfect for me.

Speaking of Principles

While I’m mentioning our principle-based approach, it may be helpful for you to see them in print.  It will give you a basis for where I come from in both my writing and my presenting.

  1. Do what you agree to do.
  2. Do not encroach on other people or their property.
  3. Create an environment of trust.
  4. Be open and honest.
  5. Treat everyone with dignity and respect.
  6. Express and value all feelings, concerns, and ideas equally.
  7. Exchange your best effort for the best effort of others.
  8. Develop long-term relationships of mutual benefit (WIN\WIN)
  9. Have fun.
  10. Passionately develop and pursue shared and individual purposes and goals.
  11. Strive to maintain a positive attitude at all times.
  12. Maintain your power to succeed by choosing not to believe you are a victim.
  13. Take responsibility for your part in each live experience and learn from it.
  14. Be successful by helping others to be successful and accepting that help for yourself.
  15. Lead by influence (using reason, benefits, and inspiration) rather than by coercion (using force, fear, and innuendo).

So there you have it, the 15 principles that guide the way the company I work for treats it’s stakeholders, and in this case it’s stakeholders are the owners, employees, customers, vendors, and any other partner you can think of.

Go ahead, read that list again.

I think it’s pretty impressive, and quite a lofty goal to get more than 300 people from all different walks of life to not only try to meet those principles, but to actually follow them day in and day out.  I’m happy to report that the company I work for is mostly successful at doing just that, and it makes for a quite happy workplace.  I do have to confess that it’s not easy to follow every principle every single day, and as a DBA and Sys Admin it would be a lot easier to use the ‘because I said so’ reason to explain many of the decisions I make about systems.  What I can tell you is that by following most of the principles above, especially when explaining to someone why they can’t have DBO rights to a database, or why they can’t be added to the Domain Admin role to simplify their access to files on the network there are far fewer hurt feelings, significantly less push back when I have to make drastic changes to permissions or systems, and honestly it takes less effort and time to treat people with respect and show reasons and benefits to changes than it does to have an argument about it.

Next up I will talk a bit about each of the principles and how they apply to IT.

Categories: Community, Prof Dev