Becoming a Lawyer
Dave Tutelman --
May 16, 2018
No, I was never really
a lawyer. I just played one on TV. Well, truth be told, I played one in
real
life for several months. In fact, the whole group of engineers I
supervised got to play lawyer for a few months in 1983. We were
actually
representing one of the biggest corporations in the world as the
"attorneys" negotiating some fairly complex contracts with other
corporations.
I worked for Bell Labs, the R&D arm of AT&T, then one
of the biggest companies in the world. I was in a staff department. At
Bell Labs, the distinction between "line" and "staff" is that a line
department develops a product to be manufactured. As a staff department
we
were supposed to provide a service to the line departments. In our
case, that service was product architecture advice --
unfortunately, a service that none of them seemed to want. We had to
prove our usefulness or we would be be broken up at best or laid off
at worst. My particular department, under Earl Jones, was a collection
of pure techies, each an expert in computer technology, software
architecture, or human
factors. We just wanted to invent and build neat futuristic stuff, and
we had worked on enough of it to be really good at it. Earl, our
department head, was himself a techie by nature, but more ambitious
than most of us to
rise up the company ladder. So the picture is: Earl
would love to be visibly useful even if it was not his preferred
technical job, and the rest of us wanted to have fun building the
software
or gadgets of the future.
In early 1983, we got a chance to be useful!
3B2 and 3B5 computers
Anyway, our management told us to be
useful by evaluating what the 3B had to be or do -- or run -- in order
to be a force in the market. We (specifically Earl) immediately said
that it had to
come with a bunch of applications that actually did business functions.
We came up with a list of such functions; our check boxes included word
processing, spreadsheet, database system, and a suite of business apps
(like accounting, inventory, etc). Perhaps other stuff as well,
depending on the company and the industry, but this was the generic
list. One point we noted: the 3B2
would be competing with the PC, and many of our potential customers
were already familiar with a bunch of popular PC applications in each
of those categories. If we wanted to sell "boxes", the boxes needed to
run
applications that worked exactly the way the customers knew how to do
it on the PC. If they had to retrain to learn our applications, we
would lose the sale. (So no, it wouldn't work to claim troff
is a word processor.)
Our executive director, two levels above
Earl, was Joe Timko. Joe was a guy known for getting things done when
he was in line departments, and was uncomfortable in the more
vaguely-defined staff role. He saw an opportunity here for a real job
with measurable output, a role he understood and relished even if it
was not product development. He jumped at it. His idea: we were going
to get at least one popular application in each of our
check boxes to be available on the 3B computer. It was a chance for our
staff division to be heroes and
rescue a line organization.
"...Be available on the 3B computer." That meant negotiating contracts
with software companies to port their popular
PC MSDOS applications to 3B UNIX. But contract
negotiations required lawyers. That threw several monkey wrenches into
the works:
- AT&T had no experience in the software
business. We were very big in software technology, but
"business" implies you sell the software.
We developed lots of software in research, which was not sold but often
shared with, say, universities. We developed lots of very sophisticated
software in line organizations to enable or improve our own work of running the nation's phone system. This
software ran telephone switching systems, tracked problems in the long
distance network, assisted operators in placing phone calls -- but none
of it was sold outside our own company business. So none of
AT&T's
corporate lawyers knew a thing about software law.
- You would think if not AT&T's lawyers, perhaps Bell Labs' lawyers would
understand enough about software law to do the job. But they were all patent attorneys, and had
little experience with any kind of contract law, much less software
contract law.
- As with most big corporations, AT&T's and
Bell Labs' legal departments were very conservative and careful. Slow and steady, they
took
forever to get anything done. The computer business moves fast, and the
lack of software for the 3B computers had to be solved quickly or the
3B computers would be obsolete by the time there were applications
available for them. So there
was no chance that any AT&T legal team would negotiate and
approve
contracts in the time frame needed. (Joe Timko had concluded that we
needed to have signed contracts and work under way at the contracted companies within three months.
Inconceivable that AT&T lawyers could work in that sort of time
frame.)
Timko had a reputation for ruthlessness in getting the
job done. A lot of people at Bell Labs were afraid of him, including
most of the people who worked for him. But
it also included people in high places. Joe pulled enough strings and
intimidated enough people to get a heretofore unheard-of agreement from
the VP of legal services. Timko's
people would negotiate the contracts,
in complete detail. (Hey, a chance to be useful!) Timko himself would
be the signing officer on behalf of AT&T. When Timko's
team
felt we had a contract agreed to, AT&T's lawyers (and it
devolved
to Bell Labs' lawyers) had one week to review the contract and identify
things needing change, and they would be available if needed to help
negotiate the change. Unheard
of!
|
Earl Jones in retirement, 30 years later.
No tie, but otherwise looking much the same.
Earl's solution was a stroke of genius! He obtained and read (or at
least skimmed) every book around on software law. In 1983
there wasn't as much around as today, but still enough books. He picked
the one that seemed the best and
most applicable to our
problem. Then he....
No,
he didn't get copies for each of us and tell
us to read them. At Bell Labs, that would have been obvious, not
genius. Instead, he
hired the
author, Paul Hoffman, to come in for a week in early April, and give
our team an intensive course in software law. That included my whole
group, which was more than we needed to do the job. Earl realized that,
if the
project
succeeded, we would be asked to do more of it, so everybody should be
trained. And the course was not just book work and lecture. As part of
the course,
we
came up with a standard form contract that was as favorable as possible
to our side. Hoffman helped us write it, and vetted it with us.
We also retained our mentor to
accompany us on our first negotiating visit to a software company. The
trip was made by Hoffman, Earl, and everybody who expected to be in the
first wave of negotiations; that was me and 4-5 members of my group. At
the time, the market leader in business software for small computers
was
Peachtree,
based in Atlanta. So that was where we started our quest. They had an
impressive headquarters, befitting their market position. We may have
been AT&T, but we were the newcomers in this business and both
companies knew it.
The meeting took a full day. At the end of
the day, it was clear there would be no deal. They wanted a lot more
from AT&T than we were willing to offer. Still, the trip was a
raving success. We learned as much from that one day as from the whole
week of seminars. The meeting would take a break every hour or so, and
each team would caucus. During the caucuses, Hoffman explained to us everything that had
happened. A lot happened that might not have been obvious to us during the meeting.
Why they had proposed certain things, what they would get out of it and
what we would get or lose from it. What we should do about such
proposals. Things we might want to add to our standard contract to head
off such issues in future negotiations. |
 As
