Nine To Five

My Career and Professional Life

This is an abbreviated version of the story for brevity's sake.
Click here for the lengthy detailed story.

The Learning Years

When I was growing up, computers were a thing, but they were either science fiction versions like in Star Trek, or huge mainframes in the basements of banks and insurance companies. I was in high school at the peak of the disco era when Radio Shack released the TRS-80 Model I. My friends and I would go down to the local store and stare at it agog. As a self-described science nerd I was intrigued by computers, and how one would go about programming them, but it was just a passing curiosity. I was going to be an architect, and at the time there was no cross-over. Computers were used for data processing, reading tapes, and printing bills.

My first real experience programming a digital device was actually on a Texas Instruments programmable calculator. I was now a senior in high school working my first job as a lifeguard at my town's municipal indoor swimming pool. The manager of the facility was an engineering school dropout, and he had one. He let me borrow it, along with the manual, so I could learn how it was used.

The thing would store and execute a sequence of instructions in the form of keystrokes on the calculator keypad. In addition to the basic computational functionality of a conventional scientific calculator, it could store and retrieving data from the memory, and it had functions that allowed for loops and if/then/else branching. It had a rudimentary editor where you could step through the sequence of instructions, insert or delete steps, and otherwise make updates. I didn't really realize it at the time, but these were all the characteristics of a simple computer.

I used it on my calculus final exam. While all my classmates were solving a differential equation by iteratively calculating a complex formula over and over again to plot x/y coordinates on a graph, I programmed the calculator with the formula to run through the iterations automatically. I began to perspire as I fell further and further behind trying to get the formula programmed and debugged, but once I did the calculator started spitting out figures and I sped to an early completion.

That was it for me as a programmer for a while. I turned back to my architectural training. When I went off to college the architectural curriculum focused on studio art and art history, but I continued taking math courses because I understood it to be required for the architectural trade. I could do the math, but I didn't like it. It really bogged down my semesters and introduced an arduosity I could have done without. The first semester of my sophomore year I decided to take a computer programming course on a lark just to take a break from all the math.

The programming language they taught us was BASIC on a DEC PDP minicomputer. I got it instantly. My brain was able to think the way that a computer processor worked. I could noodle out the assignments and craft computer code that was sleek and efficient. I could track down and fix bugs at a prodigious rate. My programs were like works of art. I felt like a savant. I gobbled up the material as fast as the professors could dish it out. My classmates started coming to me with their questions, and even the professors would seek my insight from time to time. I decided then and there to change my career path from architecture to computer programming.

The problem was that this institution didn't offer a computer programming major. I made the decision to transfer out to a school that did. When I transferred to the other school they made me start the course sequence from scratch, beginning with Introduction to Programming. Writing the code was easy, but they made us do it on punchcards. They had a Burroughs mainframe computer. Upperclassmen could use the video terminals, but they made the freshmen use punchcards. You would drop your stack off at the computer room, and later come by to pick up the printout. I think they did this in part to reduce the considerable demand on the video terminals, but I secretly suspected it was also to haze the new kids and make them pay their dues like the old-timers had to do.

Once I progressed to the advanced courses I was able to use the video terminals, but getting terminal time was a fucking nightmare. There was way more demand for terminal time than there was availability, and the school couldn't be bothered to have a mechanism to manage the queues and/or reserve time. It was Lord Of The Flies. It was such a battle to get terminal time that it made it nearly impossible to get my assignments done.

It was so bad that I was ready to give up my computer programming career, but then a miracle happened. The personal computer revolution had taken hold. The college announced that the DEC Rainbow would be their computer of choice. They would be sold in the college store, and assignments would be accepted from that platform. I'm not sure why they chose the Rainbow. The IBM PC was becoming the standard, but for some reason the college didn't go with that one. But I didn't care. I begged my parents to buy me one. They cost a lot of money back then, but I made the case that it was a requisite cost just like my tuition and books. They winced a little at the expense, but they wound up paying for it.

Now I was off to the races. I could do my programming at my own pace in my own room. I didn't have to fight for terminal time, and I didn't have to struggle with the antiquated Burroughs systems. MS-DOS was easy to master, and the Pascal language they were now teaching us was great to program in. I doubled up my course load to repeat some of my earlier classes and bring up my GPA. It was still a lot of hard work to get through the assignments, but I had the resources I needed to be able to do it.

Early Jobs

A couple years later I graduated with my degree in Computer & Information Science. I was confident in my abilities, but I was pathetic at pursuing employment opportunities. The college had a career office where they helped us with resume writing and interviewing. I was okay at the former but pretty bad at the latter. I was young and naive, I was intimidated by the whole process, and I didn't understand how to tell the interviewer what they wanted to hear. Many of my classmates graduated with jobs all lined up, but I didn't. I had my sheepskin, but no prospects and no idea what would become of me.

I wound up going down to Washington DC where a friend was in grad school. I started answering ads in the Sunday paper. I got some interviews, but I still didn't know how to play the game, and I kept getting passed over. The first offer I got was doing data entry at a doctor's office in a sketchy part of town. Washington DC is known for the government buildings and handsome homes, but the truth is a lot of it is the hood and could be quite scary. I always felt like I was taking my life into my hands just driving to my place of employment.

The work wasn't bad. I was essentially 2nd shift. I would get there as the office was closing, and type the day's notes into their records system. Data entry was beneath me in terms of my abilities, but it was a paycheck, and it was a learning experience. I was able to see real-world data for the first time, and get a feel for how it was structured in a real-world information management system.

After I was there for a short while I got my first real job offer. I was hired by a company that produced accounting software for the IBM PC. My job was to do phone support. Customers who had questions or problems would call up, and I was on the small team that would provide the answers. This was also not the kind of work I wanted to be doing. I wanted to be the one writing the programs, not helping people use them. But it was a rung higher than data entry, and also valuable experience in establishing a foundation as an information technology professional. Doing support was kind of like boot camp. It would teach me in no uncertain terms what the user experience was like, and it would serve me well later in my career.

The problem with this job was that I knew computers, but I didn't know accounting. I could help them install the software and manage their files, but most of the questions were how to use the software to conduct their business. My knowledge of accounting principles was basically limited to debits and credits. I didn't understand things like amortization schedules and fixed asset depreciation. I had to do my best to learn all that stuff on the fly. It was a steep learning curve, and I didn't really have anyone to teach me. I mostly had to have the customers explain it to me as I tried to explain to them how to use the software to manage it.

There were a couple of interesting aspects to this work, however. To the person on the other end of the phone, I was their savior. They were having trouble getting their job done, and I was the person who would solve their problem and get them going. Sometimes when I returned calls I would get some secretary who would tell me that so-and-so was too busy to speak to anyone, and say it in a bit of a condescending tone, like "who do you think you are." I would be like, "Let them know who's calling. I think they're gonna want to take my call." They'd begrudgingly put me on hold, and then a minute later their boss would come on the line appreciatively, enthusiastic to talk to me. I knew that they dropped whatever it was they were doing, or cut off whatever conversation they were having, because getting my answer was their highest priority. It was like a super power to get past the gatekeeper, and it always made me feel important and valued.

The job was a learning experience in other ways. The support area was like a pressure cooker, and in the heat of the moment I would use colorful language in my exchanges with my coworkers. I was given feedback to keep it clean in the office. I would also bolt out the door the second the clock struck five, blithely unaware of how this made me look. A couple months into this my manager took me out to lunch to give me some feedback. He was nice about it, but the message was basically to shape up or ship out. I had already decided that Washington DC wasn't for me, so I graciously gave him my 2-week notice. He wasn't really expecting that, but he had no choice but to accept it.

