One Week | One Tool just finished, and it proved to be among the most challenging and most rewarding weeks of my professional life. I have a feeling that I’ll need a few go-rounds to really decompress – if for no other reason than that the tool we produced isn’t being announced until Tuesday, so I can’t talk details – but I thought it’d be worthwhile to jot down some thoughts while they’re still fresh.

There’s much to blog about regarding my experience at One Week, much of which I’ll be able to divulge more fully after the veil of secrecy has been officially lifted. (Yikes! So secretive.) One of the things I can talk about now is the workflow of the team over the course of the week, something Jana has already discussed nicely in her blog.

Whiteboard spoilers!

We arrived at CHNM with no idea what we were going to build over the course of the week. Monday was spent getting to know each other, hearing from the CHNMers about they develop and sustain open source software, and brainstorming ideas for our own project. By the end of the day Tuesday, the project had been decided and teams had been divided up. I didn’t sleep very well that night, both from excitement and from nerves: the tool we’d decided to build would rely on a set of technologies that would make me the de facto lead programmer.

And therein lies the first remarkable thing about the event. By many objective accounts – breadth and depth of knowledge and experience – I was, at best, the fifth or sixth most talented developer in the group. (Not trying to be overly humble here: one look at the One Week “People” page and you can see that the deck was stacked with incredible talent, folks with whom I’m happy to be in even the same ballpark.) Differently-focused projects require different kinds of talent, and it so happened that this very focused project required just the sort of skills that I possess. So the first lesson I take away from One Week is that leadership doesn’t necessarily follow, or require, the greatest technical skill or experience. It might be that the notion of “best leader” reduces to “best leader right now”, which is to say that “best” is highly relative to particular needs and circumstances. It’s a realization that highlights how leadership roles are not (or maybe should not) be merit badges gifted to those who have “earned” them, but instead are necessary aspects of a structure – like the One Week crew – aiming to acheive an independent goal.

My second One Week lesson is closely related to the first: leadership doesn’t work without humility and trust. The way we built our tool was like digging the Chunnel: developers at home with one part of the tool’s functionality (like the British on British soil!) tunnelled toward developers who were digging from the other direction. I was in charge of making sure that the several tunnels met in the middle to make for a navigable whole. But, as you’d expect, there’s no way that one person (even one as dashing and wonderful as I am) could really know what was happening in all parts of the project at the same time. There were simply too many technical details to keep track of. Making sure that the tunnel got built, and our code got merged, meant putting a good deal of trust in the diggers, and accepting – even embracing – those moments when their work was beyond my ability to understand technically.

All this is to say nothing of the equally crucial folks who were not writing code, but we doing what we called “user experience” and “outreach”. In those cases even more trust was required: the dev team trusts the outreach team not to write checks that the code can’t cash; the UX team trusts the dev team to remain true to the needs of the end user; and so forth. Here too, in a less technical but no less accurate way, we were digging a tunnel from opposite directions. The outreach and UX teams were developing an increasingly detailed vision of what the tool needed to do, and the dev team was cranking out code that would fulfill that vision. There was a magical moment when, on Thursday afternoon, Jason and Scott from the UX team – coders by trade who had found themselves in a non-coding position in our particular development project – merged in a totally organic way with the dev team to flesh out some of the UX that they’d been conceptualizing for the previous two days. That too demonstrated a kind of trust between One Weekers, where team boundaries were mutable when circumstances required it, and no one blinked an eye when two more people started committing code to the repo.

Much more to come, I’m sure.