human choroinic gonadotropin

Archive for the ‘IT Leadership’ Category

5
Apr

Easter Sunday- What alerts did you receive?

   Posted by: jasoncbunn

Today we celebrate Easter Sunday, when Christians celebrate Christ’s rising from the dead.  This should be a relatively quiet day for IT.  Depending on your business, it even may be the end of a three-day weekend with the offices closed for Good Friday.

In the database administration space, Sunday is our maintenance day, at least for our firm.  We actually recently expanded our maintenance window to encompass most of the weekend in a staggered fashion.  We used to launch our integrity checks all at once and that time quickly became very well known by the storage team due to the IO load on the SAN.  Thus, we fanned those out over most of Saturday since many of the applications are offline over the weekend.  Sunday is reindex/reorganize day and even that has become much more spread out across the course of the day.

If all goes well, we receive zero alerts.  No calls, no pages.  I’m always perturbed when we get a page or alert for something that is expected or typical.  If the response is, “oh yeah, that happens.  Just ignore it,” then why are we getting called, especially overnight or off hours?  If I’m going to ask my team to rouse themselves out of bed, to remotely connect to our systems, and read an error message, the very strong preference is that there is an actionable item that needs to be corrected at the other end of the message.  If it’s a benign configuration anomaly, or a status message, then send an email and wait until morning.  If the process normally retries successfully, then email on the first failure, retry, and let my team sleep unless it fails a second time.  I don’t shy away from the work– if there is work to be done, certainly wake us up.  But the ideal state is that we only use the immediate channel of a page, text, or call if there is action to be taken.

So, we expect a quiet Easter and will pick things up on Monday.  Happy Easter!

24
Oct

Deadlines have meaning, even if no one is watching

   Posted by: jasoncbunn

The 4DX method talks about a cadence of accountability or a cadence of delivery. Making commitments and then following through on those commitments. It is where the rubber meets the road. It is where execution either happens, or doesn’t. When you put a date on a calendar, and tell yourself or others that the product will be released or the project will be done by that date, you are making a commitment.

There are two cases where I’ve recently seen problems. One is where there actually is no date defined, or it’s somewhat vague like “before the end of the year” or “this quarter sometime.” The claim is that there are too many variables, too many moving parts and too much dependence on other teams in order to define a firm date. While I sympathize, especially if you are relying on other teams, a goal isn’t a goal without a deadline… it’s just a dream. One of the skills an IT professional needs to develop is the ability to forecast and then manage the variables that feed into that forecast. Don’t just be content with Q42013, especially when it’s already October. Define a delivery date. Then, what are the blockers? Who do you need to come through for you in order to meet that date? What key metrics or interim deliverables are necessary? Get out in front of the potential problems, build contingency time into your plan, and if you need to adjust, it will be from a position of knowledge about specific issues that need to be resolved. Without a date, none of this can happen and you float through Q4 wondering what happened to all the time.

The other case is when a date is set, but no one cares, even you. Yeah, sure, we talked about December 1st, but if we miss it it’s not like anyone is waiting for it. While it may be true no one is waiting, people are watching. Once the date is mentioned, unless you operate in total isolation you have announced what your intentions are and people will be watching. It could be your supervisor or her peer, it could be another team delivering software to support your solution, whatever. If you don’t care about your date, why should they care when you need something from them? Do you want to develop a reputation for consistent, timely delivery, or do you want to be known as the guy everyone adds six weeks to whatever you say?

There are times when adjustments are needed, that is certain. No date is immovable. But if the target needs to be moved, it should be for specific reasons, identified far in advance. If you are shifting your end-goal any closer than 1 month prior to expected completion, there was a breakdown of project leadership, in my opinion. There are unavoidable edge cases that come up, but they should be viewed as failures to examine and learn from.

Consistent cadence of delivery builds a team the whole organization can trust. It’s worth the planning effort.