17.6.10

Freelancing in Ukraine

Companies like oDesk, eLance, and uTest have built a good business connecting freelance engineers with jobs and job-work. I've recently started working closely with a major crowd-sourced collaboration company on a project, and have developed a very favorable opinion of the work they get done.

So, this news strikes me as interesting, and a bit dangerous to their business model:


More info after the jump to Slashdot, but the gist is that the Ukrainian government is after the tax income from freelance associates paid by foreign companies. It's inevitable that this part of the economy would come under scrutiny, but probably wrong-headed to put onerous restrictions in place that shut down the ability for these freelancers to work on global projects...

Anyway, hopefully the guys at the above-mentioned companies are on top of this, since there I've worked with some great engineers in Ukraine recently.


4.5.10

A new time zone tool

I just this instant stumbled on a very nice tool that provides a quick, easy to understand graphic representation of time and time-offsets in (nearly) every time zone. It's called, cleverly enough, "every time zone."

Click here to launch a new browser tab in which this tool will load, in all its glory.

It looks as though this tool uses IP address geolocation to discover your local time. Then it gives you a slider so you can move your target time around, to see who you have to wake up early or keep up late for your next international conference call.

Having done this in excel for several years now, this is a nifty upgrade! It's in Beta, so keep your eyes on this one. Apparently it works on iPad as well, so one may hope for an iPhone and/or Droid version of the applet as well.


26.4.10

Some thoughts on change management

No pun intended, but the broad topic of change management has great currency in the business world today.

What people typically mean when they say "change management" is some structured approach to understanding the stages humans go through as they understand and cope with change.

This is prescriptive if you are attempting to manipulate or engineer human behavior, so it has great relevancy to Industrial/Organizational psychology. Thus it finds its way into the business world.

Like software development lifecycle models, there seems to be a change model to fit any mood or mental predisposition. I've seen these three commonly referenced in business world, and I'm sure someone with better Google fu could find even more change models:
In each of these change models, the important and useful takeaway is that the model defines and codifies some phases of acceptance or resistance to change. When the business world talks about change management, they usually mean something prescriptive, along the lines of:

Step 1: Adopt a model of change. Hire consultants or highly paid experts to train people to understand said model of change.
Step 2: Help people move from one stage of the change model to the next. (characterized, for the sake of my allusion, as "Eh?")
Step 3: Profit! (Usually for the consultants.)

In the interest of full disclosure, I will now reveal that I am a highly paid consultant, and that I sometimes make money helping organizations cope with change.

This is all interesting and good, but... this model of merely defining and facilitating adoption of change leaves a high-order problem unsolved.

That unsolved problem can be most figuratively described as "the death of a thousand little cuts."

A visual and graphic metaphor I've used to describe this part of the change management problem follows:

Imagine you are a surgeon, as am I, as are five or six of our best friends. Further, imagine that we have a patient in front of us. I have to do an appendectomy. You have to do a repair to the patient's ankle. Someone else is working on a shoulder repair. Someone else is elbow-deep in the patient's lower intestine. Each of these surgeries is survivable. Not exactly out-patient, but not a big deal these days. The patient would be expected to survive each of them, individually.

The problem comes when all of us try to operate on the patient at the same time. In that world, the patient certainly dies on the operating table... Too much surgery all at once, and the patient simply can't handle it all.

Leaving you with the mental image of that poor patient, stitched and stapled from stem to stern, we'll move back to the business world, and change models. The high-order bit that seems to get missed in all these model of change management is the apparently novel and foreign idea of change metering.

Back to my metaphor -- what would happen if we each did our respective surgery serially, giving our patient time to recover and heal between trips to the ER? It would cost a lot, but our patient would survive.

In my experience, humans can only metabolize so much change at a time. Further, it doesn't really matter what the change event is -- they are all psychically disruptive. They all require the psyche to adapt and to absorb the change. They all start a journey through some phase model, ignoring which one you like best.

