The Myth of the Transition Plan

When an employee leaves an organization, there is a weird period where the organization panics a bit. Maybe it was clear that the outgoing employee was awesome at creating things, but maybe a little weak about documenting them.  Or maybe the employee was a single point of failure on a couple different systems or components, or just legacy knowledge that will be orphaned or disappear on departure.  Could even be that the outgoing employee was the only trained backup for a couple people who have already left.

So what do the organization do?  It creates what's called a "transition plan."  This plan is supposed to reduce the outgoing employee to a set of disciplines that need to be transitioned to as many people as the responsibilities dictate.  What's the typical response to this? 

This transition is supposed to take place through a number of mechanisms: in person meetings, tutorials, documentation.  When an individual announces their departure, it's often kept quiet a couple days as possible negotiations, or risk mitigation, or simple grieving happens.  If the employee was kind enough to give two weeks, and the organization isn't one that kicks people out more quickly, there's usually a maximum of eight days to get a transition done.  As a result, a transition is often ill-planned, hastily thrown together, and often misses some key things that get forgotten in the rush.  

I've been thinking about this a lot lately.  In my time in my current employ, I've inherited a lot of legacy information, either suddenly from another outgoing peer, or by being the only one to dig through the detritus left behind when everyone who knew anything about the system was long gone and unavailable for question. In fact, I've dug through so much legacy code to discover crusty old systems that I adopted the "Software Archaeologist" moniker.  Note, I find the digging through code fun, but can be construed as a symptom of poor knowledge transition and organizational knowledge retention.

Why Transitions Are Rather Pointless

Transitions are lossy.  When a few people get into a room to do a transitional walkthrough, say of some code, what people don't realize is that there's not much hope of retention of the entirety of the information. The presenter boils everything down to only what's absolutely critical, and then the audience takes away only a fraction of that.  Spaced repetition would help this somewhat, but this information will likely be broadcast at most once.

The outgoing employee has no motivation to excel.  Sure, people are going to be professional, and no one wants to leave ex-colleagues in the doo-doo.  Can't burn those bridges!  But I've never seen anyone put anything remotely approaching enthusiasm into a transition plan. They do as they're asked, but if they don't do a great job, what's the worst that could happen to them? There's not a single motivating factor to make sure what's left behind is a well-oiled machine.  If an outgoing employee is leaving now, it's very likely you've not had their enthusiasm for a long time anyway.

Recipients are not engaged or open to transition.  The people receiving the knowledge transfer aren't leaving.  They didn't pick the timing.  They were not looking for more work.  Because they already have a job that doesn't involve what's being transitioned to them, they're likely already busy with what they're doing and aren't thinking of this new task or set of responsibilities. Maybe they don't want this new work or type of work, see it as an imposition, or see it as the company trying to put more pounds of sticky mess into an already overflowing bag.  A transition may be very demotivating to the remaining worker, and I've never seen someone say to those recipients, "Hey, I know you're already overloaded, but we really appreciate you stepping up and picking up this extra workload.  Here's how we plan to mitigate this departure's effects on you."  Never.

For infrequently used knowledge, the transition survival rate is basically zero.  When an employee transitions out, the proactive part of what they were working on often gets put on hold, and those transitioned to are basically there just to maintain the status quo of those things, meaning that the transition recipient may not use the knowledge for weeks, months, or even years.  By then, even the 10% of the material they understood from the transition has decayed significantly.

Transitional knowledge doesn't survive a second transition.  Given that the transition is lossy, and that information that is broadcast is often not fully received, you can call this observation "simple probability theory."  If information has a 10% chance of surviving a transition, then the second transition has a 1% chance of transmitting the information.  Even if you think the transition rate is higher, subsequent transition success diminishes with time and number of people.

Managers are not accountable for the information, only "planning the transition."  When a manager's employee leaves, they have to scramble.  They often do not have enough bandwidth to absorb the loss of the productivity of a full team member, but they have to do the best they can.  They can write up a transition plan, schedule the meetings, and walk away saying, "well, I did all I can do."  That's true.  Once you let your organization get to that point, that's the best you can do.  But when the transition doesn't survive for the long term, and there's inefficiency due to current employees having to mine out information from source or worse, there's no managerial accountability for the resulting drag on productivity. 

