Coding Cats?

Abby the Hacker Chick asks (in the context of work):

"What was the best team you ever worked on? What about the worst? What do you think made them so?"

Ah, memories. All alone in the moonlight.

Ahem. I started to write this in her comment section, but when it went over 500 words, I thought I should put it on my own blog. Memories are a strong thing. Abby describes her experience working on a "beautiful team." It was hard work, but she looks back on it as a good example.

I think that my two favorite memories of working on teams come from startup (or startup support) in the late '90s. In both cases, the situations were similar to Abby's description, particularly with the freedom and the rough hours.

In both cases, the teams were up against seemingly impossible tasks with unbelievable deadlines. On the one hand, the companies had to give us a certain level of freedom because they understood the monumental difficulty of the goals. On the other hand, the impossibility of the task helped to meld us into a strong team that felt it had enough communal power to insist on a level of freedom to get stuff done.

(It's odd to talk about freedom like that, since my role on both teams was 'CM guy')

The level of camaraderie from those teams arose partly from a feeling we were 'forged in the fire,' if you will. In a way, we were all learning as we went, we all had to lean on each other because there was no other choice, and it was all us against them (the management or the goal or the customer, take your pick). Of course, there was also the fact that the speed and intensity of the deliveries meant that any fluff got burned away. And this included underperforming teammembers. In larger orgs, in longer-lasting gigs, it's harder to burn away the cruft.

I'm starting to believe that the strength of those teams came from a sense of mission. I don't mean that we had some mission statement from a company and wanted to follow it; I mean that we had a specific target with a specific goal that had specific (vital/important/urgent) rewards and penalties based on the achievement of the objective. In both cases, a company's existence was on the line. In both cases, we were running to get the first thing out the door that would start bringing in any revenue at all. That feeds the urgency and forces the direction of the team in a way that documented standards, policies and practices cannot. Perhaps the first sentence of this paragraph should have read "...sense of a mission."

Do you think "mission-driven development" has legs? If we went for "purpose-driven development" maybe we could become a religious organization.

The next tier down of experiences includes a project that I hung onto as long as I did simply because I felt what was being produced was important/vital/urgent to the end users. I suppose that project had a sense of mission that is more like an overarching purpose, and it was when the management too many times did something that conflicted with what right-thinking people (us) knew to be the way to achieve the mission that it all blew to bits.

It's strange that I'll look back on those rough hours with fondness. I was just talking to one of those team members, remembering the futon in a hallway that I had napped on between an all-night release and an early morning kick-off. He shook his head and said he was so sorry that I had gone through that. I was a little surprised. I learned more in one month there than I had in the five whole years preceding the experience.

But he was right in a way, too. Because the problem with both of those teams is that our pace was unsustainable. You can't spend your life working 80 hour weeks. In one case, it all started to fall apart after the first release was live for a few weeks and revenue actually started. It seemed impossible to generate a desire within the team to work so hard on the second paying customer as on the first. The company was no longer in danger, the team felt it had earned a little rest, and yet we kept scheduling as if the world were about to end. That's when the wheels fell off.

In the second case, a few releases were live and the customer couldn't seem to figure out how to get his business up and running around it. When it became obvious that here would be a long time until the system could actually be used by anyone, the urgency dropped away, velocity skewed, and I quit, sold my house and rode a bicycle halfway across the US with my wife. In the 90s, I thought I was going to be able to keep up that kind of cycle: 18 months of nightmare work followed by six months of wandering the world. But it just doesn't scale.

Of course, I can smile at the old days; I was beautiful then.

So now the task is to get that sort of energy without killing everybody. I think I started thinking about teams (team-driven development? all the good acronyms are taken!) when I read Shadow Unit, which has nothing to do with software development but does have to do with teams and mission. I highly recommend it: it's a television series without actors or cameras--just a series of episodes written as if there were a television series (episodic fiction, perhaps)--about a team of government agents who investigate paranormal activity. I really like how it shows team interaction. If you try it out, do start at episode 1.

5 thoughtful messages from friendly readers:

abby, the hacker chick blog said...

Thanks for posting this! Stellman & Greene said what they found when they talked to all these people about beautiful teams were that the things that lead to beautiful teams fell into 4 categories:

1. People (of course)
2. Goals (this would be your mission)
3. Practices (this is stuff like TDD, continuous integration, etc.)
4. Obstacles (like those really wicked problems we come together to solve)

Of course, our obstacle doesn't have to be the kamikaze mission (isn't that what Yourdon called them in Death March?). But, sometimes I wonder if there isn't a compelling thing you're building or a really wicked problem you're trying to solve... then, maybe it's just another job and so nothing to get very excited, tight teams over.

Although... hmm, now I'm going to be going over the 500 word limit. But, this is making me think about the book Flow - have you read that? He gives a recipe for what he calls "optimal experience" - those things we really enjoy doing. And in it he talks about that we've got to have clear goals and we have to have a challenge or else it just isn't interesting. Now I'm starting to think that maybe these things are very close (beautiful teams and individual "optimal experience") and maybe the trick is taking the formula in Flow and figuring out how to apply it across an entire team... preferably without the 80+ hour work weeks. ;-)

AbbotOfUnreason said...

I'll have to grab that book. I'm excited about teams, just discouraged lately. I think what i was trying to get at with mission was a combination of 2 (goals) and 4 (obstacles). Goals sounds too wishy-washy to me, I want to see a bigger pull, like saving a company or getting around stupid rules or saving lives or something.

abby, the hacker chick blog said...

This is just making me realize I need to finish reading Flow... :-) Maybe we can compare notes when we're done.

abby, the hacker chick blog said...

Your link is back on my post under "Links", btw... blogger flakiness?

AbbotOfUnreason said...

Maybe we should start a book group around the Flow book. I wonder if Nate would be interested.

Weird about the link. I had figured that by creating the entry from the link in the first place it would automatically update it. Maybe Blogger just waits for Google to find incoming links.