The irony is that after that my job performance spiked. I had finally gotten to the point that I knew the accounting issues people tended to call in about, and I had learned the software well enough that I could usually answer the questions as they came in. I was opening and closing tickets at a feverish pace. And because I knew I'd be going back home soon, my attitude was a lot lighter. Other people in the office started noticing, and I was getting some compliments. All this was just as I was on my way out the door.

First Real Job

I was happy to move back home and return to my sphere of comfort, but it was a dark time professionally. Getting another job wasn't as easy as I thought it would be. All the opportunities were an hour south of me in Syracuse. I was sending out resumes, but not getting any interviews. I was running out of money and getting desperate.

It felt like an eternity, but it was actually only a few months before I got an offer. The Bennet Funding Group was an up and coming company that was expanding and was hiring programmers. I can use their real name for reasons that will become apparent later in this tale. They were a financial firm that enjoyed a perfect storm of factors that led to rapid success. Their bread and butter was leasing copy machines and fax machines. Copy machines had been around for a while, but they were becoming ubiquitous and there was a high demand for them. Fax machines had just been invented, and everyone wanted one. Leasing had also come into vogue. For whatever reason, no one wanted to buy, everyone wanted to lease. That made this company's services even more appealing. Finally, Reaganomics made leasing insanely profitable. Bennet Funding was making money hand over fist, and they got to keep all of it.

The hiring manager, George, was actually younger than me, and he didn't even have a college degree. The thing about the information technology field was that if you were capable of doing the work, not much else mattered. He understood computer programming, he had good insights on how systems should be developed, and he had done well there. The thing was he was a 1-man show, and they really needed a staff. He had been given authority to hire two new programmers. One was a personal friend of his named Andy who would be coming on shortly. The other was up for grabs. He liked some of the stuff he saw in my resume, and thought I would be a valuable hire. After a couple more rounds of interviews, they wound up offering me the job.

Once Andy came on board I found him to be a lot of fun. He and George and I made a good team. Between the three of us we had to cover responsibilities all the way down the stack. This was actually my first opportunity to do computer programming, which was what I wanted all along, but we also had to support the software, so I was fielding tickets like I had been doing in Washington DC. We had to do operations, running batch jobs, doing backups, etc. There was even hardware support, installing terminals, running wires, and even unjamming the line printers. It gave me valuable experience at all levels within our microcosm.

I was doing the work I wanted to do, making a decent salary, living on my own, and paying my bills. My career and professional life had finally started in earnest. It wasn't all roses, however. Since Bennet Funding was a financial firm, most of the programming was to support accounting. I thought I was done with that after my time in Washington DC, but here I was again. I wasn't crazy about it, but at least I had a more solid foundation at this point.

The other fly in the ointment was the technology. They were using an MAI Basic-4 system, so all the code was in the BASIC. I was comfortable with it as a programming language, but it was wholly inappropriate for large enterprise information systems. It's about as unstructured as it gets. We did our best to keep things organized, but it was a huge challenge to enhance existing programs without it devolving into spaghetti code. This was exacerbated by management expecting us to expedite enhancements without properly vetting them first and allowing us to do the needed analysis and design. Supporting this vast and disorganized code base became a nightmare.

This lack of strategic planning wasn't the only failing of the management style of this company. Bennet Funding was a family business. It was founded by patriarch E.T. "Bud" Bennet. He was a failed used car salesman who fell ass backwards into the insanely profitable leasing business. One son Patrick Bennet was the Chief Financial Officer, and his brother Michael Bennet was the Chief Operations Officer. And none of these dip shits new the first thing about how to effectively run a company. They had no foresight. In their mind they didn't need it. Their future was all roses, so they didn't need to think about it.

They also didn't understand how to treat their people. They thought the best way to get productivity from their employees was to chain them to their desks and watch them like hawks. Performance was measured in no small part by how few sick days people took. Spies would keep watch out the windows and tattle whenever they saw someone leaving during business hours. They motivated their workforce through intimidation. Because it was a private company they could fire anyone at any time on their whim. People were generally miserable. It was not a pleasant work environment.

Before I had been there even a year, George got fed up and resigned his position. There was a tense moment between Andy and me as to who would be promoted to replace him. It was a surprise to both of us when they went with Jerry who was an accountant who had a little programming experience. It actually wasn't a bad choice. Jerry knew the business, so he was good at prioritizing requests and detailing out requirements. He mostly left the programming to Andy and me. They hired another programmer, Debbie, so we were now a team of four.

This went on for another year. It was good work experience, but I was not exactly thriving in this challenging management environment. Michael Bennet was prone to outbursts. If things weren't going the way he wanted he would call a meeting and ball everyone out. I didn't deal with stress well back then. I wanted to get out of there myself.

Instead of leaving I wound up getting in deeper. After a while Jerry was removed from the role as IT manager to get back to accounting full time. Now it was a real contest between Andy and me who would get the position. They went with me because I had more in-depth programming skills. Andy was not happy about it. I was proud that I had been chosen, but I quickly learned that a skilled programmer does not necessarily make for a skilled manager. I managed the people well enough, but I couldn't bear the weight of the responsibility. I had no apron strings to hide behind. My ass was on the line. I had to deal with Michael Bennet directly when he was displeased. It was frankly starting to kill me. All the while Andy was giving me the cold shoulder because he was still bitter for having been passed over. He had been one of the few things keeping me sane, and not only was he no longer playing that role but his behavior was adding to the stress.

By the way, this whole time there were rumors of financial impropriety in the business. The long and short of it was that they had more investors lined up to give them money than they had customers looking to lease fax machines. The correct practice would have been to put the investors on hold until such time as there was business for them to invest in, but Patrick Bennet didn't want to turn down the vast sums of money that kept showing up at the door. He basically mismanaged the company into Ponzi territory. At least that was the rumor. I wanted to run a program to compare the money we were taking in on leases compared to the amount we were paying out to investors and see which one was larger. That would have been a whistle-blower report. But I was too busy keeping my head above water as it was. It would have been a complex endeavor to track down those numbers.

Finally I got to my breaking point. I couldn't take any more. I had a meeting with Micheal Bennet where I laid bare my soul. To his credit, he was understanding. He didn't just beat me up over my failings. He wanted to solve the problem. We brought Andy into the conversation. We came up with a scheme where Andy would take over as manager and I would basically go back to being a programmer, but they made up some title for me to help me save face. But at least I could go back to full-time programming. I did some good work during this time.

I still wanted to do anything to get out of there. I would have taken any job just to escape that pressure cooker. One of my fraternity brothers was working at Cornell University down the road in Ithaca. The next time they were doing a round of hiring he let me know. He told me to get my resume in as soon as I could. I dashed something off and sent it in right away. I would have done better to take my time because it was riddled with typos and spelling errors. What was worse was there was absolutely no reason to rush. Cornell really took their time when it came to hiring. It was a total mystery why he told me to put a rush on it.

If I had been doing the hiring I would have tossed my resume into the trash based on the typos and spelling errors, but one of the hiring managers was able to see past it and realize that I had a lot of valuable skills and experience. He went to bat for me over his manager's objections, and I was offered the job. I had to take a rather substantial pay cut, but I was more than happy to do so.

It was very gratifying to give Michael Bennet my 2-weeks notice. Or it would have been. I wanted to throw it in his face but he didn't really seem to care. I didn't do a damn thing those last two weeks. I had gotten my hands on a PC-based version of "Leisure Suit Larry." I played it non-stop all day every day. At first I couldn't play it because it kept on beeping and I couldn't figure out how to turn that off. I finally opened up the PC and snipped the wire to the little speaker. I kept on playing, making my way further and further into the game. Finally on Friday afternoon of my last day I made it all the way to the end and got to see the fireworks.