What Would Work Better

Okay, so I can't give some prescriptive advice here based on what's worked better for me.  I've never seen good transition.  Here's some quick hits that would improve the situation, though.

Don't need transition.  Just don't need it.  It's that simple.  Transition, as I've described it here, is not absolutely required.  These transitions often occur in an organization that is ill-staffed, and everyone has a unique, non-overlapping set of job responsibilities.  If no one else works on the same thing as the outgoing employee, then the amount that has to be transitioned is 100%.  If there is sufficient overlap, backups, and bench strength, transition is often not an issue.  Managers should regularly analyze their teams for single points of failure and work diligently to ensure knowledge is spread around.

Have an employee DR plan. It's amazing how many organizations plan for system outages and put DR plans into place for when computers go belly up, but absolutely fail to recognize that they are guaranteed to have permanent personnel outages eventually, and that they can't necessarily predict when those will happen. Most organizations plan for months to do a single day of system testing to demonstrate that they can handle a building or a system outage.  Every application we write has to have a fail-over story, a way to recover if the database is missing or an app pool spins out of control in IIS, chewing up all the resources on the app tier.  The same organizations that spend millions on that do no visible planning for permanent employee outages, which happen all the time.

Transition to documentation. If you do find yourself in a position to need to transition information, it is not sufficient to have a meeting to do a simple code walk-through of the most common path.  The most common path should be documented in an architectural doc already.  Have a walk-through detailing the exceptional cases, how to troubleshoot common issues.  And in that session, take notes.  Then publish them to your internal knowledge base.  You do have an internal knowledge base, right?  Oh, dear...

Maintain an organizational knowledge base.  If you don't have one, start one.  As a leaf-node resource, you may not have much say in where this is, but if you're a manager, get this up as a shared network drive at minimum.  Better still, some kind of document management system.  SharePoint document libraries are an obvious answer in Microsoft shops, and I've used a SharePoint wiki as a knowledge base for a few years now. It's searchable, editable, auditable, and shareable.  But whatever you do, have somewhere that this information can sit and be discovered later.

Transition to Video. I've actually used this strategy on my own departure previously.  You'd have to ask the recipients whether it worked effectively though.  When the time comes, interview the outgoing employee. Ask for the knowledge to be presented, and video record the whole thing.  Often, this is faster than writing all the documentation down, is less onerous than sitting and writing documentation (so you have a better chance of getting better information), and if only 10% of the information is retained, you can go back and mine the video for more.  And you can possibly produce documentation from the presentation if need be.

Encourage a culture of sharing.  This falls into the category of not needing to transition, but retains a different flavor somewhat.  If your employees self-organize, if they pair up on coding and other job responsibilities, if they regularly collaborate, then you have a much diminished need for panic transitions. More people will share ownership in more artifacts.  And the flatter the hierarchy, the more the management shares that ownership, and panics less.  

