Teaching, Targeting and Nudging at GiveCamp
I’m a coder. I cut code all day, every day. I learn new languages and programming paradigms for fun at night and on weekends. My favorite days are spent hacking in silence, with only a Skype window connecting me to other techies doing the same thing I’m doing: solving problems and making people’s lives more awesome with code.
I spent the weekend of November 8-10, 2013 contributing to the 2013 Grand Rapids GiveCamp and in two full days didn’t write a single line of code.
GiveCamp pairs local charity organizations who need technical assistance (building/revamping web sites, building donor databases, offering online organizational tools) with local techies who can solve those problems. Our team, made up of Joshua Kovach, Harrison Miracle, Mike Elston, Thomas Joseph Bush, Greg Braman, Matthew Pische, Keith Walsh and myself, did a ground-up rebuild of the website and donation engine for Haiti Needs You for Tim Ryan, who does multiple medical/dental relief missions to Haiti every year to help improve and extend the lives of Haiti’s “poorest of the poor”.
So what did I do in those two days? I fell into the role of project manager. I’d like to talk a bit about how/why that happened and what a dyed-in-the-wool coder learned from the experience.
Project manager? Wat?
How did this happen? Anybody who’s worked with me knows I don’t delegate: why would I voluntarily end up in a role where I can’t actually control anything?
It came down to three things: I have a big mouth, I’m very good at asking revealing questions, and I was not the best in the room.
No authority except what you take
This was an open-source project, at least in development style: flat hierarchy and a wild mix of skills and levels of expertise made up mostly of strangers. When Tim, the stakeholder, walked in the room, I started talking with him to make him feel more comfortable and find out what he actually needed from us, and I never really stopped. I had no right to dominate the conversation, but nobody else stepped up so I never stepped down. It’s more or less how I ended up coaching my son’s soccer team for three years. :-)
Nobody “needs” a website
Kathy Sierra is at the forefront of what she calls “post-UX” thought. Don’t think about how to make your app/site awesome, think of how your app/site can make your user awesome. I think of it as “nobody needs a website”: what they need is assistance improving their life in the real world. A website can be a tool to do that, but if it’s not, don’t bother building it.
That’s where I focused my questions. What does your organization do? What resources are required? What would help you level up? We burned it down to three things: collect donations, sign up volunteers and distribute information about the missions themselves (mainly via a mailing list). In that order. If these three things were as easy as we could make them, we had a shot at making a real impact on Tim’s efforts.
Find the important questions in order to get the important answers, and then focus single-mindedly on those answers. This was a challenge throughout the weekend, so we’ll revisit it later.
I was not the best in the room
I’m a back-back-end coder. Usually when people divide themselves into front-end/back-end, “front-end” things happen in the browser and “back-end” things happen on the server. What I specialize in is pure business logic. I build interfaces to external resources with disastrous APIs. I write heinous calculation logic and fiendish workflows. That’s where I live. Then I wrap a Rails app around it and put some front-end goodies on top. But I’m only truly powerful 100 feet underground where I’m digging with my fingernails and everything is pitch-black.
I don’t have all the Rails components and generators memorized. I have only a basic grasp of design principles. I test enthusiastically but know I could do so much better.
And I was surrounded by rock stars. People who used the gems, services and design tools we would need for this project daily in their paid work. There was none of the deep, dark, convoluted, one-off craziness where I can shine. If I’d tried to actively drive any of the features we needed, it would only slow everything down.
So I took a step back. In order for the experts to go heads-down and do their voodoo, I needed to stay heads-up and hands-off. That was hard, and humbling, but the project was undeniably better for it.
Teach, Target and Nudge
So what did I do for two solid days? The short answer is “anything to keep the features coming”. I can talk and I can improvise. I asked a lot of questions, begged favors from people I’d never met, and a bunch of other random things I have little to no experience at. The measure of whether I did these things well was if the rest of the team kept making progress.
The long answer breaks down into three things: teaching, targeting and nudging.
Teaching is one of my great joys. I’ve said I was not the best at any particular thing among the group, but as Alan Kay famously said “A change in perspective is worth 80 IQ points”. Just having someone looking over your shoulder is like having a syntactically-aware spell-checker.
Our backgrounds differed radically, so our strengths often overlapped with each other’s weaknesses in specific areas that would help us get “unstuck”, supporting Eric Raymond’s theory that “given enough eyeballs, all bugs are shallow”. Several of the developers were new to git, for instance (my favorite source code control system but notoriously difficult for newbies) which gave me the chance to explain things like how to create a tracking branch. It might have only happened a dozen times over the weekend, but every little bit helps.
It’s important to remember that getting stuck is emotionally difficult, especially in time-pressured, public situations where you’re supposed to “know what you’re doing”. Asking for help is an admission that you’re not perfect, and the social pressure to be flawless is everywhere in modern society. It shouldn’t be: none of us knows everything about anything. But we’ve all been there. To their credit, all the coders took each other’s input in stride, and developed more respect for each other as a result.
We had one member who was new to programming in general and not sure how much value he could add to the mix, but since there were a number of APIs to interface with in ways none of us had dealt with before, he spent a large chunk of time doing research that increased velocity once the coding effort for the component began. A side benefit is that he learned a great deal about APIs in general and looked at a lot of Ruby code. A win for both sides.
I mentioned at the outset working with Tim to establish how his ideal website would help his organization: donating money or service and keeping people informed about their efforts. We started our initial effort divided into groups along those lines in order to reduce code conflicts, but almost immediately we started saying “You know what we really need? X.”
My response was usually along the lines of “That would be nice, but if we had to go live without it, would the site still support the core features?” and the answer was almost always of the form “Well, if at some point he wanted to do Y, he’d need it.” The technical term for this is YAGNI: You Ain’t Gonna Need It and I think all of us succumbed to at some point over the weekend.
I followed up with “Why don’t we put that in the second wave and we’ll tackle it as soon as we get the main features launched?” and everyone was agreeable. Of course, we never got to the list, which I think everyone realized from the start, but it’s easier to swallow than just shouting “YAGNI!” The suggestions were all valid and should have been captured in the source code somewhere so they could be addressed in the future, but I think we dropped the ball on that.
To keep my courage up I mentally repeated the mantra from the trench scene in Star Wars: “Stay on target… Stay on target!” Of course, that pilot got blown to smithereens, so it’s probably good I didn’t think the analogy all the way through. ;-)
This is one area I always struggle with and I fell down multiple times over the weekend. I wasn’t anybody’s “boss” and where there were conflicting opinions (some of them on fairly-abstract coding architectures) I let the “Nope. That’s wrong” slip out before I converted into the more-respectful “I think we might get some other benefits from trying it this way.” One of my personal blind-spots is letting my passion for the technical subject blind me to the fact that these are human beings I’m dealing with and they deserve respect and consideration. The old adage “pick your battles” often translates perfectly as “don’t be such a control freak”. There’s also a world of difference between a nudge and a push.
I did better during the multiple occasions where someone would throw up their hands and say “Looks like you can’t do that” with respect to some external resource we couldn’t control. By not just accepting that at face value but engaging the whole group in coming up with creative paths around the obstruction, we managed to beat almost every one.
Another area I constantly worked on was getting people into compatible pairs, even when they felt confident of handling the problem on their own. We’ve found such benefit in pairing during our monthly Ruby training that I knew even if the technical benefit wasn’t obvious, the effect on the team dynamic would be worth it. Plus it meant no one felt underutilized or began work on a “second wave” feature “because I don’t have anything else to work on at the moment”.
I can’t in fairness end this without talking about fear. I worried constantly all weekend. I worried even the three features we’d committed to were more than we’d get to in the alloted time. I worried that the decisions I lobbied for would cause more trouble than they were worth. I worried that all the “contributions” I thought I was making were secretly alienating the entire team and they were all whispering “when is Loud Mouth going to go home so we can get some work done?”
In the end, we did hit the deadline and everyone was still speaking to me (we even drummed up more interest in our Ruby training), so I sincerely hope none of those fears had a basis in reality. If they did and I was too thick to notice, I apologize. In either case, I spent a lot of time and wasted a lot of energy wondering. Imposter Syndrome appears to be widespread in our industry and probably many others, so if you experience this too, you’re not alone.
To be honest, after the first night I was so nervous I had already caused irreversible damage that I contemplated not even returning. I came back anyway because I had committed to helping a worthy cause and I owed it to Tim to be of any benefit I could, even if that was just undoing the damage I’d done the first night.
It didn’t turn out that way: the second day we really got our feet under us and everyone showed a passion and work ethic that was infectious. By the third day, they were locked in and turning out features at a mind-blowing pace. We demoed along with everyone else at the closing ceremonies and Tim seemed very pleased with what we’d created. The updated site went live less than 24 hours later.
When Tim and I shook hands and said goodbye, I expressed my final fear. I said, “I hope the website helps you. I hope it brings in more money and new resources and spreads the word about your organization so you can do more good in the world. Because if it doesn’t do that, then we’ve failed.”
I sincerely hope that fear proves as groundless as the others. We did our best. And Haiti Needs You.