for those future negotiations, they were the next thing that happened.
- Word
processing and Spreadsheet:
WordPerfect was the market leader for word processing on a PC. VisiCalc
was the market leader in spreadsheet, with Lotus 1-2-3 about to
overtake it. But Microsoft products
were not too far behind in both categories: Word and MultiPlan. (Excel
didn't come on the scene until later.) VisiCalc and Lotus were
not interested
in working with us. WordPerfect might have been, but they were
preempted by an interesting fact. Word and MultiPlan, both from
Microsoft, had a very similar software structure and used the same
development tools; porting both would take far less than twice the
effort of porting just one. So we went with Microsoft for both
products. Microsoft was a very hard-nosed negotiator, but we were
becoming fairly tough ourselves, so a mutually acceptable agreement was
reached.
- Business
suite:
Nobody was close to Peachtree in market share; we were not going to win
on that count. But there was a small-but-growing and very competent
company called American Business Systems that really wanted
to do business with us. They were our eventual choice of partner for
the business suite.
- Database
management system: The DBMS leader for the PC was
Ashton-Tate's dBASE II. They wanted to do business with us, so the
negotiations went rather smoothly.
Back
at the Labs, John Dawson created some very nifty tools to manage our
multiple contracts. He observed that our contract was like the source
code for software. Remember, our team may have
been playing
at being lawyers, but we were
accomplished developers. John adapted our source code control and
software "build" tools to store and build our contracts. Each
paragraph of the contract was treated as a software module. We had a standard set
of modules for our standard contract, and a separate "branch" for each
deal we were negotiating. Obvious differences from branch to branch
were the name of the selling company (e.g. 'Microsoft'), the name of
the software (e.g. 'MultiPlan'), the date of the contract, and the
amount and terms of payment. But, as negotiations went on, other parts
of the contract departed from the script, and differently for
each deal we were negotiating.
With John's software, any
departure from the standard contract in a branch meant a file was
created with the new version of just that paragraph and identified with
the
branch. If we wanted a printable copy of the contract for Ashton-Tate,
we would ask for the Ashton-Tate branch. The software would go through
the branch, processing files. If there was a file in the branch, it
used that; otherwise it used the one in the standard branch. So we
could generate the current version of the contract for any of our
deals, even though the deals might be quite different. And, since the
paragraphs were files under source code control, we could generate any
previous version of the contract, or see when we made
a particular change.
We had suddenly gotten
very good at both the content and the mechanics of software contracts.
It became clear over time that we were
much better at it than the AT&T legal staff. And we were
dealing
with it as lawyers would, albeit lawyers who were also software
subject-matter experts. Hoffman had taught us the style that
contract
lawyers have to be very good at: think of every "what if" and make sure
the contract covers it. BTW, programmers are very good at that,
too; think of every "what if" and make sure the program handles
it. It
wasn't a
hard approach for us to learn. We just had to learn the "what
ifs" for contracts, and Hoffman taught us that.
By the middle of June, Earl and I
and our director Steve Bauman (who appeared in the organization chart
between Earl and Timko) went on a whirlwind tour to finalize our
agreements
with Ashton-Tate (Los Angeles), Microsoft (Seattle), and ABS (Boston).
At each stop, we were met by the member of the team that was working
the
details with that company. We lived on airplanes or in airports for
three days, then we had agreement on a contract with each of them. Now we
had a week to work with AT&T's legal eagles and get the
contracts
signed. Our lawyers had remarkably few objections, and most were
quickly disposed of. That week, I found myself spending several hours
on
conference calls, with our lawyer on one line and their lawyer on the
other. The lawyers argued; I proposed wording changes that settled the
arguments. Every dispute was resolved that way. I was pretty proud of that, doing better contract
negotiation than either company's lawyer.
Before the end of
June, we had contracts signed with all three initial suppliers. When
Timko had gotten the go-ahead back in March, nobody believed it could
be done.
Even after the fact, it was hard for most people to believe it had been
done. But it had. |
Epilogue
The last of the contracts was signed on a Friday morning at the end of
June. That afternoon right after lunch, I walked into Earl's office and
asked if I could transfer to a department that did real technical work.
Earl grinned and said, "David, I'm surprised it took you so long to
ask." I felt that I had earned my "exit pass" from this amorphous staff
organization, and Earl agreed. I spent a couple of weeks interviewing
in other Bell Labs departments, and a month later I was in charge of a
software development group.
The 3B line of computers was not a commercial success, in spite of our
efforts. Of course, I was in another part of Bell Labs by then, so I am
only relating hearsay from my former co-workers. They negotiated
the second wave of software for the 3B, and there were more and
different people on the job. Thanks to Earl's foresight, they had also
been through Hoffman's crash course back in April.
Sadly, the applications were not ready by the dates the contracts
called for. Once the contracts were signed, they were turned over to
the organizations that typically managed supply contracts for
AT&T. Those departments, of course, knew little or nothing
about software. They also tended to have a pretty cozy relationship
with suppliers. It didn't take the suppliers much to come up with an
excuse for slipping a date or dropping a requirement, and
AT&T's people could not
tell truth from BS. So they allowed all sorts of changes. I
don't know how much of the software was ever even delivered.
It is possible, even likely, that the 3B would not have been a success
anyway. But it didn't help that the contract administrators chose not
to lean on the terms of the contract and the penalties we so carefully
built into them.
In 1997, fourteen years later, I found myself as a systems engineer for
AT&T's email service. I was not doing
development; AT&T was no longer committed to that activity.
(I'll have more to say about that in another article at another time.)
Instead, we had contracted a software company to develop our email
server
software. My job was to write the technical requirements for the server
and
convince the development company to meet those requirements.
I suppose I should not have been surprised to find I had no
leverage. The development contract was already signed. All I could do was suggest
changes in the technical portion of the Terms and Conditions. If the development company
didn't like what I proposed, it would not get into the contract, because that was already written and signed.
I was interested to see whether I had any power at all based
on the contract, so I asked to see the contract itself. It took a
while; nobody seemed to know where to find a copy of a real contract.
But eventually they got the document to me. I started reading it. (That
in itself would have shocked most of the people involved -- that an
engineer could read lawyerspeak.) A few paragraphs in, I was smiling
broadly. I
skimmed the rest, laughing out loud. AT&T's 1997 software
procurement contract was the one we wrote in 1983. I didn't notice a
single place where a
word was changed.
In fourteen years of experience, in a world now dominated by software,
AT&T's lawyers couldn't find a single thing to improve about
the contract. I'd like to think that was due to the great job we did
when we wrote it. I wish I could believe that.
Last changed - 5/20/18
|
