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
AT&T had dreams of becoming a power in the computer business. A line department was developing a line of computers called the 3B. The first products in the line would be the 3B2, roughly the size of a PC, and the minicomputer-sized 3B5. They had a proprietary AT&T microprocessor chip that ran UNIX, which the PC could not do at the time. They were hoping to "sell boxes" as Earl put it ("boxes" being computer hardware), and Earl and most of us knew by then that specs didn't sell computers, applications sold computers. Unlike techies like us, real businesses bought computers to do specific business functions, not just because they wanted a computer. The folks building the 3B2 were not working with that insight, or perhaps they were hoping that UNIX would be the software that would sell the computer.

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:
  1. 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.
  2. 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.
  3. 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.
Timko did the usual thing an upper manager would do. Since Earl Jones had identified the problem, he got the responsibility to solve it. I was a supervisor under Earl, and my group was assigned to "git 'er done!" My team for the first wave of contracts consisted of John Dawson, George Wyatt, Harvey Cohen, and others to whom I apologize for forgetting them now, 35 years later. (Please contact me and remind me, if you are willing to admit your involvement in this activity.) You could have written everything we knew about software law on a post-it note and had room left over. And we had only three months to conclude favorable contracts with software companies for at least four applications. What to do?

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.


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