An interesting string started today on the
ILTA listserves regarding the generational rift within IT Departments as reported in a recent
CIO.com article. This falls
in line with what we're seeing in all corporations,
especially in law firms.
This also has an important impact on how technology is designed and how we go about training lawyers on technology.
A great post by Doug Cornelius which discusses/defines the types of searches a lawyer conducts when looking for documents got me (abstractly) thinking more about this issue.
As we get more focused on the needs of lawyers in our design of systems, the knee jerk reaction is often to build to the needs of the Partners and rightfully so. They are the ones that ultimately employ us and bring money in the door. On the flip side, there's the possibility that you are building systems based on the wrong user group, if for nothing else, because many partners won't bother using the technology - regardless of how great and user friendly it is. You often hear the term "building to the lowest common
denominator", which is a nice way of saying that we'll build something so even our least tech-savvy lawyer can use it. But, is that the right approach? Will your least tech-savvy lawyer even bother trying out what ever system you have built and if so, what percentage of your lawyer population actually falls in that category? Furthermore, how much longer will that crop of lawyers be at the firm? Conversely, tailoring your systems to the needs of young, tech-savvy, Associates might also be a
CLM (Career Limiting Move).
Going back to Doug's post and thinking about some of the
comments by my good friend Beau
Mersereau, perhaps you do both and build systems around "where they live". When you build document retrieval systems, you focus on the needs of the Associates, as they are the ones most likely to use a system like that. Partner's aren't usually taking a first cut at a
MSJ (motion for summary judgment), or being asked to dig up a buyer-friendly asset purchase
agreement, it's the Associates. On the flip side, when looking at implementing a portal, or Outlook integration, Partners have a greater need to aggregate information from various locations than Associates do.
Then you start looking at how we traditionally train lawyers. I'm still mystified at all the
rollouts that rely on classroom training for lawyers. I guess we're all still stuck in the late 90's, when we could get lawyers to show up for classroom training for the WP to Word/DOS to Windows training. Ah, the days of watching people play
Solitaire for hours on end while they "learned" to use a mouse.. That went out around the same time Pearl Jam stopped being popular, but we (much like Eddie
Vedder) are holding hope that there are glory days still ahead of us.
Partners don't have the time (or desire) to spend an hour learning the latest and greatest tool being rolled out and the misnomer that food will bring them in is also a joke. These guys make plenty of money, they can afford to pay for their own
Quiznos sandwich. Associates are equally pressed for time and many of them feel that they can usually pick up whatever new software you put in front of them within minutes. Unlike their senior counterparts, they were practically born with a keyboard in their hand and dismiss the notion that they need training on most anything.
This requires a shift in the way you deliver training to lawyers. This isn't to say that you stop all forms of classroom training, it's still a valuable tool - especially for staff. But, you can't rely on it as your only means of training the lawyers. Take the 1hr session and boil it down to what you can deliver in 10-15 minutes, usually the most
relevant 5-10 features/functions that are critical for the lawyers to know. Walk the floors and make personal visits to every attorney armed with "Do you have 10 minutes for me to show you a new tool that might make your day a little easier?" Now, you're doing on their terms, in the comfort of their office and doing it in a
timeframe that they'll accept. While this approach requires more people, time and effort, it's a sure fire way to optimize the acceptance and adoption of new tools.