There was no going-away party for me. There was no cake and ice cream. Michael Bennet didn't even say goodbye. When I left the office on my last day I had to track him down to shake his hand before he just went off to whatever he was doing. I walked out and never looked back.

From Corporate World To Higher Education

The difference between Cornell University and Bennet Funding was night and day. I had gone from a poorly run small private company to a massive educational institution. Whereas there had only been four of us running the whole department, Cornell had a small army of staff divided into echelons dedicated to different layers in the stack. We programmers were at the top of the pyramid. Teams were organized around the major administrative offices in the university. Programmers like me were the worker bees. Each team had a Project Leader who was the primary contact with their administrative customers. They would get the requirements and give us our assignments. Above the Project Leaders were the managers, and at the top was the director.

I found the working environment to be a dramatic relief from Bennet Funding. Employees were free to do their work in their own time and come and go without scrutiny. I found Cornell to have an institutional culture that sincerely valued their workforce. They got it that a happy employee is a productive employee. Some of my new colleagues would complain from time to time about this or that. I would look at them, shake my head, and tell them they didn't know how good they had it.

The technology was all new to me. Central IT was on an IBM mainframe computer running Natural ADABAS, which was a database with its own proprietary programming language. It took me a while to learn this new language. It wasn't all that complex, but the syntax was a little nutty. It was designed to read like regular English, but that made it a little verbose, and it was all rather inscrutable to me. It was difficult to find someone who could just explain it to me clearly. But after a while I caught on.

My team was assigned to the Alumni Affairs and Development [AA&D] office. They were rewriting their gift data entry program. Cornell got a lot of gifts. In addition to run of the mill alumni donations, they had some wealthy and high-ranking alumni who made huge gifts, as well as corporate donations. All of these had to be processed and cataloged in an intricate and complex way. Ultimately they had to be passed on to the general ledger. Despite this significant change in my career path I was basically still doing accounting programming. I was vexed that I still couldn't escape the accounting applications, but at least it had become old hat by this point.

The gift data entry system rewrite was a huge project with many components that all had to come together. The schedule was not tightly managed, but the deadline was firm. It had to be in at the turn-over of the fiscal year so that they could start out fresh on the new system. Things were rather tense as the date approached. We were ready to go, but implementing a new system of this size was a major undertaking. It was my first experience with a deployment on this scale. We all held our breath as we flipped the switch, and we were at the ready on that first morning that it went live. I was Johnny-on-the-spot as any bug reports came in. I had a reputation for being able to track down and fix bugs quickly. It was touch-and-go at first, but things settled in pretty quickly. It was a success.

I remained on the AA&D team supporting the existing code base and taking on random tasks. I would have been happy to stay there, and the customers loved me, but an interesting opportunity came up. There was an opening on the database administrator [DBA] team, and I decided to make the switch. I knew it was not a good fit for me, but I wanted to challenge myself. It didn't go great. The technical nature of the work was over my head, and I didn't find myself rising to the challenge. I had on-call duties to do maintenance and enhancements off first shift, and if anything went wrong I didn't have the wherewithal to figure it out myself. It was all very stressful to me.

After about a year of that I was very relieved to move on to a different role. I was back to programming again, but on a different team serving different customers. This became a time of growth for me. We were focusing more on how we structured our code, and doing more up-front design, and trying to establish a development methodology. It was my first real experience with flow charts and data models, and my first exposure to proper project management techniques. It was still rather primitive, but it was a start.

By this time I decided I was going to stay at Cornell for the long term. When I got there I was escaping the nightmare job at Bennet Funding. I figured this was just where I would land, catch my breath, and decide where I wanted to go next, but the truth was I had no reason to leave. I was happy working on a college campus, and was coping with the inefficiencies that come with the distributed and risk-averse leadership structure. I figured it was time to lay down roots. I bought a house and had every intention of completing my career at Cornell.

It was around this time that the Feds finally caught up with Bennet Funding. Someone finally blew the whistle, and an investigation revealed a massive pyramid scheme. It was exactly what the rumors implied. They had been paying out more to investors than they were taking in from lessees, and had to keep bringing in more investment money to keep the ball rolling. It was the largest Ponzi scheme at the time, and they would hold the record until Bernie Madoff came along. It made the national news. There's nothing like seeing your old boss being escorted into a federal courthouse on network TV. Michael Bennet wound up getting a light sentence, but Patrick Bennet served 19 years.

The Next Wave

Back at Cornell, the technology was beginning to evolve. We were stuck on a mainframe computer and 80x24 character "green screens", but more and more was happening on the desktop. By now it was the mid-90's, and graphical user interfaces (i.e. point-and-click; drag-and-drop) was becoming the standard. The tech wizards in our department started developing "client/server" technology. They created tools that would allow a graphical user interface on a Macintosh to access data and trigger routines on the mainframe. This was kind of the best of both worlds. I wasn't egg headed enough to be in there developing the infrastructure, but I was an early adopter. Not only was I at the forefront of implementing systems in this new technology, I started writing documentation that would help other developers adopt it. I was starting to shine like I never had before.

While this evolution was staring to take hold, something came out of left field that took us all by surprise. A project to develop a new HR/Payroll system on the mainframe had been going on for years and years. The product they were creating was top-notch, but it was an example of runaway scope with no schedule. Development just kept going on and on with no end in sight. One day the customer announced out of nowhere that they were tired of waiting and were abandoning the project.

Until then, custom software had been the name of the game. Commercial software was typically in the form of word processors and spreadsheets, but large scale business packages were now becoming available. Someone in the HR office learned that a company named PeopleSoft had an HR/Payroll package that could be implemented at Cornell. They opted to ditch the custom software that was still nowhere near ready and go with PeopleSoft.

None of us were expecting this. It was a 180 degree culture change. The University had been running entirely on custom developed programming. The down side of that was that it's inefficient to do, as evidenced by the runaway HR/Payroll project, but the benefit was that it worked exactly the way the customer wanted it to. PeopleSoft was designed for the corporate world, and Cornell business practices would have to change to conform with the software. That was an even bigger cultural change. A dinosaur like Cornell was accustomed to getting its own way.

Alas, the change was coming, and there was nothing we could do about it. It was basically an all-hands-on-deck scenario. Different people at different levels from across our IT department had to come together to figure out how to make it work. PeopleSoft operated in the same general "client/server" architecture that we had been experimenting with, but implemented very differently. The mainframe was out of the picture. We would need new hardware to run the backend database, and new staff to implement and support it. The user interface was in the form of a "fat client" that ran on PCs. Cornell had previously been a Macintosh shop, so they needed to buy an army of PCs and staff to support them.

The software, while "pre-packaged" was still configurable to meet a variety of business needs, and customizable to a degree. A whole team was put in place to work with the customer to figure out how it should be configured, and what customizations to implement. We brought in a consulting firm to help with this. This was another cultural shift. We were accustomed to doing everything in-house. Depending on consultants was a difficult pill for many of us to swallow.

I was on the conversion team. We had to pull all of the legacy data off the mainframe and transform it into the structure of the new system. This was mostly leg work. There were no decisions to be made. We were downstream from the decision makers. But we had to work directly with the customers to know that Field-X in the mainframe mapped to Field-Y in PeopleSoft, and what, if any, transformations the data needed to undergo.

We were also assigned a consultant to help with this. We balked at that, thinking we didn't need anyone's help. But he came on board whether we liked it or not. It actually wound up working well. He was a good guy, he was smart, and was good to work with, and he took on a huge portion of the workload.

Our work became the tip of the spear when it came time to deploy. The conversion of data was the first step to be executed. This really put us in the spotlight, but the good thing was that when we were done we were done. Once the conversion ran and the transformed data was loaded into the new system, our part was concluded. It was those who configured the new system and developed the customizations who needed to stay on board and see to the care and feeding of the new system indefinitely.

