Coming Up To Speed

Throughout our careers, we're often faced with new situations where we have to "come up to speed" quickly. It may be a new project, or we may have taken on a new role (or both), or we may have switched technologies, moved to another company within an industry, or even switched industries. Whatever. The immediate result is that we find ourselves outside of some of our old spheres of competency, and have to rapidly acquire competencies in the new situation.

Over the years, I've learned or developed several strategies for rapid adaptation, a few of which are general enough that I'll try to cast them as patterns.

Use SystemsThinking to organize your understanding of the problem domain (and/or the local political domain).
Work quickly to KnowYourCustomer.
To organize your understanding, pretend that you'll soon have to TrainYourReplacement.
If you're having trouble understanding the behavior of the people around you, play WhatsThePayoff.
Play VisitorFromMars

A book that I've found helpful in dealing with the discomfort of feeling temporarily inadequate in a new situation is George Leonard's Mastery. Leonard talks about plateaus in performance, and how climbing to the next level usually involves crossing a ravine, where we have to unlearn some old habits and skills before learning new ones.

-- DaveSmith (3/8/96)

In general, I have attacked the ComingUpToSpeed problem as follows:

Learn the existing system (manual, automated or both) by reviewing any available documentation (since people are usually too busy to help).
Meet the users and observe how they use the system.
Ask the users about what works and what doesn't.

At this point (about 2 to 4 weeks) my mental model of the world begins to resemble the model of the people who have been working with the system.

I also find that being the VisitorFromMars helps because I don't have the same preconceived notions about the system (i.e we've always done it this way) that everyone else has. (Instead, I have my preconceived notions about what the system should have -- without knowing the system at all!! :) )

-- ShalomReich

In addition to playing the VisitorFromMars, I try and see what the system reminds me of. By this, I mean that I look for Patterns. Often what has been built (or is being built) will remind me of a previous system. Or, sometimes I can get an idea of the nature of the problem being solved and generate fresh ideas which can lead to a more general solution.

For example:

I was once asked to develop data field validation routines for dozens of very specialized database forms. They wanted to prevent invalid data from being submitted from a client machine to the server (to reduce network traffic and turn-around time). The team spent days trying to get me up to speed on the what the data was being used for and the specific calculations that would need to be performed to validate the data.

Given the time constraint, I offered a solution that generalized the problem. That is, I suggested developing a scripting language that could be tailored to each type of data field validation requirement. This language allowed the team experts to quickly write data validation routines that also proved flexible (it was easy to change the routines upon customer requests). (I owe the insight of my solution to the book ThinkingForth...)

A VisitorFromMars can often see how specific problems really aren't that specific.

--ToddCoram

c.f. GettingUpToSpeed, which comes at this from a slightly different angle.

How have you handled ComingUpToSpeed?

I've been thinking about this in the area of software development (I working in a unfamilar language in an unfamiliar style). Here are some ideas. Are these parts of larger patterns?

If you have documentation only, create test executable that perform small functions (a few api or library calls with life-support). Keep these around - these greatly speed up debugging the larger system later.

If you are blessed with existing, working code, copy it, document it, and tear it into pieces that demonstrate distinct functionality (this shows reading from/writing to a database, this show creating a UI, etc).

Or take the code, strip out what you don't need, and use it for a template for what you are creating.

And while ComingUpToSpeed, alive but Frankensteinian is often better than beautiful but dead.

--WayneCarson

ComingUpToSpeed, PatternMining, and several other things are forms of Analysis.. figuring things out. Related stategies can be found in GuerrillaDomainAnalysis and ScenarioPlanning. -- MichaelFeathers