From May 20th, 1996 to January 17th, 2020, I was an IBMer.

I can't believe all of the things I've learned, the moments I've experienced, and the amazing people I've collaborated with over the last 23+ years. As I've been catching up with people a few suggested I share some of these things. Here you go...

The old days

May 20th, 1996 I started in the Lotus Rogers St building in Cambridge, MA. I had really big and slow computer, it was a desktop, nobody had laptops. There was no VPN, we could only work sitting at our desks. I asked for a second computer so I could code on one and run tests on another. We still shipped on 3.5 inch floppy disks, around 30 of them, someone a few cubes down from me had to test the install. Ugh.

We were co-located but incredibly siloed. I was testing stuff coded by someone down the hall and I had absolutely no idea whose stuff it was. 

We worked on releases for an entire year. Code delivered on day one provided no value to our customers for an entire year. It was waterfall, we didn't call it that, we just called it development. That's just how it was. We had periods of time where one release completed, the next one hadn't started, and we had nothing to do. I bought a book (Java in a Nutshell) and taught myself Java, it was version 1.

Ghost in the Machine

We had automation that had to run against multiple versions of Windows. It took ages because I had exactly one system I could run it on. So, rather than kick things off manually, I wrote automation that leveraged Ghost (remember that?) to run the test automation, put the results on a server, change the Ghost config to boot into the next version of Windows and then reboot. A pointer to the automation on a server was in the startup group in each OS image. So, with each reboot, the latest build would be downloaded, installed, and the test automation run. Over and over again, that second computer I had ran all of our tests on all of the versions of Windows we had to test against. I was hooked. I loved automating automation.

Translation Truncation Tester

We used to get tons of truncation issues when our apps were translated into different languages. I wrote code to inspect the length of each string that ended up on a control of any kind (button, label, etc) and then checked how many characters it was, then figured out an average based on system font widths. It then checked every single dialog control to see how many characters were allocated to the strings that were displayed. After a little tuning, it found nearly every translation truncation defect we had.

Lotus Automator

I was working on a project with a team and went down to work with them in the Raleigh lab. The first morning I was there, someone walked in with a stack of CD-ROMs with the daily build. They passed them out around the lab and each person put the CD in, typed the same command, and then waited. Some got coffee, others read through their Lotus Notes Mail, some people talked. Why wasn't this process automated? I looked around and found a small project that had booted up that was being used by our VPN team. We joined forces and created a thing called Lotus Automator that was like Jenkins before Jenkins was a thing. We could change the password on hundreds of machines at a time with a few clicks. It could deploy software overnight so when you came in you had the latest build. Such a fun time. So much time saved.

Selenium

Later on I was working on this web software, but our testing software wasn't keeping up. At one point it supported zero current browser versions. Another team at IBM made the test automation software, I rebelled and brought the very first version of Selenium into IBM. I wrote an abstraction layer to redirect the calls made to the Rational API to Selenium instead. The vast majority of our tests now ran against every current browser version. Yay!

Browser Fest

We had started doing "TestFests" - when we needed to go beyond the automated tests, or for brand new things, we'd get everyone into a room and have everyone Test together. These TestFests became a regular thing. They inspired a Selenium-based tool I created called "Browser Fest". Selenium would be connected to a bunch of different browsers over Selenium Grid. You would do manual exploratory testing on your system using Firefox, and then Selenium would rebroadcast the links you clicked to a bunch of different systems over Selenium Grid, capture screenshots for each and then put those screenshots in the logs. We'd fire up all of these VNC windows and you could see the changes happening and if you had a big enough screen, could spot IE render issues live on the fly as you were testing locally against Firefox.

Jeopardy!

After years of working in the backend infrastructure space, I sat in the cafeteria in the Littleton Lab and watched a system built by IBM Research beat human beings at Jeopardy! I remember thinking I couldn't imagine how smart you'd have to be to work on something like that. I suddenly felt like a software plumber. That summer, Bill Hume reached out, he was running a small team that was working to commercialize the game playing system. It took ages for developers to know whether or not any changes to the system had any impact on how accurate the system was. Turns out they had a plumbing problem. I became the plumber of Watson ??