Long story short, when the day came our conversion worked well, my team washed our hands of it, and the HR/Payroll office was living in the new world. It wasn't perfect, but it worked. The institution at large took notice. This was the wave of the future. Custom programming would become a thing of the past. Vendor software was where it was at. PeopleSoft decided to venture into the higher education space, and started developing alumni and student systems. Cornell laid out a multi-year plan to implement all of it and piecemeal retire all our old mainframe systems. The wave had begun.

My role in the HR/Payroll project had concluded, but other things were afoot. The other fundamental shift in the technical landscape had to do with the web browser. By now it was the late 90's. Web pages had previously been frivolous sites, silly games, or promotional material, but tools were becoming available that would turn static HTML into a procedural language that could implement logic and access databases. The tool we adopted was called ColdFusion. It seamlessly integrated the HTML with procedural functionality and database access.

I took to that like a fish to water. I had been playing around with HTML and had gotten good at it, so I had a solid foundation. I also understood data structures and could design a solid database. We paired the ColdFusion up with a Microsoft Access database. I didn't know Access as a tool, but it was easy to define the data structures. This allowed me to support the whole stack. I could manage the database and write the code. I was a 1-man development machine.

I got loaned out to the AA&D team. This kind of brought me back to where it all began. They were the next to go with the big PeopleSoft implementation, but we had to wait until the product was developed by the vendor. To tide them over I was put at AA&D's disposal to use ColdFusion to develop whatever interim solutions they wanted. I was actually given a desk out in their office space and was co-located with them full time. They had carte blanch to do whatever they wanted.

This was perhaps the most productive time of my career. I didn't need to rely on anyone. I could design the backend database, write the code, deploy applications, and support them all by myself. I had always been a quick developer, but now I was operating at light speed. I had direct access to the customers, and they had complete freedom to specify whatever they wanted. We could stand up systems just as fast as possible. They were happy. I was happy. My management was happy. Everyone was happy.

This assignment also allowed me to dodge the Y2K bullet. Remember that? All of the legacy systems that were on the mainframe had the 2-digit dates that needed to be fixed before the year 2000 rolled around. It was nasty work. It was gritty and detail-oriented, if affected every aspect of every legacy system, and it absolutely couldn't fail. There was a skeleton crew that was assigned to the task, augmented with some Russian consultants. I don't know why Russians. I guess they were the ones who were willing to do the work. All I knew was I was very glad to have been omitted from the whole tarball. To their credit, their work was flawless. When we all came back to work after New Years everything functioned fine without missing a beat

After a couple years of this, the AA&D vendor product was ready, and everyone ramped up for the implementation. There were some advantages this time. Unlike HR/Payroll that affected every office across the institution, AA&D was isolated. The only connection to the outside world was passing gift data to the accounting system. This greatly simplified the whole affair. Additionally, the scope and scale of the business domain was smaller than HR/Payroll. This meant that the project itself would be smaller and simpler. Still, we engaged with a consulting firm to manage the project and provide additional resources.

The leadership on the AA&D side had learned some lessons from watching the HR/Payroll project, and they made some critical decisions. First was that they would find people to back-fill the responsibilities of the staff who were assigned to the project so that they could focus on it 100% and not have to try to keep doing their day job at the same time. Second was that they sequestered us out in office space far away from everyone so that we would be free from distractions. And finally they arranged for some team-building exercises so that we could form a team identity and have techniques to use to keep our team dynamic smooth and productive as things got tense.

The consultants were good to work with both personally and professionally. The AA&D staff on the project were also very personable. We all made a good team, and it was a good working environment. My previous few years working directly with AA&D put me at the center of everything. I had at least one finger in every pie. That had me spread very thin. I was trying to focus on so many things all at once that it became rather stressful. I also had to learn a couple of new technologies that I was put in charge of. That wasn't my strong suit. I could develop systems like nobody's business, but trying to understand systems that other people developed was a challenge to me. I also had some personality conflicts with a couple of snot-nosed young upstarts that AA&D had brought on internally. That elevated my stress to the point that it became difficult to manage.

When it was time to deploy, the conversion went smoothly, and the system worked well. Everything was good, at least for the time being. The problem came a couple months in. When their annual fund raising drive started in earnest, the system usage exploded. The solution we developed to support that function was not designed for the volume we encountered. I was left holding the bag while another team set about developing a more industrial strength solution. In the meantime I was absolutely drowning. Requests were coming in faster than I could fulfill them, but the schedule could not slip. It took all my skill and resolve to keep it together, often not delivering until the last possible second, which had the business people stressed out. This went on for weeks, and I became positively burned out.

Finally the enhancements came online and I was off the hook. But all of that had taken a toll on me. I was exhausted. I looked out to the future, and I didn't like what I saw. Because of my close relationship with the AA&D office, and because of my knowledge of the assemblage of systems that were now in place, I would presumably be assigned to them for the foreseeable future. I didn't want to be tied to this business area any longer. I needed to make a break.

At the same time I had things percolating in my private life. I was in a long-distance relationship with a guy I had met while on vacation in Palm Springs. We wanted to get something more serious going. I wasn't happy with what I saw laying ahead of me at Cornell. I decided to take a leave of absence. Not only would it allow me to catch my breath and recover from the insurmountable stress I had been under, but it would also cut the cord with AA&D. They would need to learn how to get along without me while I was gone, and presumably when I returned I could be assigned elsewhere. But that was even if I returned at all. The plan was that I start a whole new life with my new boyfriend and not even return to Cornell.

Starting a New Chapter

Alas, things didn't work out romantically or professionally in Palm Springs. I returned on schedule and started working at Cornell again. But the break had worked wonders. I had experienced some personal stress from the failed relationship, but if anything it had been a distraction from the professional stress I had escaped, and I was ready to get back to work. Management agreed to reassign me.

After roaming around just a little I wound up on the team that had picked up the ColdFusion work. They were developing all manner of applications for various offices around campus who had a need. They had replaced the Microsoft Access database with Oracle, which was much more powerful.

Things started out a little slow. The team was made up of individual contributors each working alone on their respective assignments. Our manager was timid in terms of taking on new work and holding team members accountable for their progress (or lack thereof). But I was doing well on my own.

Things changed when we underwent a leadership change. Some resources were shuffled around and they brought in a new manager for our team. The new guy was a great fit for me and the rest of the team. He would work with University management to identify and prioritize the requests that were coming in. He was not afraid of taking on new work like our previous manager had been. Once he made the assignments he would leave us to do the development however we wanted without interfering. All he did was require us to have some manner of coding standards between us, and encouraged us to develop reusable routines where applicable.

I began to thrive in this environment. I was cranking out solutions and my customers loved working with me. I specifically developed a reputation for being able to work well with the business people who needed a solution to their business problem. Not all technical people could do that. A lot of them had trouble getting out of their technical niche and communicating effectively with non-technical people. But it became my forté.

Eventually the team expanded. We were so successful at what we were doing we needed to staff up to handle the increased load. I was put in a leadership position myself. I was made the official manager of a couple of team members, and hired a new employee. It was the first time since my failed management position at Bennett Funding that I had people reporting to me. That had me kind of afraid to go there again, but I actually took to it very well. I took a note from my supervisor and didn't micro-manage my people. I empowered them and let them do their thing in their own way without looking over their shoulder.

Things really got into high gear now. My team started adopting our own standards. When a new project came in we were able to crank out a solid, uniform design very quickly, and get down to developing the solution. We were quick, and our code was bullet-proof. We were absolutely on top of our game. And I was emerging as a rock star. My team loved me, my customers loved me, and my management loved me. This was probably the ultimate pinnacle of my career.

