Wear Whatever You Want

In the old days of product development in IBM, the release of a new version of the product to manufacturing was a big deal and would often be greeted with some extra financial rewards of some types for the product developers. The rewards would typically be cash bonuses and awards for the key engineers that contributed to the release. Now times are tough though, and those traditions are long gone. Since 2005, the team I am working on currently has released roughly six major versions of our product – the milestones come and go.

Run, rabbit run. 
Dig that hole, forget the sun,
And when at last the work is done
Don't sit down it's time to dig another one.

Breathe: Waters, Gilmour, Wright

Now, upon the completion of a release, the team members may get a day off (Management Directed Time Off they call it) and a pizza luncheon courtesy of management, but that is about the extent of it. To compensate for the lack of that truly good $tuff that all of us could use, management will often concoct other team-building events.

These events are designed with a goal in mind of improving the development culture of the organization. These are well-intentioned of course, but a “cool” development culture can’t really be created by outside forces like managers and PHBs, so these usually come off feeling forced and contrived.

For example, a couple of times a year, there will be Pancake Breakfast where the managers will cook breakfast for the worker bees – I know WTF? – or there will be some Summer Olympiad-themed outdoors events when the weather gets nice. These will consist of a cook-out accompanied by activities like ping-pong and volleyball. I generally don’t participate in these events – and I am not alone.

A couple of years ago, management thought it would be a good idea to improve team morale with a big college tailgate-themed outing. Across our third-line development organization, all the engineers and testers were encouraged to bring a tailgate food and join in the festivities in the parking lot where the managers would grill meat and serve the team members. The invitation associated with the event had a college football theme to it – the event was held in the fall and participants were urged to proudly wear their favorite team colors and apparel. 

Our development organization is organized around product or component teams. Each team is a fairly self-contained tightly-woven entity of managers. engineers, testers, and information developers (technical writers). The teams are typically referred to by the cryptic product acronym (SAAS, MADT, SRM, etc). Apparently, for some folks, this bond between an engineer and their team can be pretty strong, as evidenced by the following anecdote.

A colleague of mine is assigned to a different team than mine. For purposes of this discussion, let’s refer to my colleague’s product team as Team ABC. My colleague relayed to me a story about this College Tailgate event involving one of his fellow team members, who shall be referred to as The Supermodel. As her name would suggest, this engineer is quite striking – the term supermodel is really not an exaggeration in her context.

A couple of days before the College Tailgate team-building event, The Supermodel approached my colleague with a confused and troubled look on her face:

• The Supermodel: “Did you see that invite about the tailgate in the parking lot?”
• My Colleague: “Sure. What’s up?”
• The Supermodel: “I had a question about that. What are the ABC team colors?