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

-----

See also GettingAcrossTheDomain