But nothing good lasts forever. A change was coming that would pull the rug out from under me. The central IT department decided to start implementing a project management practice. These behemoth vendor implementations were still going on, one after the other, but I had been able to dodge that bullet off to the side on my ColdFusion team. But the more the institution worked with consultants the more they were exposed to formal, structured project management techniques. They were adopted piecemeal here and there internally, but finally leadership made an effort to establish some consistency and uniformity.

On paper this was the right thing to do. Times had changed. IT projects were now more numerous and diverse. Pandemonium abounded. Bringing structure to the way the projects were organized and executed was needed. But in practice there were issues. The project management standards that were being adopted were heavy. It introduced bureaucracy, which slowed things down. This kind of comes with the territory. You can do a project quick and disorganized, which will be long and inefficient in the long run, or you can invest time up front, introduce an initial delay, but then run an efficient project which will ultimately go more quickly.

Conceptually this is how things could be done, but it depended on having sharp and effective project mangers. It ran the risk of that up front planning phase would get too mired in details, and slow things down unnecessarily without adding any practical value. Unfortunately that was how things played out. Developers and customers alike started hating working under the project managers. They were seen as paper pushers who bogged down the process unnecessarily, and prevented anyone from getting anything done.

We on the ColdFusion team were seeing this from a distance. Our projects were small enough that they didn't need any heavy project management oversight. I wasn't employing any of these formal techniques on my projects, but I was a seasoned veteran who had been to battle countless times. I intuitively knew what needed to be done and what sequence it had to be done in. As a team we adopted our own tools where we could break down the work, track who was doing what, what was complete, and what remained outstanding. We were getting along just fine on our own.

But that wasn't good enough for management. They couldn't have us out there going rogue. They started assigning project managers to our projects. It didn't go well. We would try to do business as usual, but the project managers couldn't keep up with us. Rather than them picking up their pace, they made us slow down. Typically they weren't technical people themselves, so they didn't really understand what we were doing, how we were doing it, and what we needed to be productive. Instead they instituted their bureaucracy on us and made us jump through hoops that we just didn't need to.

After a little bit of this I devised a work-around. I asked the leader of the project management team if I could just act as project manager on our projects. He agreed. I took a hybrid approach of doing things the way I always had, and producing just enough formal documentation to placate the project management lead. There were some points of contention, but we got by well enough. It was workable.

The real problem started when the department took the next logical step and instituted a business analysis practice. I knew something of the concept. The business analyst is the liaison between the business people who have a business problem they want to solve with technology, and the technical team that will develop the solution. This was a big part of what I had been doing since I started working at Bennet Funding. I had a knack for it. I was one of those rare technical people who could relate to non-technical people on a non-technical level, and had enough empathy to understand their business from their perspective.

The department announced that they would be making two hires. One would lead up the business analysis practice, and the other would be their deputy. I applied for the leadership position. I was a strong candidate, and I was considered, but I didn't get the job. They hired an internal candidate whom I perceived as getting the job based more on her relationship with the department leadership rather than her merits. She basically piddled around for a few months and then retired.

The one they hired in the deputy role was a guy named Grant who had been working out in one of the satellite IT offices on campus. He was the one we would wind up working with directly. It didn't go well. He had a chip on his shoulder because that was just the kind of person he was. He thought he knew better than everyone else, and he wasn't going to hear otherwise. I had a chip on my shoulder because I thought I should be doing the job myself, and I resented the fact that they brought someone else in to do it instead of me.

Things would have gone fine if Grant was good at his job, but he wasn't. Everything he knew about business analysis he had read from books. It was like an executive chef trying to run a kitchen when he'd only read cook books and never actually worked the line. His personality didn't help. Rather than learn from us and adjust his practice to meet our needs, he just treated us like we weren't on his level. It was a disaster.

Because the initial lead retired, they made Grant the lead and hired another business analyst. She was someone from outside the university. She was much more personable than Grant, and I thought maybe we'd have more luck working with her. She was assigned to one of our projects, and it didn't go any better. She was great at working with the business people to understand their business needs, but she had no technical background at all, and was unable to turn the business requirements into a technical spec.

This same project also had a project manager assigned. It was another new hire, a smug French Canadian who had the kind of face you just wanted to hit. There was friction between us tech folk and both of them because neither of them was being effective. They teamed up to throw us under the bus. We were portrayed as not being team players, and were blamed for the reason the project was struggling.

Turning Lemons Into Lemonade

I couldn't take any more of this. I couldn't go on in this environment. But I was too old and too established at Cornell to go anywhere else and start over. There was only one way out. I approached the project management lead and asked him if I could become a business analyst myself. It was a make or break moment for me. I was lucky that he was open to the idea. I was further lucky that this was back when management could redefine my role that dramatically on a whim. That would change not long after that.

Finally I was lucky that Grant didn't veto it. He was now running the show and (ostensibly) establishing the business analysis practice. He and I weren't exactly on good terms, and he wasn't crazy about the idea of me coming on board, but he didn't stand in my way. He did, however, require that I spend some time under his tutelage learning how formal business analysis should be done. This was absurd. He couldn't hold a candle to me. But I was a good little plebe and I went along with it. Those skills I developed being hazed as a fraternity pledge back in college finally came in handy. I had learned how to just say, "Sir yes sir" and deal with whatever abuse they gave me no matter how misguided or ridiculous.

Things started off well. My first assignment was just a discovery project. Someone was retiring soon, and I had to capture all of his business knowledge and put it down on paper. It would not continue on to a software development project, at least not yet. I just had to capture his knowledge so they had it for his successor. I met with him many times, picked his bread to death, and produced a document that was a blueprint for his business domain. It was a thing of beauty. His department had never had this kind of thing in writing before. Even other institutions who saw it were impressed and wanted to use it themselves.

My next project, ironically, was to help shut down the old mainframe. By now all of the core systems had been replaced with vendor products. My job was to inventory the miscellaneous things that were left, and oversee the design and development of their replacements on other platforms. I was paired with a project manager that I fortunately got along with. He was a South African transplant whose demeanor can best be described as "jolly." I usurped a lot of his duties just to keep things moving along at a quick pace. Rather than act like I was stepping on his toes, he welcomed my contributions. We made a good team. The project was a challenge, but it went well. There was a small celebration at the conclusion when we went into the machine room and shut the behemoth mainframe computer off like turning out a light.

From there I started to struggle. I was put on more conventional development projects. I was good at working with the business people and understanding their requirements, but it was a challenge for me to turn around and write tech specs for the developers. In the past I had always done it myself. I would design the application by developing prototypes and refining them iteratively until it was what the customer needed. Now I was in a position where I needed to do the full design up-front and perform knowledge-transfer. I was well positioned to do this in that I understood the developers' journey and knew what information they needed to know, but I didn't know how to document it and communicate it. It was an arduous task to write it all down, and I didn't even know what format to put it in.

I became frustrated. My frustration was rooted in the fact that I could no longer just do it myself. I no longer had access to the development tools, and I started working with a team where I didn't even know the technology anyway. This was exacerbated in my difficulty getting the tech teams to do what I wanted. It was also a cultural shift for them that they weren't doing my part of the job themselves. They started getting frustrated with me because I was basically acting like a horse's ass. I had a wakeup call when I was essentially kicked off a project team. It was the first time in all my decades in this trade that I had failed.

From that point on the change was slow, but I started to improve. Things really turned around when I was assigned to an upcoming suite of projects. The central IT department had adopted a new technology for document imaging and storage. The whole effort was Grant's baby. He had championed it, and he was running the show in terms of standing up the technology and developing the initial applications. However he was floundering. Try as he might, he just couldn't get any traction. The spotlight was on him, and management at all levels was very aware that things were not going well.

