I first came in contact with the Jazz project back in 2005 while I was working as an IT architect in IBM Global Services. A couple of IGS and Rational managers agreed that it would be a good idea if I shared with the Jazz team some of my experiences working on large IT integration projects. So I began spending 25% of my time working with the Jazz product management team.

I felt fortunate for this interaction because I was impressed both with the Jazz strategy and the Jazz team – composed primarily of the folks who created the Eclipse platform. However, I felt like I wasn’t adding as much value as I could have since I didn’t interact much with the development team, who were driving much of the direction.

I spoke with Kurt Bittner of the product management team about my concerns and he told me “You’ve got development experience, why don’t you talk to Scott Rich about joining the development team?”. To me this was a pretty wild idea, since in Global Services I’d worked hard to ‘escape’ the Developer caste in favor of architecture. But Kurt explained that in the Eclipse/Jazz team, everyone, up to the executive level, participated in technical design and even wrote code.

After thinking about this a while, I decided it was a good idea, so I spoke with Scott about working on his Jazz server team. Our talk went well and we both had a good vibe but the outcome was a bit muddy. Because no one on the Jazz development team had seen my technical skills first-hand, and because I hadn’t done active development for more than a year, they wanted to bring me on in a sort of trial period. If I did well, there was an opportunity to join full-time, and if things didn’t go well, no harm done.

At first this was quite surprising, because since I joined IBM, I’d always been a top technical performer and had a very good reputation around Global Services. But the more I thought about it, the more I realized that this was a very positive sign about the Jazz development culture. My glowing performance reviews weren’t enough – I had to prove and show my capabilities – this team would not risk bringing on dead weight. Now I wanted to join this team even more and worked very hard. So on September 14th 2005, after two months of working on a trial basis, Scott asked me to join the team full-time. This was probably the happiest moment of my IBM career. I even saved the chat:

Scott Rich – hey, still there?

Bill Higgins – yes

Scott Rich – what would you think about joining the Jazz team? 🙂

Bill Higgins – !!!!!!!!!

Bill Higgins – are you serious?!?!?!?!

Scott Rich – yep, you’re in. your final test is to figure out how to apply for JobReq #006282 in the jobs system…

Marcus Aurelius begins his Meditations by giving thanks for the qualities he gained through observation of others who exhibited those qualities. On a much humbler scale, I recently reflected that my personality has changed as a result of observing the constructive behavior of my project leaders.

One example of this happened at the end of 2006. The day before we were supposed to freeze code for the year, I assisted another developer on a late-breaking severe defect. Unfortunately we didn’t test the fix adequately and it led to another defect which I discovered two hours after the final scheduled build completed. Sleep-deprived and stressed, I forgot about the code freeze and delivered a fix to the second defect. Fifteen minutes after delivering the patch, one of our senior technical people sent out an email reminding everyone that the codebase was frozen. I felt horrible because I’d committed a major faux pas at the most critical period in the development cycle. With great embarrassment, I sent a follow-up email to the project, notifying them of my mistake.

The next morning I came into the RTP lab for the end-game planning call with the PMC and component leads. I went to a meeting room and found John Wiegand and Scott Rich, who at this point were fully aware of the mistake I made. With a sheepish smile, I asked “Can I buy anyone a coffee?” Scott replied “You’re not forgiven that easily. What you did last night requires coffee and donuts.” John said, “Well, we all screw up from time to time, and the important thing is that you recognized the mistake and, to look at the positive aspect of it, the feature now works.” And that was that. In the end it turned out that there were a few other lingering bugs in the final scheduled build so we did one more build and all was well.

Another example was my mid-year checkpoint with Erich Gamma, reviewing the progress on the subsystem that I lead. My team was struggling at the time. In some very new technical territory, we were progressing more slowly than anyone would have liked. I was dreading the call, because Erich’s sort of a professional hero of mine, so I really wasn’t looking forward to hearing him tell me that things weren’t going well. But the call wasn’t like that at all. He began by reflecting on the things we’d accomplished and what had gone well. Only after a few minutes of discussing accomplishments did he gently segue into the discussion of areas that needed improvement. We prioritized a list of architectural features and user scenarios, and then worked through the details of what my team would need from other teams to succeed. I left the call feeling energized about what I was confident we could achieve, and over the past six months, I’m confident that we’ve met or exceeded those expectations.