Life Lessons Learned Managing Technology Projects

The PC Revolution

In the early years of my career, after I got my degree as a computer programmer, I bought my first computer – an Apple II Plus with a whopping 48K of memory and a couple of 5.25” floppy disk drives. I even added a Zilog Z-80 card so I could do CP/M and Business Basic. The computer store I bought it from asked me to come join them because they were swamped by so many small business owners who bought into the promise that these new micro-computers could do everything for a couple thousand dollars that the mini computers would do for $50,000.

It was a sweet gig. I was still single. I made a nice salary and commission as I managed the computer store and sold computers during the day. I then worked evenings and weekends writing programs for insurance brokers and small doctor’s offices who wanted a way to automate the typing of these long forms required for insurance claims. Remember Daisy-Wheel printers? I made them sing and the folks who used to have to type those forms were just loving it. I started my own consulting business.

A New Skill in High Demand

I do not know how she found me, but I was approached for the first time by a recruiter who wooed me to interview with an established mini-computer software development house in North Hollywood. Delphi Systems Inc. by name, not at all related to Delphi Technologies (Automotive). You will not find anything about them anywhere on the Internet today. The owners merged and sold out many, many years ago. It was a sweet offer; double the salary I was making when I managed the computer store. How could I not accept?

I did not mind the drive. I was now going on sales calls as the technical consultant to the Vice President of the brand-new PC division that was going to deliver technology on PCs for half the price of what you would pay for the same thing on a Mini-Computer. In those days I developed code in an early database manager you may have heard of from a short-lived, high-flying company by the name of Ashton-Tate. The product was dBase II, my bread and butter.

Working with Recruiters

So, my first impression of working with a recruiter was incredibly favorable. She got me a great deal. As far as I know, she represented me properly to the company. She explained to them how I had started my own consulting company and would be giving that up, along with the day job at the computer store. She did not promise that Tim could do anything other than what Tim was doing – writing single-user code in dBASE II and delivering systems in six weeks.

The company was used to working with recruiters because it was hard to find good programmers for the DEC PDP/11 who were willing to leave larger banking, insurance, and oil & gas industries to come work for this small systems house (about 80 employees).  However, this was the first time they had used her and paid the fifteen percent fee for the new PC division. Because of that fee, they held back on the base salary they could have offered. The deal included a raise at the end of one year, obviously depending on performance.

Living the Good Life

For a year, my boss and I made tons of money for the company. He would take me to all the smaller customers of Delphi Systems, promise them a custom system for less than half the going rate charged by the other side of the house, and make a killing in profit for the company – billing my time and services at rates I would never dream of charging while I was out on my own. And you know what? It worked. For a year.

We sold system after system, I spent six to eight weeks developing the custom code, delivered the system and trained the customer. Everyone was ecstatic at how well it was working out. Life was wonderful. I felt so confident I even got married and started a family. Everything was happy until the boss decided we should step up to larger multi-user systems and start writing code in a more powerful language, that promised to work just like dBase II, but would take half the time to develop, or so he had read and heard from others at the trade shows we attended.

Similar Systems are not the Same

“You can do it, Tim. They say FMS-80 is just like dBase, only better. You’ll be able to write code faster and better.”

“I don’t know, Frank. I’ll need some time to look at the manual, write some test code first. It will take time to figure it out.”

“Come on. I’ve got a call already lined up this morning with a tropical fish wholesaler who needs a multi-user inventory system.”

A Promise to Deliver the Moon

And off we went. Frank made the same glowing promises, only this was a multi-user system, a BIG difference. The customer bought in, wrote a check on the spot for half the $50,000 to get a complete inventory control system, custom-written just for the way they do business, that could be used by the sales order folks on the desks up front as well as the shipping department in the back. And Tim would have it ready in six weeks, just like he always did. What could go wrong?

“What do you mean, we need to send you to a week’s training class? Can’t you pick it up on your own? Come on Tim, you’re smart. You can do it.”

“No Frank. This is Oasis, not CP/M. It works completely different. It has file and record locking, stuff you don’t need to worry about in a single-user system.”