I was brought on board in no small part due to my technical background. I could quickly tell that Grant was in over his head. He talked a good game, but his practical experience was limited. Beyond that, his personality wasn't doing him any favors. Standing up a whole new technology required collaboration by other teams at all levels. Grant wasn't good at working with others. Rather than listening to what people were telling him he would act like they should be listening to him. It was a big reason there were roadblocks.

I came in calmly and assessed the landscape. I put the technical issues on the back burner for the time being and looked at the implementations that were ramping up. Grant had written almost nothing down. This was my big shake-my-head moment, because he wasn't practicing what he preached. He had all this book knowledge of how business analysis should be done, and he wasn't doing any of it. He would conduct meetings and scribble on the whiteboard, but not capture any of it on paper. All I had to go on were some email threads.

I didn't gloat. I didn't throw stones. I just quietly took the wheel and started driving the bus. Grant seemed happy to let me take the lead. The first project was to implement a central repository for all registrar documents. Cornell was divided up into multiple colleges and professional schools. Each one had had its own registrar office, each with its own set of documents, each stored them in separate repositories in different technologies. There was no way to share documents for interdisciplinary students who spanned silos.

I called a working session with all the University registrars. This would have been a nightmare to schedule, but they were all pissed off at how things were going, so they were motivated to show up and demand satisfaction. To anyone else this would have been intimidating. First of all these were high-level administrators. I was bringing together a very powerful set of people. But add to that they were all frustrated and discouraged with the way the project had been going so far.

I was expecting them to show up with pitchforks and torches in their hands, but I was confident in my abilities, so I was cool and collected. My demeanor immediately affected the group. I set the stage and laid out how the project was going to proceed. Within minutes I had them eating out of my hand. I had transformed them from a group of disgruntled power players into an engaged and productive working team. From there we rolled up our sleeves and got to work. It was an arduous prospect to get all these different people on one page, but I made them stick to it, and we emerged successful.

Now that I had everything organized, the next step was to write the technical specifications for the tech staff who would develop the shared repository. This was where I had struggled in the past, but this time the technology made it easier. It didn't rely on coding as much as just making a lot of configurations. When I understood what those basic configurations were, I just had to specify what values should be entered.

Before we could deploy the system I had to get back to the other technical teams that had previously been obstructing Grant's progress. I met with them and simply listened to what they needed. We sketched out a plan by which it could all be addressed, and started moving forward. It was that simple. I really didn't know what the problem had been. Apparently it was all due to Grant's argumentative nature.

We got the technology properly implemented, we developed, tested, and deployed the registrar application, and we had our first success. My management took note. It was not lost on them that I easily succeeded where Grant had struggled and failed. That was when my reputation began to emerge as someone who knew what the fuck he was doing. We did a couple more projects on that platform and racked up other successes.

The down side of my new notoriety was that I became known as someone who could rescue struggling projects. My next assignment was similar. The project was simply to adopt a learning management system. This was similar to Cornell's vast academic course catalog, but geared towards employee training programs and other small-scale offerings. The software allowed trainers to enter courses, allow people to register, and record the results. The project was like those big vendor implementations in the past, but this one was much more modest in scale. For starters the business domain was small and highly focused, but the nature of the software had also changed. By now the industry standard was "software as a service." That meant that there was no installation on-site. We essentially leased space on the vendor's server. That further simplified the project because we didn't need to install or support anything, just configure and use the vendor's product.

Despite the simplicity and direct nature of the project, it was struggling. I was brought on board to get it on track and across the finish line. Like before, I just sat down, looked around, assessed what was going on, and calmly laid out a plan. There was a project manager who thought he was king shit but was basically clueless. I called a one-on-one meeting with him to define our roles. I told him directly that I was about to start stepping on his toes, and that it would be in his best interests to let me do so. We negotiated a line of demarkation between us. He would manage up, dealing with project sponsors and other leadership. I would manage down, directing the worker bees and overseeing the implementation.

It worked well. I didn't want to have to deal with the leadership anyway, and was happy for the other guy do cover that. The worker bees welcomed my presence. The first thing we did was noodle out what needed to be done, and then we just went about doing it. Like before, it was simple. I didn't know what the problem was. I didn't understand why these other IT professionals couldn't do it themselves. We just kept marching along until we were done. We cut over to the new system without incident. I had another success under my belt.

Then it was on to the next project I was sent to rescue. By now Salesforce had become the new shiny object that everyone was obsessed with. The first project was to provide a suite of tools that could be used by student advising offices across campus. It was a flashback to the registrar project I had done, because the advising function was under the auspices of registrar offices. The goal was similar in that they wanted consistent practices and a common repository across all the colleges and schools so that practitioners could share information.

The project wasn't struggling in quite the same way as the others had been. The problem this time was that they were spinning their wheels. As I had done before, I sat down and assessed where things were at. What I saw was lots of activity, but no progress. It was like a football team that was running plays, but each one resulted in the ball being back on the line of scrimmage. They weren't able to work their way down the field.

I had trouble understanding what the application was even supposed to do. The scope of the project was rather broad, and the project objectives were not formally documented. There was one lady, Betty, who was running the show. She was the one who championed Salesforce being brought in, and the student services application was her brainchild. Like Grant, pretty much everything was in her head. Nothing had been written down. But unlike Grant, Betty was very pleasant to work with. She recognized and appreciated my strengths, she was a good listener, and she was very open to new ideas. She was like a sponge, soaking up everything I had to say.

It took a little doing to get the information out of Betty's head, but it wasn't long before I had things properly analyzed and documented. One thing that I had learned from the previous implementation was that if you run the project meetings you effectively run the project. I had a similar one-on-one meeting with this project manager where I got him to agree that I would take on that role. He was all too happy to let me run free with that.

From there all I really had to do was to work with the project stakeholders to noodle out what needed to be done, and we set about doing it. And once again I couldn't really understand why other people couldn't seem to do this themselves. It was hard work, but it wasn't complicated. Just determine what needs to be done and do it.

It was a pretty straight forward process to get the application developed. It was a lot of work, but there were no mysteries around it. The developers were present during the project meetings where I was eliciting requirements, so they pretty much wrote their own specifications. From there it was like my process back when I was the developer. We would develop a prototype, the users would give us feedback, and we'd do another round of refinement. Eventually we had something we could release.

The challenge came in deploying it. Each registrars office was going to have to adopt it one by one. It was a rather broad suite of tools, and they were going to have to be trained in how to use them. My role morphed from business analyst into trainer. I developed training materials and went out to conduct training sessions.

It took a long time to get through all the colleges and schools. I was met with a lot of skepticism, but I didn't let that deter me. I didn't fight back. I just listened to their concerns and issues, I validated them, and we worked through them together. It's a lot easier to swim across a current than against it. This was a concept that Grant could never grasp. I also had the benefit of having worked with the registrars before. They knew me, I had gained their trust, so they greased the skids when needed. And with each successive school the rollout process became more streamlined and expedited. By the end it was becoming a no-brainer.

This was another big success under my belt. I now became the Salesforce guy. There were other projects lined up, and I was at the center of all of them. By now I was doing the lion's share of the project management work. I let the formal project manager draft whatever documentation he had to. I just worked with project teams and did what was needed to get the work done. I formalized my business analysis practice when needed, and wrote tech specs when needed, but we partnered together so well that it was almost like the old days.

Surfing On My Laurels

At this point I was cruising. I had become the go-to person that everyone wanted on their project. My official role was still business analyst, but I was really recognized as being a jack of all trades. If I was on a project then I would do whatever needed to be done to make it a success. I could do just about anything but write code. People knew it, and they started fighting over who would get me assigned.