Maintain a culture of transition.  These transitions are often a surprise because an outgoing employee does everything possible to hide the potential that they might be leaving until the last moment.  This can be because the employee is hedging and thinking about not leaving, the deal can fall through, or a number of other scenarios.  There is fear that once identified as someone who might leave, opportunities will cease coming your way.  Thing is, everyone is a candidate for leaving at any time, if they are an individual of talent that is visible in any way to the outside world.  And if they're not, they're probably not good enough for you to want to keep (because they're not competitive on the market, say).

Conclusion

Losing employees is expensive.  Locating, hiring, and retraining a replacement employee can cost half an FTE or more.  You lose more than the employee's productivity.  You lose their organizational memory and their contribution to both present and future corporate culture.  Given the amount of time spent transitioning and the retention that results, you're better off not bothering with so-called "transition plans" and letting your employees, both staying and outgoing, be productive through the transition. 

Transition is inevitable, though, so you have to have a plan for talent management that involves identifying performers, keeping them happy, making sure you know what they want, and how to help them move on when it's time. This isn't an easy thing to balance, I'm sure, but it would mitigate the risk of loss of organizational knowledge and disruptive schedules if an organization could do that correctly. And knowing that you can't keep everyone (and you may even want some of them to go), develop and nurture a culture that supports flexibility and sharing. 

Group Coding, Benefits and Observations

A few years ago, I started up a weekly tech seminar in my organization.  We do everything from demos of new technologies, to sharing technical issues and solutions we found to them, to watching videos from the web of our favorite speakers on technical topics.

There's another thing we like to use this time slot for: group coding sessions.  We take a simple problem from Project Euler, and we code it up as a group on a projected screen.  The sessions allow the developers to share tips on tools, talk about the right seams in code, and

Someone asked me why we would code in a group, and I sent them the following

Benefits

Here’s the benefits as I see them:

·         It’s great for everyone to get to know each other. 
·         It’s great to work with other people and learn how to develop in a more collaborative environment. 
·         It’s great to create a more collaborative environment. 
·         It’s great for everyone to know everyone else on all dev teams.  Especially as some groups are more segregated than others.
·         It’s great to see how people use tools differently, as we all use things differently and become more productive as we work together on things.

So from an organizational standpoint, it’s all good.

That's what I said.  The details are a bit more complicated.  Let me talk a little bit about some overvations I've made and lessons learned.

Results

We've seen great results from working together in these sessions.

It's no secret that I am a big fan of NCrunch (I tweet about them from time to time), and that and ReSharper are two of our key dev tools.  We got enough licenses for every developer to use both, but people weren't really using them.  After seeing the tools in use as we do a test-driven style example, people come up and ask for their license.  Spending a little time coding together has meant that we get a better return on the tools we bought, in terms of usage (hopefully they learn to use it wisely).

We usually send out the solution after the exercise, so everyone can work on any finer points after the fact. We've seen people dive deep into an optimization, or work on finding analytic solutions to brute force problems.  It gets people thinking about something other than the features their day job offers them, and they seem to be really excited about these other opportunities (I'm using the proactive follow up as evidence here).

Further, you get some peer recognition.  Everyone contributes some code, and those people who can code get the kudos of their peers.  Better still, we've found hidden talent and enthusiasm in all our colleagues.  It's great to know who can do what, and it's great to give them props for doing so in a group.

I don't care who you are.  When you start out, coding in front of people is hard.  You have to let go of that ego.  You have to silence that little voice of doubt.  You have to get past freezing up.  And it's better to do it here than, say, during a job interview or a more important coding session at a conference, meetup, or Hackathon.  And everyone does it.  It's harder for some than others, but you see them grow in confidence, both in themselves and in their code.

One Big Observation

One thing that kills, absolute kills a group coding session, and that's negation.  Someone else writes a test and implements a method, and the first thing the next guy does is delete the body of the method and put in a pet implementation.  Maybe it's better; maybe it's not.  I've seen both, actually, and what is most important here is a concept straight out of the improv comedy world.  I know it's a weird place to apply the concept, but one of the core concepts of improv is that you never negate anything anyone else does.  You build on it. You manipulate it.  But you never simply say no.

Imagine a comedy sketch at The Second City that goes like this:

Milli: "And now I'm a T-Rex trying to make a peanut butter and jelly sandwich in a military cafeteria."

Vanilli: "No, you're not.  You're eating a pizza on the set of The Sound of Music."

And where does Milli go from there?  Vanilli has just taken the momentum out of the skit and turned things over on their head.  The same thing happens in a coding session.

The trick of great Improv is "Yes, and..."  In the Milli-Vanilli sketch above, Vanilli can do this by saying, instead:

Vanilli: "Yeah, and I'm a four-star general who walks in and does a double take as you cut the crusts off your sandwich."

Momentum saved, and the skit moves forward.

Yes, And 