Agile and The Spotify Videos

The first commercial release of the Watson Core (the domain-independent Question+Answer system we built from the J! codebase) was 14 months after Jeopardy! We then worked towards getting things out the door every six months, then every 90 days, but we still couldn't align our dates with the needs of the teams building cool things on top of the Core. At Bill's Staff meeting one day, he said "We have to figure out how to ship every Sprint", then looked around the room and said "And George, is going to figure it out". So I did. It was hard. We automated all kinds of things, optimized everything until I realized people were now the bottleneck. Getting serious about Agile helped, but we still had all of these handoffs. I then saw the just released Spotify Videos. My internal blog post about them is the earliest reference I can find to anyone in IBM mentioning them. Squads, Tribes, Guilds are now commonplace at IBM. We broke our big teams down into small teams, we _tried_ to have them own a mission from thought to production. We were successful in some places, not in others, we kept improving. We started shipping every Sprint. Then came the Cloud and we started shipping weekly, some teams could release at will. Yay Agile + Spotify + the Cloud + DevOps!

Stack ranking

IBM used to have it's own form of stack ranking. It wasn't awesome. Managers couldn't rate performance on performance alone. They had to rank people against each other. You could give X number of 1 ratings, Y number of 2 ratings. It was particularly horrible in Watson where the early team had been staffed with the former 1's from all of the other divisions around the company. One day we had a roundtable with our HR leader. He asked what we thought about it. After a minute of silence, I found myself on a soapbox. I talked about how the practice prevented us from being truly selfless team members since we were essentially in competition with each other for performance ratings. Why would someone help a team member who was stuck if it would benefit them by them looking like a rockstar because they weren't the stuck one. After a moment of silence, he looked at me and said "You're fired!" - as I felt my heart sink he laughed and said "I'm just kidding, he's really on to something here! What do the rest of you think?". The next Quarter it was announced that performance reviews were changing for Watson and we'd no longer be stack ranked. The next year IBM got rid of the practice for everyone. While I'm sure the HR Leader was testing the waters, I'm going to go ahead and take credit for getting rid of the practice.

Slack, GitHub

In the early days of Watson, we used to use Notes, Connections, Sametime and Rational Team Concert. IBM Design started a project with the CIO Office called Whitewater. They had a mission to bring the best tools to IBMers. They needed partners in the business units. My friend Sam Richard and I brought Slack, GitHub, Box, and other cool tools the CIO made available into Watson. We worked with the teams, the teams were happy, awesome tools! CIO used our success in Watson as a proof point and could say "Watson works like this, why don't you" to other orgs. As I leave, we live in Slack and GitHub. Life's been good.

ZenHub

GitHub is great for source code management, and good for planning and tracking work. We needed something to make it great. We shopped around. Sam and I started a pilot of ZenHub. ZenHub adds Agile project management, reporting and so much more to GitHub. It makes it awesome. A few people started using it. Then, a hundred people, five hundred people, thousands of people, tens of thousands. The growing team at ZenHub was a pleasure to work with. They listened to our needs, they added features, they learned how to deal with the scale of a company larger than just about anyone else. Sam and I turned the pilot over to the CIO Office who now run ZenHub Enterprise for the company. ZenHub makes GitHub great for tens of thousands of IBMers on a daily basis.

GTD Squad

One of my favorite periods in Watson is when we were the GTD Squad. We worked with team after team to figure out how get things done. The funny thing is, I think we got more effective the smaller we got. At the end it was down to Micaela Eller and I. Micaela once likened us to a Jazz Band. We'd get into a situation and start riffing off each other. One time we helped our Denver team shrink their lead time so much I checked three times to see if I had gotten the data wrong. We did awesome things together, years later people are still watching our Webinars. I miss that partnership every day.

The Playbook

It started life as two pages on a wiki devoted to onboarding people to Slack and GitHub. Those two pages got moved to GitHub Pages with a cooler URL. I started putting everything that people had been asking me there as a reference. It became a thing called The Playbook where people from across the company shared patterns and how we adopted Agile at IBM Scale. Today, there's a 70 country audience that spans far beyond where we in Watson had people. For a zero budget thing, it turned out pretty well. Sadly, only available to IBMers.