This fed my ego. It was nice to finally be recognized for my talents. I still wondered how I seemed to be the only person who could do this. It was all very straight forward to me. I think a big part of it was because I had come up through the ranks. I had lived my life in the trenches. I had cut my teeth developing, deploying, and supporting software systems. Beyond just having the experience, I truly understood the process. My analytical nature helped, as did my no-nonsense approach. I was able to cut through the complexity and the bullshit, leaving nothing but the work itself and a clear path to the finish line.

At one point a number of factors put me into an interesting situation. The first was that I took a closer look at my retirement finances. I met with a financial advisor, and was a little surprised to realize that I had enough money in my accounts that I could retire pretty much whenever I wanted. This was comforting to know, but it was still a little early. I hadn't even turned 60 yet.

The other factor was that my role got reorganized into another part of the department tree. There was only one person in the whole department who didn't really appreciate what I had to offer. Her name was Sharon, and she was running what my old ColdFusion team had morphed into. She had been put in charge of it some years before, and she had built it up into a powerhouse. Her success made her a bit of a diva. Like Grant she thought her shit didn't stink, and she wouldn't listen to anyone else. Unlike Grant, she had the success to get away with it.

Sharon and I had crossed swords before. I was the only one who wouldn't bow down to her. She had a formidable personality, and she would bulldoze over anyone in her path, and people let her get away with it. But I wouldn't take any of her shit. We did battle a couple times, most notably over one of the Salesforce projects. She had hijacked a big portion of the deliverables to be developed by her team outside of the Salesforce platform. It was the wrong thing to do, and it introduced a ton of work that would otherwise be unnecessary. It was a nightmare to get through it, and when it was all done I swore I would never work with Sharon again if I could possibly avoid it.

It came as an utter surprise to me when I was moved over to her organization. She was to be my boss. This didn't sit well with me. I came this close to retiring on the spot just to avoid it, but I wasn't quite ready to take that extreme of a step. I didn't want to go out like that. So I did my best to suck it up and try to make it work.

The first things Sharon did was to talk down to me, like I was a first year cadet. She gave no deference to my decades of experience and mountain of successful projects. She acted like I had to be told what to do at every level. The next thing she did was to sideline me. A couple big projects were coming up. For once I could start at ground level rather than having to rescue a failing project. Sharon told me that I was going to play second fiddle to one of her staff, someone with a fraction of my experience and skills.

This was a real head-scratcher. Sharon was the one who lobbied to get me on her team. Once I was there she pretty much kicked me to the curb. It made no sense. But I didn't get my panties in a bunch. I remained calm. I would allow her person to think they were leading the effort, but I would be along for the ride the whole time. When the discovery phase was done I wrote it all up as I saw fit, and let the other person deliver whatever they were going to deliver. What they came up with was as if it had been written by a high school student who was passing themselves off as an IT professional.

By time this project was getting off the ground, Sharon surprised everyone by taking a different position in the organization. It was a big step up for her. I knew that her take-control personality style was not going to fit well with that role, but it wasn't my problem. All I knew was I was no longer under her thumb. That suited me just fine.

However no sooner did that happen than Covid hit. This caused our projects to be canceled as the university shifted its focus, and we all got sent home to work remotely. The responsibility for developing a whole host of emergency applications now fell on Sharon's lap. Everyone was scrambling to develop information systems to track infections and support remote learning. At first Sharon tried to bring me into that, but she and I clashed from the very start. I tried to do my job and bring order to the chaos, but she said that we didn't have time to do it my way. Since I was not her employee any more she couldn't force me to live in her maelstrom, so she basically just left me in the dust.

This didn't give me a lot to do. I felt guilty because most everyone else across the board was burning the candle at both ends to get all of this emergency development done, and I was sitting idle at the sidelines. At the same time I was adjusting to working from home. I feared I wouldn't have the discipline to sit at my desk all day if I had the distractions of my home and property constantly tempting me. The truth was that didn't become the problem I thought it would, but without much to do I could largely kick around to my heart's content. The new catch phrase in this remove working environment was "time theft." It described people who were being paid but not doing the work. Full confession: I became a time kleptomaniac. I spent a lot of time away from my desk, and I got away with it because no one was asking much of anything from me.

Once the dust settled and things started to get back to normal my work picked back up again. By now I become so proficient that they could throw any assignment at me and I could hit the ground running. I still had a lot of free time on my hands because I would work through the assignments faster than they could assign them. Everyone was happy with my work product and output, so no one complained.

Then I got assigned to a big ass project that would keep me busy pretty much full time. It was to implement a new mass emailing system. Like everything else at Cornell, every college and every administrative department was doing their own thing. This caused great duplication and inefficiency. Our task was to implement something centrally that everyone could migrate to.

The first order of business was to select something. I had never really worked on a vendor selection project before. Until now when I was brought on board the selection had already been made. But it was solidly in my wheelhouse. I had to get the requirements like any other project, and bring it all together in an orderly fashion. The only difference was that now I had to present it in such a way that the users could log how well various products met those requirements. From there I sat back and let them watch the demos and make the decision. I only chimed in if there was a requirement I had heard that I didn't see getting any attention.

Once the selection was made we had to roll up our sleeves and work through the implementation. It was divided into two main areas of focus. One was just the email builder, where they would compose the email contents, insert graphics, and make pretty layouts. I wasn't involved in that at all.

The other area of focus was the data. This was like mail merge on steroids. The first thing they needed was data to paste inline with the content, for example "Dear , based on your start date of , your manager would like to congratulate you on years of service."

But this was only half of it. They needed data they could use to select the audience they wanted the email to go to. For employee stuff this was pretty straight forward, but the AA&D office was also on the team. I knew from past experience how very much data they had, and how intricately they selected their audiences.

This was the point at which I really started earning my pay. It was also when the "analyst" part of my job title came into play. I not only had to get the users to formally itemize all the data they wanted, we needed to define the structures where it would live in the new tool. Then I had to work with the developers to port that data from where it lived into the tool. This would have required a lot of organizational skills and discipline under the best of circumstances, but with the volume and complexity of the alumni data it was a heavy lift. For once I wasn't asking, "Why can't anyone else do this?" I was saying, "You're lucky you have someone like me on your team."

By the time we were ready to deploy, they were pretty much done with me. The data transfer portion was in and tested. The training and rollout had to do more with composing the emails and making the pretty layouts. I wasn't involved in that to begin with, so I was not called upon to train anyone in how to do it. The rest of the rollout had to do with training people on how to use the database to select the recipient lists and paste in the substitution variables. To my relief, that fell on the data team who implemented the procedures to bring the data into the tool. I was able to pretty much walk away. But I left with everyone from the lowly developers up to top level management and everyone in between saying they couldn't have done it without me.

The Final Curtain

By now I was actually getting ready to retire. I chose my 62nd birthday as my retirement date. That had originally been tied to Social Security. My financial strategy had changed, but I still had it in my mind, so I was sticking with that date. It was still a ways off into the future, but I made no secret of it. In fact I brought it up with every conversation. I wanted to give people plenty of time to prepare to get by without me.

I wanted to coast quietly across the finish line. I wanted to get a handful of cake-walk assignments I could just knock off in my sleep. I wanted to go out with a whimper, not a bang. But that wasn't what fate had in store for me. Not by a long shot. My swan song would be one for the ages.

There was a project that had been struggling for years. It was to replace the facilities management system. Cornell had hundreds of buildings, and each one had hundreds of rooms. They all had to be tracked and managed in an information system. The tech team who supported that department had a reputation for being a bunch of hacks who did slapdash work, and the business principals had a reputation for being difficult and inflexible. The whole area was a mine field.