Time to Learn New Technology

So, Frank went to the president, explained why they needed to pay the $1,000 training fee plus travel and lodging, then sent me to Phase One Systems in Oakland for a week. He grumbled about it and let me know what a risk he was taking and how difficult it was for him to explain this “huge expense” to the CEO.  When I got back, I studied and mastered FMS-80 (they had no training available, and a barely readable manual), a multi-user competitor to dBASE II. This was no walk in the park.

Sure, a lot of it was familiar and I understood the concepts, but I needed time to develop my own subroutines, test them, and get the coding flow down like I had with dBase. It took time. Six weeks to be exact. All this time Frank thought I was developing the multi-user system he had promised to the tropical fish wholesaler and that it would be ready to deliver at the end of the six weeks like he had promised. Never once did he come to my desk and ask how it was going. In fact, he got married again and then took a long, long vacation.

One-Year Anniversary on the New Job

Well, it just so happened my one-year anniversary with the company coincided with the end of the six-week period that Frank had promised delivery of our first multi-user system to the customer. I was getting the hang of the new environment and beginning to feel confident that I could crank out the new inventory control system. And yes, it would probably take about half the time. I was fairly confident I could deliver in three or four weeks.

I cheerfully came in to work on the morning of my one-year anniversary, popped my head into Frank’s office to say hello and asked if we could meet a little later that day. He had some meetings in the morning, so we scheduled for about 1:30 that afternoon. I went to my desk to work on the project. At 1:30, I sat down in Frank’s plush office, expecting a happy conversation about the good times we had over the past year, how many systems we had delivered on time and that I would now finally be able to really afford the house I had recently bought.

“What do you mean it’s not ready?” Frank was obviously not happy. In fact, he was clearly shocked.

“It will be, Frank. Like I said, I just got started this morning. Give it a few weeks and it will be ready.”

“We don’t have a few weeks. We were supposed to deliver it today. What have you been doing?”

Delivering on a Promise

You can imagine the rest of the story. Frank ripped me up one side and down the other. There would be no raise. In fact, I would be lucky to keep my job, according to him. He said we would probably be sued by the customer for breach of contract. He bemoaned how in the world he was going to be able to explain this to the owners. In all his career, this was the first time HE had not been able to deliver a project in time. He made sure to express how bad I had made him look, that it was all my fault and that it might cost him his job.

There was obviously something going on here that went way beyond the simple delay of a project, due to the change in scope (single to multi-user). He made it clear he thought I was a terrible communicator, that he had no idea the project would not be delivered on time and that there was no reason why it should have taken me so long to learn the new language since he had been told and KNEW it was so similar to the old one which I had been developing in for years.

Early Technology Didn’t Always Deliver

The story has a happy ending, at least for me. I was indeed able to deliver the system in just a few weeks. Yes, Frank got fired, but it had nothing to do with the project delay. He had been making promises to management of building a huge new PC division that would make more money than they could ever hope for compared to the “expensive” mini-computer business. I got a new boss, a much more reasonable, easy-going, laid back former airline captain who was a great listener, made sure we met regularly and did not promise the moon to the owners.

We delivered many more systems together, although not many were multi-user since the architecture was not quite mature enough to handle the complexity with the ease of mainframe and mini-computer systems of the day that relied on polling of terminals and CPU time-slicing. I was even given two interns to train and helped them get into the business, something I really enjoyed. Frank was a visionary, but just a little bit ahead of his time. None of us foresaw the IBM PC that came out the next year and changed everything. But the magic of that year was over. I moved on but left with a good track record.

Bottom Line: Lessons Learned

Why did I go to all the trouble of sharing this story? Besides making me feel really old as I reminisced about the very early days of my career, I was reminded that I was blessed to participate as a pioneer in the PC revolution. I don’t write code anymore, I manage networks. I wanted to share a couple lessons learned that I still find applicable and useful today in my everyday life. The first is of the importance of communication. After my dressing-down by Frank that day, I realized he was right. I had failed to clearly communicate where I was on the project.

