A case study of “going to the cloud” (SaaS)

Here’s one series of questions that’s great to ask a candidate for a senior position in IT, be it in project management, development, operations, or whatever: Tell me about a recent project or initiative for which you were responsible. What was the goal, and how did you ensure that the goal was achieved? What were the roadblocks you encountered along the way, and what did you do to address them? What mistakes did you make? What would you do differently if you were faced with a similar project or initiative again?

For this post, I’ll play candidate and outline the kind of full and detailed response I would be looking for as a hiring manager, based on a project from my own experience. Let’s use a relatively simple one: implementing off-site (Software-as-a-Service, known as SaaS) email, replacing a poorly implemented in-house email system. Today, this would loftily be called “going to the cloud.”  (Yes, I’m aware that cloud computing encompasses far more than SaaS, but that’s not my thrust here).

[Read more…]

“Hot stove” lessons, part II: development and operations

I noted last time, once again, that “IT is hard. In fact, it’s so hard that it seems most people have to learn certain core lessons by themselves.  It seems like everyone needs to burn his or her own hand on the hot stove.”  I went through some examples of this sort of “hot stove” lessons particular to management; this time, let’s talk about similar “hot stove” lessons/myths I’ve observed in other IT areas, most notably development and operations.

  • Source code control and release management. One of the traits of a superlative programmer is his or her ability to maintain a complete logical model of the system/program in their head.  The really good ones are in fact really good at this.  Unfortunately, their consummate skill ironically leads to them sometimes resisting tools that help out with some of the logistical pitfalls that arise as system complexity increases.  Source code control is the most important such tool.  Programmers have even told me, “I can just keep track of what I’ve changed and what’s where.”  In a way, I suppose this is a species of the (typically male) trait of refusing to ask for directions—it’s a reluctance to embrace appropriate tools that are designed to avoid common screw-ups and to facilitate overall team success.  Suddenly, though, complexity mushrooms: releases overlap and patches are made in the heat of the moment, and without impeccable source code control and release management, bugs reappear, QA takes longer, and so on.  Typically, I’ve seen this “hot stove” lesson not really get learned by an organization until the source code control failure causes a notable customer-facing issue with a major release.

[Read more…]

“Hot stove” lessons in IT, part I

Regular readers here have certainly noticed the recurring nature of many of my posts: “things about IT that should be obvious, but clearly aren’t.”  Each week, as I set about writing on my chosen topic, it often strikes me that what I have to say is anything but new or radical; rather, it seems to embody fundamental, well-known practices and underpinnings that should be, if not incredibly obvious, at least quite familiar to anyone who’s spent much time in or around IT.  Yet, as I reflect on my actual experiences, I realize anew that I’ve spent much of my career working up and down the executive and worker chain to absorb and impart these basic principles again and again.

So here comes more of the same.  In fact, this dual post encapsulates a lot of what I’ve written about on this blog for the last year: lessons learned and lessons still learnable about IT for the people who work in it and the people who have to deal with it.  In other words, I should hasten to say, these are not only IT management lessons, but lessons related to development, operations, QA, and project management: in other words, the whole spectrum. 

As I’ve observed before, IT is hard. In fact, it’s so hard that it seems most people have to learn certain core lessons by themselves.  It seems like everyone needs to burn his or her own hand on the hot stove.  So here are some of the glowing redhot stove elements that I’ve watched make fingers (including mine, for I’m not immune either from learning some things the hard way) sizzle over the years.  I’ll start here in part I with lessons particular to management, and next time will cover similar lessons/myths relating to other IT areas.

[Read more…]

More astounding IT utterances

A few months back, I wrote a post on various “Astounding Sayings” that I’ve encountered in my career in information technology.  It turns out that it’s been one of the more popular posts I’ve written, judging from page views, so in true Hollywood fashion, it must be time for a sequel.  I am retitling it slightly, though, to distinguish it from the Peterisms I post from time to time.  The point of writing about the “astounding” sayings was that they usually reflect misguided energy (or, to put it bluntly: wrong-headed thinking); the point of the Peterisms, on the other hand, is to distill and communicate absolute, undeniable, sublime truth and wisdom at every possible turn. (Hopefully it’s unnecessary, but just in case, <insert smiley face here>.)  Hence, I’m now going to call these non-truthful, unwise sayings “astounding utterances” instead.

Here are two more such utterances, with moral-of-the-story observations for each.  Note: as before, these are true stories.  I may have changed some of the facts, lightly, to make them less identifiable.  They also always come from at least several years in the past, to provide a healthy amount of distance for everyone.

[Read more…]

“Astounding IT sayings”: the inaugural post

I haven’t given myself the luxury of telling an IT anecdote or two here recently, so it’s about time: here are two, with moral-of-the-story observations for each.  Note: these are true stories.  I may have changed some of the facts, lightly, to make them less identifiable.  They’re also always at least several years in the past, to provide a healthy amount of distance for everyone.

I’d actually like to make this post the first in a recurring motif, a series that I’ll call “Astounding IT Sayings,” for what I hope are obvious reasons.  The saying that I consider to be astounding, in its context, will be highlighted for you below in bold.

[Read more…]

Mastodon