A project had been kicked off to select and implement a vendor product. The project manager was someone who didn't have the best reputation as an effective practitioner, and the business analyst was Grant. I knew it was doomed from the start. Fortunately I was a million miles away from it. I watched from a distance as it crashed and burned. Others were watching too. From there things got worse. The project churned for years, and chewed up and spat out a succession of practitioners. More project managers and business analysts came and went. Even the executive sponsor eventually got yanked off it. The whole effort became a wry joke in the department. It was the project that would never end, and anyone who touched it would get burned.

It got to the point where they had selected a product, but the implementation kept failing. It would be given one last chance to succeed. The project manager that got assigned was named Michelle. She was someone I knew pretty well, and we got along great. She had good project management skills, and she took her work seriously, but she had a great sense of humor. She and I would joke and kid around, but still crank out quality work.

When I heard she got assigned I was concerned for her well-being, but then I learned that I would be assigned as business analyst. This would be my last big project before I retired, and it would be a doozy. Michelle and I met to strategize. Neither of us wanted to take this on, but both of us were ultimately up for the challenge. We knew that if anyone could finally see this through to success it would be us. We basically made a blood oath to see it across the finish line or die trying.

The lead on the business side was someone I knew fairly well. Her name was Jade, and she was a grizzled old veteran like me. I had worked with her enough to know her style. We were very much the same in that we could be a little gruff, we didn't suffer fools, we spoke our minds without restraint, but we were damn good at what we did. Jade had all the hallmarks of being a difficult customer, but she didn't exactly have that reputation because she was extremely effective. If you got in line and didn't put a foot wrong, you were good with Jade, but if you didn't meet her high standards then there was trouble.

Between Jade, Michelle, and me we were well positioned to get down to work, but there was one more piece. We needed a good consulting firm to help with the implementation. This was not the kind of thing we could do ourselves. We needed someone who knew the vendor product, and could guide us through the configuration. Michelle and I came on board just as a new firm had been selected. Despite the fact that this project had been struggling and failing for years, we were basically starting from ground-zero.

Things didn't start off great. The person we were working with at the consulting firm wasn't the best. She knew the product, but there was something odd about her demeanor. Jade would express her requirements, and the consultant would react funny. It was like she didn't get it, or she didn't get why we did things that way. She would act like it would be a problem to get the product to support it.

This did not go well with Jade. She kept her cool, but we could all tell there was some tension. Michelle started walking the tightrope wire. No one had much confidence. It felt like it would only be a matter of time before things melted down again. But before things could go south, we got a notification that the consultant had left the firm and we would be assigned someone else. At first blush this was bad news. It was like once again there would be yet another staffing change on this troubled project. But it wound up being the best thing that could happen.

The thing about Cornell University is it's a marquee client. The name has a lot of caché. Companies want to say they have us as a customer. That means that they will often bend over backwards to make us happy. They wound up replacing the consultant with someone at the highest levels of the firm. He had once worked at the vendor who made the product we were installing. Not only did he know it backwards and forwards, but he had connections with people at the company.

This was all good, but it wasn't even the best part. He had the kind of personality type that worked exceedingly well with Jade. He was no-nonsense. He would listen to Jade and say, "Got it." He would then either say how the product could support that, how we would have to tweak things to fit the product, or why the product couldn't do that but what we could do otherwise. No muss no fuss. Just direct communication back and forth between him and Jade. They fit together hand and glove.

We were now off to the races. I participated in all the conversations between Jade and our new consultant. Or at least I tried. At times I would attempt to assert myself in my role as business analyst. The odd thing was that Jade reacted very negatively to this. She had no trust in me or my abilities, even though we had worked well together in the past. She treated me like a saboteur.

I was totally perplexed by this. My best guess was that she had been burned so many times in the past that she didn't trust anyone but herself when it came to communicating the requirements to the consultant. I took a step back. I knew what needed to be done with respect to business analysis, and I could see that Jade was actually doing a fine job of it. I still sat in on all of the conversations, but mostly as an observer. If I felt like something was not being given the attention it deserved I would say something, but then sit back and let Jade and the consultant address it. This actually worked fine. Things were running perfectly smoothly.

Eventually I was given a side quest to lead up. There were a bunch of ancillary systems across campus that consumed facilities data for their own purposes. Each one of these would have to be retooled to connect to the new system. It was a great opportunity to modernize the techniques that were used to accomplish this, but it was also a lot of grunt work.

I would have to review the inventory of systems to ensure it was complete. I would then write up a dossier for each system, exactly what they needed, and what new tool they would use. I then had to work with tech staff in my own department to design and develop these tools. Finally I would act as liaison between us and the consuming tech teams to get the new solutions implemented and tested.

There was nothing specifically untoward about that work. It was mostly a matter of coordination. I was the middle man in a bunch of technical conversations, and I wasn't always equipped to facilitate matters that didn't match up cleanly. If I could have gotten all players to clear their calendars and lock them all in a room together we could have had it done in a few days, but because it all played out asynchronously it went on and on and on. I liken that kind of work to pushing boulders. There's nothing fancy about it, but they don't want to move, so it takes a huge amount of effort.

It was going well enough, but I had to keep some stuff hidden from Jade. She had her own preconceived notion on what the technical solution would be. The thing was she wasn't a technical person, and she ultimately had no say in the matter. If I ever brought up solution designs that didn't match her expectation, she would have a meltdown. I finally just kept her out of the loop. I made certain that I understood her requirements, and I assured her that they would be met to the letter, but never got into detail. It worked.

Michelle had her quagmire to wade through, and I had mine, but both of us stayed with it through to the end. She got the system implemented and I got the integrations implemented. There were a couple of last-minute heart-stopping moments, but between the two of us we were able to keep things moving and we had a successful deployment. We were both exhausted, but we had done it. We had succeeded where everyone before us had failed. It was a feather in both our caps. I would have preferred to avoid the whole ordeal, but the truth was I was proud to have one last major accomplishment under my belt on my way out the door.

It was just a few short months after that that my retirement date rolled around. The last thing to be done was have my going-away party. Usually it was a few people in the conference room with a cake, some manner of farewell gift, and a couple of testimonials. That wasn't good enough for me. First of all I was going to invite everyone under the sun. I had a great many colleagues on the technical side, and my list of satisfied customers read like a who's who of University staff at all levels. Our administrators said they'd never had this kind of invitation list before.

Beyond that, I was going to do the event my way. I reserved the biggest room we had in our building. I brought in a number of pieces from my computer collection and had them set up like a museum. There were testimonials from my boss and a couple of my closest coworkers through the years. But then I basically did a 1-man show taking a trip down memory lane from all the years I had worked there. I had PowerPoint slides and everything. I talked for almost an hour. I wasn't sure how it would go down, but people loved it. It was an education for some of the newer hires, and brought back a lot of memories for old timers like myself. That was it for most people, but for those who wanted to stay I did a mini film festival, showing some of the art videos I had produced in my past. I printed up a little festival program and everything. I had to be very judicious because so much of my work would have been entirely inappropriate. Not a lot of people stayed anyway, but those who did really enjoyed it. When it was all done I packed up my stuff and went home.

After that I did have a minor epilogue. I worked on an hourly basis for the next six months doing a few random tasks. My primary focus was to draft a project formation methodology. So many times I had been brought in to rescue a project that had gone off the rails. My stance was that if you start off a project right, it can stay on the rails all the way through. The failings were always from omissions or mismanagement in the early stages. I worked with a task force and we crafted a step-by-step process that, if followed, would position any project for long-term success. It was a thing of beauty, and I was gratified that it would be my final deliverable after a 35 year career.

The department never wound up using any of it.

Index | Next Essay -->