Software In Person

Distributed software-making organizations (companies, open source projects, etc.) generally make time to get people together, face-to-face. I know; I’ve organized or run hackathons, sprints, summits, and all-hands meetings for open source projects and businesses (and if I never have to worry about someone else’s hotel or visa again, it’ll be too soon).

Engineers often assume we don’t need to explicitly structure that time together, or default to holding an unconference. This refusal to reflect on users’ needs (in this case, the participants in the event) is lazy management. Or event organizers fall back to creating conferences like the ones we usually see in tech, where elite men give hour-long lectures, and most participants don’t have any opportunities to collaborate or assess their skills. Still a bad user experience, and a waste of your precious in-person time.

Why do you think you’re spending hundreds of thousands of dollars holding hackathons, sprint weeks, and conferences? And how could you be using that time and money better?

Our defaults

Photo CC-BY Sebastiaan ter Burg, filtered.

Companies and open source projects often plan sprint weeks and hackathons in a fashion that could generously be called laissez-faire, or ungenerously called procrastinatory. For a few months, conversations glide to a stop with: “that’s a little sticky; how about we try to do it at the next sprint?” But too often, no one stops to count, to see how many TODOs the team has casually added to a burgeoning list. And then, at the event, we end up working on what’s on our mind in that moment, instead of making the long-term investments we can do best when we’re in the same room.

Because boring, irrelevant presentations stink, and because we want to empower event participants to work on what interests them, engineers often revert to an unconference format (usually without the formal structure of Open Space Technology, where unconferences originated). But sometimes an unconference is the wrong choice, especially if some of the participants don’t have enough social capital or implicit knowledge to explicitly ask for the sessions they need. If you are planning an event for people who already know and trust each other, and are good at public speaking and collaboration, and are experts in the field, then an unconference might work! But for newbies who are learning not just a new skill, but a new way of thinking? Give them a more familiar structure.

Investing for the long term

it’s hack week, and you know what that means! rockstars generating technical debt that the rest of us will have to clean up for years yayyyy

— zack (@meat) August 17, 2015

I’ve seen many projects and many technologists only call a face-to-face convening productive if engineers wrote and merged working code. It’s easier to persuade engineers to come to “hack week” than to “meetings week.” In the short term, that commit log feels good; in the long run, software organizations need to use rare high-bandwidth communication opportunities to spread knowledge and make hard decisions, even at the cost of the immediate satisfaction of a `git push`. Plus, our project-based approach to events too often calls the event over once everyone’s plane has landed. We don’t consistently follow through to keep momentum going: a presentation on automated testing frameworks won’t get the dev community using it unless code reviewers add a check for tests to their checklists. 

For those of us who are used to religious communities, a more balanced approach is familiar and suggests lessons for our technical practice. When I was a kid, my mom and dad prayed in front of the kitchen altar daily, and we practiced our Hinduism in our daily actions. We welcomed guests, worked hard, practiced kindness and charity, learned and taught. And phone calls, letters, emails, and visits kept the threads of community alive in between the big get-togethers. Every so often we went to temple or rented a high school gym for the big celebrations. We reaffirmed our values by performing rituals together, shared food and chitchatted about our shared problems and little victories, swapped tips, gave awards.

What can we learn from this? We need both execution and alignment. We need the daily practice, the little chores invisible to each other, the habit of hygiene, and we need the rare get-togethers, the big convenings where we see each other and help or honor each other, the ones that are a task just to put on. So, I agree with “Why I don’t like hackathons, by Alex Bayley aged 39 1/2“; if your strategy for “getting things done” or “getting new people involved” starts and ends with “hold a sprint/hack week/hackathon”, then that’s all temple and no kitchen altar. And face-to-face events are better for quality time with other people’s faces than for quality time with IDEs.

Beyond “hack a lot”

Photo CC-BY Guilherme Tavares, filtered.

 So what strategies work for in-person technical events, outside of unconferences, lecture blocks, and “let’s just hack”? Start with goals! That way you can do a retrospective to make the next one better, and key your follow-up off those same goals. For example: at one hackathon, I set aims including training community members on specific tools, getting participants from more diverse backgrounds, holding social events that helped build relationships, and keeping a certain number of new cross-pollinating community members three months after the event. I suggest you limit yourself to, at most, a few foci.

Don’t plunk the responsibility of the event on one admin’s shoulders; give your organizers backup and don’t burn them out. And, of course, make sure people feel safe, by publicizing and enforcing a genuine code of conduct.

