I spent the weekend at Code for America’s Brigade Congress event where we enjoyed programming related to running the volunteer program that Code for America administers. We covered a large swath of topics from fundraising to diversity. After helping run a brigade for over a year I have come to realize that brigades face two types of problems: figuring out how to do something, and then executing on doing it.
For the most part the biggest barrier to more success we face at Code for Boston is not on the how side, but on the execution side. This problem can be divided into two parts: lack of desire and lack of time. The first problem is difficult to solve. Either you need to modify the activity to make it fun, or make not doing it so painful for a person that they choose to do so it despite not wanting to. The second part is easy to solve because you just have to choose to not do something else. Unfortunately it is also hard to solve if you cannot or do not want to stop doing those other things. The only other solution is to make it take less time.
On Saturday I attended the Public Interest Technology Summit at Harvard Kennedy School. About eighty people gathered to learn about and discuss issues related to public interest technology. Public interest technology is the term the Ford Foundation is using to describe the field that many of us currently call civic tech. It was a worthwhile summit where I networked and learned a lot.
One session I attended was facilitated by Nick Sinai and focused on how to get students into the field. Students involved in the group Coding it Forward were there to share their experiences and how their program worked. It was helpful to get the experience of college students but I was disappointed to learn one of the founders of the group chose a job with Google instead of government, as rational as that decision was.
Another session was focused on David Eaves maturity model for digital services groups. The session emphasized that the product of digital services groups is culture change and there was a focus on user centered design. User centered design is the design and management side of what software developers might know as agile. Working together these two methodologies allow teams to deliver products that do a better job of fixing problems more quickly.
Almost a year ago my friend Mandie asked me to do the BAA Distance Medley with her. I roped in another friend and as a result signed up for my first half-marathon. I had never run a half-marathon before and was not sure how well it would go. After a year of training including a month of getting up at 5:30 a.m. to run before work on Tuesdays, I made it to a place where I was ready for this challenge.
Training was not without its challenges and sacrifices. The blistering hot summer made running more brutal. Some days I only made it half way before giving up. Longer runs and more sweat required extra tools. I got a new water bottle and gained a new appreciation of Gatorade. I found a sweatband to keep the burning mix of sunscreen out of my eyes. My sweat and the rain destroyed three pairs of bluetooth earbuds. When the distance is far, minor discomfort can derail major progress.
Running this race has taught me much about grit, dedication, and following a plan. Not every run was my best. Sometimes there was rain and headwinds. I had to eat and drink based on how food made me feel instead of how it tasted. When it felt like I could not go any farther, I persisted because I knew that doing so would make it easier next time. I kept my eye on the North Star and followed the plan to get to it.
Yesterday I ran some numbers about the impact of my group at MAPC and posted them on the wall:
If you want to put your own number on this wall, you can apply to join us!
At Code for Boston I keep a backlog of projects that are ideas for the organization. Many of these tasks are not exciting or interesting to a large group of people, but they are valuable ways to move the organization forward. Usually I try and delegate these tasks to folks with varying degrees of success. Recently I delegated a task and it worked better than I expected.
The project is still in progress so I am not going to share what it is. However I do want to share the surprise of how it is happening. The first step was to let Code for Boston know what I was planning to do. Then to say I was going to start doing it. When I did this, people offered to help. I asked some questions about their background and it sounded like they were skilled at things, so instead of continuing the project I offered to give them control. I told them the major idea behind what I wanted to do, and then asked them to guide me.
Recently I saw a rough draft of their work and it was of much higher quality than what I was likely able to produce. This made me both proud and excited. Suddenly I found a new non-project way to engage my members in helping the organization. They are doing something they enjoy and are good at. As a result Code for Boston will be better off.
This is a story about converting potential into kinetic energy. Despite the fact a giant backlog of important things exists in Code for Boston world, people do not often seem interested in the backlog. The key catalyst was telling folks that a project was happening. At that point is when they became excited to contribute.