I’ve never let that happen again. I do a lot of tech projects and learned from this early experience how important it is to keep my boss informed of where I am on the delivery process, even if he or she doesn’t really understand the technology involved. Sometimes it’s tough. Bosses can ask hard questions because they don’t recognize all the implications of the steps involved, no matter how clearly you may think you have spelled them out. It still happens to me today. I think I’ve spelled out all the steps and the boss still calls me to explain why we have to do this or that.

Explaining Technology to Management

It’s hard to not get frustrated. I have an image in my mind of how something will work, but know it will become clearer once we get this first step completed. The boss doesn’t have that image. He’s never done this before, and isn’t at all clear on why this first step, which happens to be the most expensive, is so important. The requisition for the project includes labor from an outside technology company. The boss calls and says he has questions.

“Can’t you do that yourself? You’re an experienced engineer. Why do you have to hire someone else to do it?”

Sigh.

“When you take you car in for a tune-up and the mechanic let’s you know your transmission needs work, you then take your car to a transmission specialist, right?”

“No I usually just buy a new car.”

“Okay, let’s say you go to the dentist to get a crown and she tells you your cracked tooth can’t be saved and is going to have to come out.”

“What’s this got to do with this project?”

“You have to go to a specialist – an oral surgeon.

“And …?”

“Just because I’m an engineer, that doesn’t mean I know all the technology required for this project. We need to bring in someone who specializes in this sort of thing. It should only take them x number of hours because they’ve done it so many times.”

“Can’t you learn to do it yourself?”

“You said you wanted this done as soon as possible. In fact you said it should have been done weeks ago. Sure, I could learn how to do it, but it will take me a few weeks and it’s not something we would ever need to do again.”

Let’s leave this scene. It only gets worse.

Experiences Repeated Until Lessons Learned

Inherent in working for a small business is the understanding that upper management doesn’t always understand that the IT team doesn’t know everything there is to know about every piece of hardware or software that is in use in a company that has been around fifty or sixty years. Now do they seem to realize that the IT folks don’t know everything there is to know about the latest technology out there. One of my pet peeves is when the boss hears about something one of his friend’s companies is doing with some new technology and asks why we aren’t doing that too.

Obviously this post is not like my usual stuff. There is very little focus on the events of the latter days. My work consumes a lot of my mental energy lately. I thought perhaps writing about dealing with bosses and technology projects would be a good way to relieve some of the stress of making a living in a world of declining light. I am witnessing firsthand the loss of civility, kindness, patience, and just plain human decency in the business world. It’s not just at my place of business either. My son, who also works in technology, has shared some of the same observations. It’s not so friendly any more.

A Lifetime in Babylon Prepares us for Zion

I know it may seem a paradox, but sometimes working in a toxic environment teaches what we want our own world to not be like. We are gods in training. What kind of a world do we hope to create someday? Will our world have the principles of Babylon, of trade and commerce, where the goal is to strive to get ahead or to get more than the other person? Perhaps it’s inevitable. Perhaps each cycle of God’s eternal round has many of the same environments and characteristics where opportunity to get gain is made to appear more enticing than the opportunity to serve unselfishly.

I chose this career long ago. I remember the day the Lord presented it to me. It wasn’t a coincidence that a high school teacher showed us a marketing movie he had obtained from IBM on making disk drives. I was hooked. I’ve been working with disk drives ever since. Storing and retrieving knowledge on magnetic media is the core of my job. I love the advances in technology I have seen in my lifetime, especially in this area. Spinning platters are giving way to solid-state drives. But knowledge retrieval systems and Business Intelligence should never be more important than human kindness.

May God bless us all to treat each other the way Christ demonstrated – with love, kindness and especially with human dignity. After all, He also worked a trade as a carpenter for many years before he began his ministry. He drew so many of his parables from life around him, from things his listeners would understand. He spoke to Roman soldiers, the tax collectors, the common folks who tended sheep and goats. Today, were he to come and teach us, perhaps he would use the marvels of technology in his parables. “The kingdom of heaven is like a software developer who …”