Another way to introduce Lisp, to a job where it's not used, is to always
write a prototype in Lisp, of each program you're going to write in
whatever language is used. Always demonstrate the prototype and say it's
for clarification of the requirements. The prototype gives people an
opportunity to think about whether this is really what they want. Then,
when all agree, proceed to write it in the orthodox programming language.
After doing that for a while, start writing prototypes of bigger
programs, being developed by groups of programmers. Those prototypes
will help those programmers argue with each other about how their program
should work, etc.
If you keep that up, eventually your boss will start to notice that you
actually have each program working as a prototype early in the design
phase, while groups of programmers are still hashing out the details
before they start coding. Then one day your boss will ask you, "why are
your prototypes just prototypes? What would happen if we just used those
as the actual programs?"
A key point in doing it this way is that it's not a language war. You
never even mention Lisp except when someone asks, and you make light of
it, as not being the important issue. The important issue is that a
prototype helps clarify the requirements, by giving the designers real
experience with what they're designing.
But the prototype has to be working before anyone even finds out you're
spending any time at all on a prototype. Otherwise they would just tell
you to stop wasting time.