What's important isn't knowing what to call the phases. What's important and mostly missed is understanding the capacity of the system to absorb change, and metering the rate of change so that the system doesn't get overloaded.

So, by long way of introduction, I've got a model I've been using to describe Change Metering.

First, you have to think about what you can do to people. In business, there is a fairly finite list of factors you can change within an organization. I break it down into 7 categories in my little model:
  1. Location - Where do you do your job?
  2. People - What do you do for a living?
  3. Team - Who do you work with?
  4. Leadership - Who's in charge?
  5. Technology - What tools do you use?
  6. Process - What modes and methods are the norm?
  7. Policy - What behaviors are mandated?
Within that 7-fold spectrum, you can have small, medium, and large change events. A few example change events follow:
  • Technology - Small Change Event: You get a new version of MS Office.
  • Technology - Medium Change Event: You switch from MS Office to Star Office.
  • Technology - Large Change Event: You switch from Windows to Linux.
  • People - Small Change Event: You switch jobs to a new but similar role.
  • People - Medium Change Event: Your job changes, and some responsibility goes away.
  • People - Large Change Event: You get promoted to a new job, with enhanced responsibility.
These are just examples, but you get the picture... Each change event in your work life, or in the work life of your organization, will fall into these seven buckets, and will be graded on this scale.

(Oh yeah, Small = 1 change point, Medium = 3 change points, Large = 5 change points.)

So, if you have followed me so far, you can see that using this model, you can easily build a multi-dimensional array of change, over time, over a team of people. It might look something like this:







(click to make this big enough to read...)

Now, as the table shows, you have a change score for every "significant" event that has happened to this team, over a few months. The next bit of this requires some hand-waving, but will work for the sake of explaining why change metering is so important.

Assumption 1: People absorb change at more or less the same rate.
Assumption 2: People can absorb change in about 6 months. Irrespective of the change model you choose to use, or whether you even have a change model in mind, in six months, people will have pretty much gotten used to their new (compiler, operating system, campus, boss, coworker, etc.).
Assumption 3: Change absorption is linear. (Why linear, you ask? Because it makes the math easier.)
Assumption 4: Though these units are arbitrary, accumulating more than 12 of them is bad.

Making these assumptions (and with the caveat that you can make up your own numbers, as soon as you get your own blog), you get a visual representation of the change absorption rate in this small team. (again, click on the image to make it big enough to read)


This can be immediately prescriptive:

As you can see, the whole team is going to be pretty stressed out in June and July.

If you were an executive manager and you were interested in, for instance, launching a big new discretionary initiative aligning your work norms to a new process model, you may want to wait until Q3. That slight pause in your roll out would prevent your change from overwhelming your team, and would give your initiative more mind-share and a better chance at success.

If you were the manager of this team, you should note carefully that you've got poor Amy in a state of perpetual flux. You might want to pay extra attention to her performance, and offer assistance as she absorbs her new role, new responsibility, and all the other change you've thrown at her.

In summary, change metering is more important than change modeling, but few people I've ever worked with have grokked this fact. If this model helps you, use it. Contact me via e-mail to negotiate royalty fees.

And to help amortize the cost of my graduate studies in philosophy, I will close with a quote from Heraclitus of Ephesus:

Πάντα ῥεῖ καὶ οὐδὲν μένει

Nothing is permanent but change

22.4.10

Doc Reviews

This blog entry has been in draft form for, oh, a long time. Before I forget what I wanted to say, I thought I'd finish it this morning...

Document review meetings are a necessary evil of software development, no matter what you consider "a document" and no matter what your SDLC is.

Whether it's a quick PPT slide review, a white board session, or a formal design specification review, you have to get ideas out of one brain, on to some transfer media, and into another brain.

Given the difficulty of communication in general, and the compounding impact of distance and cultural/linguistic difference, it gets even tougher. So document reviews are important to get right.

I've done two approaches successfully:

1: Conceptual Walk-Through