Brooks' law is real

One of our projects wasn't going to make it on time. We talked about what we could do, reduce the scope? Change the date? An offer was made to Ari to a Squad to the team. Ari and I debated since we knew it'd slow the existing team down. The call was made to take the Squad since we didn't know if we'd get another chance to grow the team. 

The new Squad came on board. The whole team slowed down. We could see their Velocity go down day after day, Sprint after Sprint. We saw their lead time increase 21% from one quarter to the next. I looked in the Slack Admin history and could see that the number of messages in the team's Slack channel going up while their velocity went down. It was perfectly matched. Nearly double the messages from before with just a single new Squad with only 5 members. As the new Squad got comfortable, the number of messages returned to normal, but the Velocity didn't recover at the same rate! It was like a traffic accident that'd been cleared but the highway still slows down at the same point. Eventually the whole team sped up, but it was well into the next Quarter! So, yeah, Brooks' law is real. Adding people to a late project makes it later (or in this case, forces you to cut scope more than you would have had to if you hadn't changed the team size to begin with). So, if you're going to grow teams, be very careful when you do it.

CodeRetreat and New Hire Onboarding

Along the way we acquired a cool company. They did these things called CodeRetreats (coderetreat.org). I had them come to Littleton and run one. It's a day long intense series of iterations each aimed at helping you get outside of your coding comfort zone. Over time I tweaked the format to include some other things people needed help getting outside of their comfort zones with. Agile, Design Thinking, Team design. During one of these modified CodeRetreats, someone asked me why it wasn't part of New Hire Onboarding. I ping'd my friend Tommy Wenzlau in HR. We ran an experiment. After the new hires got their laptops, I ran a modified CodeRetreat + Agile + Design Thinking Bootcamp. Six weeks later Tommy asked me if I was ready for the trip to Armonk on Thursday. I had no idea what he was talking about. Turns out he forgot to tell me that the experiment was a huge success and there was another one scheduled for later that week. That too was successful. Next thing I knew a person I had never met thanked me for agreeing to help them start the new IBM Developer JumpStart program. Turns out Tommy had forgotten to tell me about that as well. We started running JumpStarts with each new group of new hires. A few weeks after one of our new hires came through the JumpStart, I asked him how well it prepared him for life in his Squad. He told me he opened a Pull Request on the first day in his Squad. Awesome. Today, all new hires attend this day long crash course into how IBMers work. It's awesome. I wish I had that when I started.

The Finish Line (Recruitment)

The final tale I have to tell includes a bit of a confession. For years, we've held these events called the Finish Line as the final stage of our recruitment process. We get candidates together into a big room, give them a challenge, and see what they build. Last fall they needed to change up the challenge and I was asked to come up with a pitch that would resonate with our recruits. I got busy and completely forgot about it. One day I was signing onto a video call and realized that they were expecting me to pitch the idea for a new challenge. My mind raced thinking about what user they could truly empathize with. What if we set a challenge around creating a way for new hires to navigate their first days, weeks, and months on a job. They pointed out we already had bots and enablement material to help them. I suggested we could use their ideas to help us improve the bots and enablement materials if they said it was cool for us to do so. Everyone loved the idea. The event we ran was just amazing. We had small Squads of Product + Design + Development candidates all working together to figure out better ways to get up and running at work. Empathy for the user is incredibly important for us to have and by turning the recruits into the users that would benefit from their ideas, the things they came up with were phenomenal. 

The Finish Line (my Finish Line)

So, as I come to the end of a 23 year run, I’m incredibly grateful for the opportunities I’ve had at IBM, but I’m even more grateful for being able to work with everyone I worked with. While it sounds cliche, I can tell you it’s one hundred percent true, the greatest thing about IBM are the people you get to work with.

This morning, I got my carry-on bag out to start packing for my flight to Vancouver on Sunday. Out fell the lanyard from the Finish Line event in Austin. Could there be a more appropriate metaphor for my last day at IBM? I've crossed the Finish Line.

It’s an honor and a privilege to have been an IBMer...