So do this while coding.  Sure, someone may have just taken a misstep.  Maybe you see a more optimal way to do something.  Maybe you think your way is cleaner.  Keep that to yourself and don't negate what someone else has done.  Add to the example as is.  One of a couple things may happen. The example might evolve until it's obvious why your way might have been better.  Or you might learn something new.  Either way, I've observed that sessions that are allowed to evolve dynamically are more enjoyable.

Conclusion

I happened to be talking to Clark Sell on Friday during our That Conference call.  He's currently reading a book on Improv Wisdom, and said something very similar.  I haven't gotten to read the book yet myself, but I recognize the rule on the cover... "Just show up."  Which has a familiar vibe to what draws me to the tech community.  A big part of getting better is speaking up, doing, and making things happen with the people around you who also show up.

So get your code on.  Do it now.  Do it with your co-workers.  Just because you're dark matter, doesn't mean you don't matter.  You can do it.

Drinking in China

Snow beer is the most popular beer in the world, despite being sold almost exclusively in China.  It was the first beer I had on the trip (on the flight there), the first of many.  I was most fascinated by the pull tab on the beer can, something that I hadn't seen since the '70's or '80's.

I didn't know that drinks were included with the international flight.  Hainan airlines really treated us well.  I haven't flown internationally since our wedding and honeymoon, so I don't know if including wine and beer with the flight is typical or atypical, whether it is for all airlines, or non-American ones.  I would be interested to hear in the comments section if anyone can supplement my info.

Staying hydrated in China is tough.  The tap water there is not for American constitutions, and may make you sick.  Luckily, you can drink beer anywhere you want.  Snow beer, for sure.

No kidding - this isn't really beer.  This is lighter beer than Budweiser.  It's just a slightly hoppier and slightly more alcoholic version of seltzer water.  So I'm not sure it's actually possible to get tipsy off Chinese beer unless you're a thirty-pound child.  Which I'm not.

Given the tour we were on, Master (our bus driver) kept a cooler full of beer for us and charged us a buck a beer to drink on the bus.  Better still, we could buy one as we were getting off the bus and just walk around any old place with it.  As an American, worried about open container laws and such, I'm not used to that.

Mmmm, bus beer!

I'm especially not used to feeling freer in communist China than I am in my home country.  That's one of the things that traveling really does, it opens your eyes to the myth of American exceptionalism (a phrase that appears to be completely not unique - the google search results boggled my little mind).  Cultures are different certainly, but there are always places each culture can improve.

As an aside, Master is the title used for bus drivers on these tours.  When you see twenty-six million people navigating the area around Shanghai, and the bus driver has to navigate between other buses, cars, mopeds, rickshaws, and bicycles with huge piles of stuff on the back... Well, you realize that you have to be a master to drive in that mess.

Anyway, it was awesome to have beer on the bus.  Coming back down off the trek up the Great Wall under a beautiful and rare blue sky and a hot bright sun and onto the bus, it felt so good to have a cold drink.  And strangely enough, although it was $.50 for a water and $1.00 for a beer, only the beer was cold, so what would you expect us to drink anyway?

The Great Wall is quite a climb.  Phew!  Give mah some beer!

And with all this near beer, water beer, snow beer, you'd think we had plenty of beer and wouldn't want any with our meals.  But still...

When we went out to eat, drinks were included with the meals.  But they'd only give you about four ounces of whatever it was you were drinking.  But more often than not, they'd leave a 22 oz bottle on the table. They wouldn't give you more.  That was it for the table.  So it was a shrewd move to sit at the kids table. Drinking at the kids table was aces.

Mmm, yeah!  Dinner beer!

On the streets of Hangzhou, from a streetside shop, I stopped for a bubble tea.  The signs were in Chinese, and the guy didn't speak any English.  So I got me a bubble tea by grunting and pointing.  I didn't know what I was ordering.  It looked like berry.  Turned out to be red bean tea.  The communication barrier had struck again.

Oh, and before I forget, this isn't unique to China, but it's the first time I had a glass of celery juice.  I liked it, but Nicole didn't.  She tried to put watermelon juice in it, and yuck, that was pretty bad.

