Being There – Geek Style

July 2, 2010

I’m getting another lesson in “being present” with people. Specifically my 3 year old daughter. When I’m playing with her, she demands my absolute, complete and undivided attention. Any distraction on my part is a punishable offense – usually by a rather irritated, “HELLO Daddy!” As a part time geek and full time father, I find this requirement to be completely “present and in the moment” often hard to satisfy. You see I’m really the typical introvert – often imagining I’m somewhere else, ruminating on a problem, running some absurd internal monologue, or otherwise just drifting about with my head in the clouds. Apparently children don’t tolerate that sort of behavior particularly well, and in my opinion, neither do teams.

I don’t know much about kids in general, but from what I’ve seen from mine so far they are *extremely* highly interactive creatures. They are avidly absorbing everything in their environments like manic little sponges. They’re asking questions and gosh darn it, they expect the answers pronto! They’re looking for a good partner, someone who is going to attend to their every need. And as a good partner, they are watching you to see where you might be going next. They repay any attention you give them with vigor, enthusiasm and affection. Not a bad dividend really.

Teams are a tougher nut to crack. They are also highly interactive beasts to work with. They are doing a lot of learning, typically trying to understand a complicated domain or design challenge. They’re asking questions and gosh darn it, they expect the answers pronto! I hope you see where this is going by now…

Recently I attended the XP2010 conference. One of the sessions that I attended was on using improv theater techniques to learn to be a better team member (this was facilitated by Mike Sutton – a really fantastic guy). A lot of improv is about being “in the moment.” It was all about making yourself a good partner to interact with. I found it to be a very powerful experience and I felt like I got a lot out of it. For instance, like many geeks, I place a high value on cleverness. But it turns out that “clever” behavior is very hard to anticipate (and even harder to produce with any consistency). So being too clever can make you hard to work with when you are doing improv work – it’s hard to know what you are going to do next. Now, I imagine there are a lot of parallels between improvisation and collaborative, problem solving work. In fact that was really a theme of the conference.

The conference reception was kicked off with a presentation by two jazz musicians. They did a fantastic job of demonstrating improvisational musical technique for us in an entertaining and thought provoking way. Part of the message was about making yourself a good partner, but for them, an equally significant message was that in order to express ourselves truly, we need to learn how to be “in the present”. They ended their presentation with the  following quote:

Yesterday is history.  Tomorrow is a mystery.  And today?  Today is a gift.  That’s why we call it the present.  ~Babatunde Olatunji

So what does all of this have to do with teams? Look, let’s get one thing straight – so much of the “process” that we use on software development teams is all about planning or history. Very little of the process focuses on the work actually being done in the moment. I consider the work in the moment, the collaboration that takes place as we are writing code, as the hardest part of the development process. We have techniques that lead us toward this mode of collaboration like pair programming, but often I find teams resist them. Teams that aren’t able to work in the moment, in the present with each other, are going to be handicapped in the speed with which they can deliver innovative solutions. If you are looking for the place with the greatest opportunity for improvement for your team, try steering away from the process – the planning and the history – and try spending more time in the moment. Focus on the actual work you and the team are doing right now. Give your team a gift – the present.


Teams – Tag, You’re Us!

July 2, 2010

I was in my brother-in-law’s office the other day. He’s a former Marine and on the walls of his office are various and sundry decorations and plaques. They’re on the walls in his office, the hallways, the garage, the bedroom – in short, they are everywhere. I’ve seen it all before and in my ignorance all I thought was, “Military dude” and never gave it another thought.

This day was different though. As I looked at the plaques I saw for the first time the same name repeated over and over, it was the company he belonged to (or some such military beast – I’ll confess my ignorance of all things military up front). In addition to the name of the group he was part of, many of the plaques contained the signatures of the members of that group. It reminded me a bit of a high school yearbook, signed by all your buddies. At that point it hit me – this guy was part of a really tight team.

Bear with me here – I know that last sentence sounds like one of the all time great statements of the obvious (hey, everybody has a super power – stating the obvious seems to be mine). Here’s my point: great teams tag their members. I get the term “tag” from John Holland (Hidden Order: How Adaptation Builds Complexity). In his book, he describes the essential characteristics of complex systems in nature. Frankly, a lot of it is over my head. But there is one part that discusses the ability of actors in a complex system to “tag” one another. He describes this property of tagging as critical for complex adaptive systems. Tagging enables them to discern important differences and to create order out of chaos. Teams are chaotic. Software teams are *really* chaotic. Last time I checked (on TV), war was chaotic too. So this notion of tagging struck me as important. How important was not clear to me. That is until I saw my brother-in-law’s office. Each one of those decorations on his wall reinforces the message, “This is who you are.” Tag! – you’re us.

Wow.

You see tags in all sorts of strange and wonderful places. For example: some asshole “tagged” my fence where it adjoins the street behind my house. He spray painted a slogan that I can’t even begin to decipher across roughly 10 feet of fence. I guess somehow that makes my fence part of his ‘hood.

Another example: I worked at Aldus in the early nineties. One of the innovative new product teams went out and bought themselves letterman’s jackets (The PressWise team: a.k.a. “The Wise Guys”). You know the kind I’m talking about – the nice colorful jackets that the jocks wore in high school with a big letter for whatever varsity team they were on? You saw a group of those guys wearing those jackets and what did you think? Assholes? Perhaps, if I’m honest I remember thinking, “I’ve got to get one of those!” In our peculiar little geeky corner of the prepress software world, those guys were tight. It worked. Tagging in action.

A final example: I remember the very first product that I delivered from concept to customer. On the day we shipped, the team gave me a box that was signed by every member of the team. I still have that box. That box means a lot to me (sniffle…). We gave a box to every member of the team and it was proudly displayed on their desk. Of course these days we don’t deliver “shrink wrap” software as much as we used to. It’s all on the web. So where do we keep our box? How do we identify ourselves as part of the team?

How do you know you are on a good team? Well what sort of tags do you have to mark yourselves? How does the team mark you to indicate that you are part of the group? After looking at my brother-in-law’s office, I think we could be doing a lot more tagging with our software teams.

To be perfectly clear, there are a lot of teams out there that we software geeks can learn a lot of valuable lessons from. I don’t mean to trivialize a squad of marines by comparing them to a bunch of pale faced, bespectacled software guys trying to support a gaming habit – but I see a lot of things we could learn from the military in terms of creating really tight teams. Given the complexity that software teams attempt to tackle, it may be essential.

ps. Mentioning my brother in law may have been a mistake. He may be forced to kill me. Sorry Dana. In my own defense, it seemed like a good idea at the time…