So: plan activities, and make sure you set aside time in the weeks and months after the event to follow up and see what participants need to consolidate skills and achieve new goals. But what activities are good bets for your sprint?

This is a great time to meet across disciplines. For instance, tech writers can interview designers, engineers, and testers to get raw material and learn what needs documenting. And sysadmins and developers can work together to run and automate finicky deploys that require both ops and dev domain knowledge, or share their needs and brainstorm fixes. (A big showcase deploy can be a morale-raiser, but watch out; don’t save showcase deploys or setup work for the last day!) 

More emotionally skilled engineers understand that face-to-face time is a good opportunity to talk through disagreements. While “DisagreementCon 2015” isn’t necessarily the most appealing draw for the larger community, you can sell it as “let’s hammer out what we want in the next version” — participants can add to the wishlist of features before the convening, and then agree to cull items in person, where it’s easier to respect people’s feelings while negotiating.

Similarly, face-to-face chats are great for assessing and committing to changes in your project’s core architecture, especially since diagrams and high-level explanatory conversations aid visual or pattern-based (“intuitive”) learners who are often ill served by asynchronous text. And key committers can, well, make personal commitments to their goals.

As Jo Freeman noted in “The Tyranny of Structurelessness”, informal governance structures that people are hesitant to acknowledge too often turn cliquish and reify dominant biases. The meritocracy myth too often stops us from addressing governance questions, but you can use in-person meetings to work around this taboo by scheduling sessions around “breaking bottlenecks” or addressing specific pain points brought up in recent retrospectives.

Grow your people

Photo CC-BY solarisgirl, filtered.

Open source software, and the tech industry generally, cater to some kinds of learners and not others. Distributed software organizations especially are set up to help those who learn via text, feel safe when learning by making successive mistakes, and prefer learning from live codebases to learning from documentation or textbooks. If you want to get the most out of your team or community, set up your events to activate and grow people who learn in different ways.

Savvy technologists know that managers use hackathons and sprints to informally interview candidates for new jobs or promotions. Try explicitly encouraging people to talk with you about how to grow in the organization, and personally inviting those who seem to suffer from impostor syndrome. As Dr. Anna Fels writes in “Necessary Dreams”, ambition is a combination of the urge to be a master at a domain, and the desire to have that mastery recognized. Create accessible, discoverable channels for that ambition, and recognize that mastery.

Sometimes that takes the form of titles, acknowledgment, delegation, and training. For instance, in-person meetings are good times to officially promote developers to maintainer or core committer status; you can give them “the keys to the kingdom” in public, to the applause of their community. And to make sure candidates for maintainership actually feel confidence in their own code review skills, use this time to skillshare. Let a candidate shadow a current maintainer and watch code being reviewed, rejected or merged; have the maintainer think aloud to demonstrate how they make decisions. Or use a structure like a code retreat to help everyone get better at pair programming, test-driven development, or some other difficult habit.

Similarly, follow the advice of multiple case studies in Making Software: What Really Works and Why We Believe It (edited by Andy Oram & Greg Wilson) by running a feature interview or code tour. Have one developer interview another, in front of a projector, as they walk through one of your gnarlier components and talk about what it does, why it works that way, and why the authors made the decisions they made. This particularly aids pattern-based learners and mid-level or junior developers, who frequently flounder when they don’t understand the design rationale behind a chunk of code. A good feature interview demonstrates why and how a big system works by helping you see all the problems that the components solve. (For further insight here, I recommend Mel Chua’s introduction to educational psychology, especially the the parts about visual learning styles, spiral learning, and the Dreyfus model of skill acquisition.) 

Hackathons and sprints are also good opportunities to get everyone set up with fiddly new tools, like Docker or git, with hands-on workshops. You’ll reduce demoralizing time spent alone in yak-shaving and dead-ends of troubleshooting. It’s easier for us to help each other in person; diagnostic information emerges most easily in conversation with a generous interlocutor, whereas many fora online where people ask for help would prefer that help-requesters’ initial speech act be delivered with the concision and throughput of a paramedic running alongside a gurney.

Setting yourself up for success

User experience means paying attention to users’ needs, making choices to better suit those needs, and iterating in response to what you observe. The suggestions above will probably help you; what’ll work even better is watching, listening, improving, and seeing beyond both the stifling extremes of “lectures and lunches” and “headphones and hacking”.

Try going beyond the default event structures and activities to make your next sprint, hackathon, or conference a long-term investment in the team that makes your product.

Thanks to Gus Andrews for asking the question that sparked these thoughts, and for taking notes on my initial answers.