In this approach, the author of the document isn't the one presenting it. Rather, the author finishes the document (to any level of detail, so this will work in light-process SDLCs too), publishes it somehow (steps away from the white board, sends a PPT out in e-mail, or checks a document in to source control), and gives the recipient or recipients a chance to read or review the document. Then, the recipient, or a nominated representative of the recipients, has the task of presenting the ideas in the document as a walk-through. In this model, rather than a line-by-line or section-by-section review, you're able to test that someone understood what was being presented. The author has to be the judge of the quality of the walk-through. If there are problems with the presentation, then you learned one of two things: Either the reader has poor reading comprehension skills, or the document is unclear about the key concepts or ideas it's trying to convey. Either way, you need to fix something. If the walk-through is clear and on target, then the document is OK, and you have communicated an idea or several ideas between the author and the readers.

2: Line-by-Line Review, with a twist

If you are still committed to line-by-line document reviews (and these only really work for big, long documents like design specifications, test strategy documents, schema definitions, etc.), then you will know that the biggest problem with a document review is that people seldom read the documents in advance. In every design review I've ever attended or run, there are several people clearly reading the document for the first time, IN the review meeting. This is a waste of everyone's time. So, to fix that, you can make a game of the pre-reading. Sprinkle the document with passages of Shakespeare, or your favorite public-domain author. Put in whole sentences, here and there. Count the number of instances of text you insert. (Oh, and save a pristine copy...) Distribute the document with the Shakespeare in it. When you call the Document Review meeting to order, ask people in advance to let you know how many instances of Shakespearean prose they found in document. Do the section by section review, then at the end reveal the number of instances of Shakespeare, and give a prize to the person or people who got it right. There are arguments to be made that this will get people to skim the document looking for "Now is the winter of our discontent," but in practice, I've found that this methodology does get people to read and review the document in advance, and makes for a more productive and interesting document review meeting.

Your mileage may vary, as always.




26.2.10

The Shared Services & Outsourcing Network

I've recently been hitting this site every few days, for news about the outsourcing and shared services industry. As a news filter, it seems to catch what's important in the outsourcing space, so it's a good one-stop shopping experience for me. There is, within the site, a bunch of content around templates, best practices, and industry events (that they sponsor).

I'll offer the caveat that I haven't really explored their articles too deeply. As I said, I read it mostly for the news feed. But, it's a good site for that!


As always, your mileage may vary.

25.1.10

Booster shots...

Travel remains a constant backdrop to building and running global technology teams. I've written about this before, but thought this was worth a quick reminder to people.

If you travel internationally, it's a good idea before you go to check with a travel nurse and get a professional opinion about what you might or might not need in the way of immunizations.

I'm in my early 40's, and in my last visit to the travel nurse, I was informed that there are some immunizations that guys my age need boosters on (measles/mumps/rubella, I think). And some stuff you can simply protect against with a shot or two (some kinds of hepatitis). But I do NOT pretend to offer advice here, except to say that a travel nurse (or a general practitioner) would be able to lay it all out for you as a cost-benefit, and that's what they do all day, so they're good at it. When I went to India for first time I didn’t do anything with respect to immunization, second trip to Asia, I got the full treatment… Shots, anti-malarial drugs, etc.

As an aside, I've personally opted against the anti-malarial drugs - they give me vertigo - but again, that's just a personal preference so I’d advise seeking professional opinion…

Lastly, for anyone traveling to India or China (or Vietnam, or the Philippines, or whatever) if you’ve never been 9 or 10 time zones off home, you might want to see about getting sleep aids (stronger than over the counter) so you’re not a walking zombie the whole trip.

As always, your mileage may vary, but do consider seeing a travel nurse, and getting the run down first hand, from a professional.




15.1.10

Dusty old dust...

I remain in awe of bloggers who can, continually, for years on end, blog about three or four interesting things a week. Obviously, this blog has been inert for about 8 months. The bad news of that is that if I ever had a regular readership, they've stopped reading. The good news is that I've been busy as hell working, and I now have a bunch of ideas I need to write my way into and through, so I hope to pick up the pace again.

So, I'm re-launching this blog. Stay tuned for more...