I say yum.  You say?

Also, I always like to try to figure out what unique types of alcohol are available in various parts of the world. In China, the unique stuff I got to try was called Erguotou.  I didn't get to try any there, but I brought a bunch of it home.  After having a glass of it, I plan to use the rest to strip the paint off an old dresser somewhere.

No, the picture isn't upside down.  This is a picture of what the bottle would look like while pouring.

Another alcohol we saw there was Moutai, also Maotai.  Sounds good, but I didn't get any of this, and it doesn't appear that I can get it in the U.S.

I guess I'll just have to go back...

Spitting in China

So on our first tour day in China, the first tourist destination we hit was The Summer Palace.  While we were there, we got to see the Giant Rubber Duck, which was on display in the lake for National Day, October 1.

Our tour guide, Bryan (like Adams) at the Summer Palace in front of the Giant Rubber Duck.

As we left there to go get back on the bus, we were walking down the street when someone nearby stopped, held one finger up to one nostril, and blew a great wad of snot onto the sidewalk.

I gotta tell you, I was kinda surprised.  Someone in our group said, "Farmer's blow!"

That was the first I really saw of spitting in China, but then we saw it everywhere.

And I do mean everywhere.  In every city, and every stop we made, people were hocking up loogies and spitting them to the side no matter where we were.  And once you noticed it, you saw it all the time.

With somewhere north of 20 million people in Beijing, that's a lot of loogies.  There's a constant audible undercurrent of Auuuch-ch-ch!

At Tienanmen Square, there were a number of sidewalk scrapers whose job was to keep the entire public square clean.  They would occasionally stop an stoop down and, using a little metal scraper, meticulously scrape at the ground to clean it.

At first I thought it was gum they were scraping, but it could have been dried loogies.  The thought shudders me.

Eating in China

Probably the biggest question I get about China, maybe after questions about pooping, is what we ate in China.

My answer is bland: Chinese food.  That sentence would have still been true without the colon.

The Meals

As I mentioned before, we were on a tour, wrapped in a little safe cocoon of western company and a tour bus.  Almost every lunch and dinner we ate was scheduled in advance and provided to us by Rewards Travel China.

