Versatility and reusability. Those are among the few words in the English language that have a positive vibe, pretty much no matter how you use them. Managers and coaches find versatile athletes to be invaluable. No one ever seems to argue against recycling. Technology professionals adore plug and play. Green is in, waste is out. How, one may ask, could versatility or reusability possibly be considered a bad thing?
Well, in the world of legal applications, and, more broadly, the applications development discipline in general, there can be a trade-off when striving to develop common code and modules. Usually this involves balancing time-to-market, versus the development of a more powerful product, for no matter how skilled a development group you have, something more complex requires more time and effort to complete.
So what are the key factors to consider and what are the proper choices?
In my opinion, turning a specific user requirement into an attribute an entire user base can take advantage of is always preferred. If your programming expertise is required to construct a unique feature, report, interface or module, why not do so in a manner that allows everyone to benefit from the fruits of your labor?
While there are sometimes legitimate reasons to take either path, at other times some nimble Henry Kissinger-like negotiating skills are needed to move the needle toward the direction of reusability. Here are some of the issues and concerns a legal technology professional must navigate to deploy new elements of system functionality across the enterprise.
Many attorneys and legal professionals have parochial concerns. This is not a criticism. Solid professionals are trying to do their jobs. Part of that is providing outstanding client service to those they represent and support.
Folks ask for new features to meet a specific business requirement. They may need to track some new types of data, have to crank out a specially formatted report, want a screen to appear in a certain way or have unique requirements for securing access to data.
Most of the time, they are asking for something in reaction to a request from a boss or client who probably is not as benevolent or patient as, say, a preschool teacher, or Mother Teresa. There is a reason things like the drive-through, Twitter and texting have taken over our lives. People want things done, and they want them done fast! Anything that slows down a need can be perceived as a contributory factor to woeful customer service. Even if a legal technologist's desire to create a reusable capability is admirable and visionary, it can be a daunting challenge to get that sort of message across.
Why does it take longer to build versatile features anyway? Good question. Sometimes it is hard to understand why building a feature for mass deployment takes more time than a single system enhancement. Part of the reason is that it usually requires more brain power to create a design that intertwines a new report, interface or improved security capability into the "guts" or core of a system than it does to modify a few procedures in one client system. A second reason is the level of testing that is required, for a development team must execute more complex system integration tests for an integrated code improvement than for a one-off improvement.
Perhaps a third reason is the time required to actually promote the new or updated code, table changes, etc., to all of your production systems — a strategy which is 100 percent necessary to ensure each system is using the same common application code base. (BTW, a failure to follow this simple practice could easily elevate you into the top one percent of all NSAID customers in the world, as you struggle to support a perplexing plethora of combinations of system code, a place you surely do not want to be.)
The bottom line is there is no disputing that building versatile and reusable system functionality requires more time and effort than simply bolting on a few lines of code to an individual system.
So how do I make this happen? It takes longer to complete versatile features. That makes clients less satisfied. "Longer" or "more time" doesn't sound like something those kids in the AT&T Wireless commercials would like, does it? Well, there are some ways to get to where a legal technology professional wants to be. One is just sheer logic. There is a class of people — a fairly small phylum, I am afraid, but one that does exist — who will listen to a logical recommendation about taking more time on a finite project and are willing to step back from their needs to do what is best for the organization. That's an easy group to deal with (and my favorite!).
Others are not so easy. The "I need it done now" crowd may not understand — or care about — that line of reasoning. Some client conversations are so bothersome it makes dealing with problematic folks like notorious sports agent Scott Boras seem pleasurable! But that's not the end of the line for the legal technology professional, it simply means you need to dig deeper into your bag of tricks to woo your valued clients into seeing things your way.
Use the tools. Cost is always a great tool in the arsenal. You can offer to complete a project at a lower cost if they do it your way. Money talks, and it is often a great motivator. Offering a few added benefits/features in exchange for more time to complete the project in a versatile manner can be an effective strategy.
A final tactic can be (not that you want to go to the well with this once too often) the fairly frank approach where you inform a client that because her or his project is not time-sensitive or business-critical you are going forward with developing shareable functions, as this is in the best interest of the company.
These approaches, somewhat obviously, are presented in a certain order of preference. Just as a pitching coach might advise a pitcher, even one with a 100-mph heater like Aroldis Chapman, not to challenge the likes of a Mike Trout, Miguel Cabrera or Robinson Cano with a fastball down the middle too many times, but instead to tempt the batter with a curve ball, so can you entice your users to swing at your pitch, with some attractive incentives.
That's much better than trying to rule with an iron hand. I don't know of any graduate school of management named after the likes of Joseph Stalin or Nicolae Ceausescu. No need to manage like a bully unless it is absolutely necessary.
Assess each situation. It should also be noted that there are times when business urgencies and needs clearly trump one's desire to build out useful, far-reaching features.
The astute legal technology manager — like an instinctive NFL quarterback — will be able to ask the right questions and have the proper perspective to know when it is right to scramble for the first down (e.g., meet the immediate client need) versus stay in the pocket looking for a receiver to take it to the house (e.g., build the system-wide feature).
But at the same time, if you truly believe, as I do, that a legal technology organization, and in fact any development organization, should take advantage whenever possible of opportunities to build features with global utility to an entire customer base, it is perhaps even more important to stick to your guns rather than acquiesce to the short-term perspective of a demanding customer.
This is not a simple skill to master. Making the right call, and working with a user base to try and move them in the direction you believe to be best, is easier said than done.
Each situation presents a different set of circumstances, and it takes judgment and experience to do what is best. But in the end, striking the right balance — between helping clients meet immediate needs and building reusable system components — is a skill that separates the wheat from the chaff in the legal technical applications development field. •