When you go to a Chinese restaurant in the U.S., it's like every other restaurant.  You pick what you want: chop suey with a side of pork fried rice and an egg roll, and you get it delivered to your table.  It's a little different when you eat in China, although you can find some restaurants that will serve you this way in the states (Mapo restaurant in Naperville is one place I've been that does this).

For every lunch and dinner, we sat down, eight or ten to a table.  Tables were all round, and pre-set with silverware and plates.  In the middle of the table is a large lazy susan.  Often, there was a pot of green tea on the table when we sat down.  Then the waiter comes by and sets a dish of food on the lazy susan.  This could be anything on the menu, really.  Sweet and sour pork?  Breaded fish?  Celery with eggplant in a light glaze?  Mostly what you'd expect from a Chinese menu.

The person it's in front of generally takes a spoonful and lets the susan spin to the next person, who in turn takes a spoonful.

Then a giant vat of white rice gets set down.  Then a bowl of soup.  People generally take a little of each.

Then it gets interesting.

Dish after dish gets placed on the lazy susan, until it is completely filled.  Beef, chicken, pork, fish, veggies, and combinations of them in a dizzying array choke out the available space on the spinning apparatus.  It becomes hard, depending on the number of people at the table, to get to the dish you want, since people are always spinning it left or right to get a little bit more of something.

What's interesting was how much variety there was at every meal, but how much, by the end of the trip, the food all started tasting and smelling the same.  It got to the point where we were tired of the same food and were dying for any kind of food that wasn't Chinese.

This may be because the food was designed for a western audience.  On more than one occasion our tour guides told us that they carefully guarded our tender tummies because they'd had groups that ended up with a long visit to the People's Republic of Diarrhea.  And in a country where many of the toilets are squatters and paper in the potties is not plentiful (more on that some other time), this is not a fun situation.  It's possible that the meals were designed with that in mind.

Could also have been that these were the cheapest meals on the menu, and they were keeping costs down. As I pointed out, the price for the trip didn't even cover the apparent cost of the flight, let alone the hotels and meals.

One interesting tidbit is that these meals never came with any sauces.  With the dishes being tasty, but on average somewhat bland, I got in the habit of ordering soy and some spicy chili garlic paste so that I could spice things up a bit.  And they'd bring out a little dish of each, only about a half ounce, almost as if the stuff was more valuable than gold dust or unicorn farts.

And then the fruit shows up.  Sometimes it's a plate full of oranges, but most of the time it's not-quite-ripe watermelon slices.  That's dessert, and it's refreshing.  Oh, and no fortune cookies anywhere.  Or egg rolls.

By the end of the meal, there are plates everywhere.  Because we're part of a tour group and it's all paid for, that's when the tour guide shows up and we're whisked away.

Of course, that was just the meals we sat down for.  Sure some of them had different twiddles like the time we got to go to a place for great Peking duck, but overall, those were pretty same-samey.

The Wangfujing Snack Street

No, the real variety was in the street food.  In Beijing, you can visit the Wangfujing.  This is a street with major name stores that's been closed to automobile traffic and set up as a giant outdoor mall.  The main street is kind of Times Square-y meets a typical American outdoor mall, but alongside the main shopping area lies some real treats.

Wangfujing Snack Street is an extremely densely populated walkway chock full of street food vendors.  It's probably a quarter mile of vendor after vendor serving different kinds of local snack food. It is so crowded that the claustrophobe in me felt very uncomfortable navigating it.  This was home to some of the most interesting culinary sights in China.

There were produce shops down this alley, some with fruits of all kinds piled high.  The cantaloupes in China are oddly elongated, so I had to snap a picture:

I've got a cantaloupe.  Go long!

A lot of the food in Beijing comes on sticks.  At least the snack food in the market.  Imagine a six to ten foot wide table set with large serving pans of sticks of raw meat.  Now imagine these placed one right after another for a quarter mile, each vendor serving something different.  When you order these foods, they are cooked immediately in a vat of hot oil nearby. The prevalence of gutter oil may be the reason that our tour guides sternly warned us not to eat any street food.

And some of it is food you wouldn't want to eat anyway.  Never mind that the smell of this narrow snack street was a pure assault on the senses, but this street is home to food that even the Chinese only eat on a dare.  Some of these foods include sheep's penis, larvae, starfish, centipedes, spiders, seahorses and live scorpions. On a stick.

Yes, starfish.  PATRICK!

The seahorses weren't moving, but the scorpions wiggled and wriggled, very much alive

On the north end of the Wangfujing is what's called the Night Market.  It's a bit more roomy than the Snack Street, though they have largely the same things.  I had planned to try to eat something at the night market, but the reviews of the taste (scorpions taste like egg shell; crunchy but not much else) and the warnings of our guides kept me from doing it.

There was only one bit of street food that I did eat.  When we visited the Bird's Nest and the Water Cube from the Beijing 2008 Olympics, there was a street vendor that had these sticks with nine little candied balls on them.  I had no idea what they were, and the people couldn't describe them to me, but I'd seen them everywhere, and I was feeling adventurous.

I bought the stick and bit into one of the candied balls, and inside was a little piece of fruit.  It was as big around as a quarter, and it had three little seeds in it.  The candy on the outside was crunchy, though it looked like a little candied apple.  Deciding it was OK, I shared it around and brought the empty stick on the bus with me.

I showed the tour guide and asked what I just ate.  The look of concern that came over him took me by surprise.  He shook his head and said, "No, no," and patted my belly.  He said that I shouldn't eat any street food or I will get sick.  He also said that the fruits were called Haw.  In looking them up, I found that I had eaten BingTanghulu, a popular street treat in China.  And yes, they were hawthorn fruit.

So that's my experience eating in China. There is one more tidbit and some photos to share with regards to eating, but the experience in the Market in Suzhou overlaps with the shopping details I'll share, so I'll save that tale for another day.