When the team takes on a life of its own

The longer I've been working with this team, the more and more I am so impressed with them.  One of my favorite things is to see people take ownership over the project, doing things by themselves without any prompting of others push the project forward.  

Last week, Liz created an amazing onboarding form for new members of the team.  One of the problems we face at our Code for DC meetings is having a lot of new folks show up asking how they can contribute.  It can take 30 minutes or longer to get someone's environment set up to start making contributions, plus giving them an overview of the project goals and walking them through the current application.  The onboarding form Liz created guides new people through a few steps on how to get ramped-up on their own.  We're going to give it a whirl at the next Code for DC meeting.

Screenshot of our new onboarding form for new members

Screenshot of our new onboarding form for new members

This week, one of our new members pitched-in by creating a public-facing page for our project.  Previously, it was wrapped into our demo application, but this new page gives us a very clean way to communicate what we're doing without it being mixed into the application that is ultimately going to be used internally by Bread for the City.  Check it out the new page!

Maintaining volunteer-developed applications

Yesterday, Stacey, Andrew, I met again to make a final list of the things that we want to accomplish so that we can start to pilot it in the weekly Housing Access Program workshops.  One of the biggest choices we had to address was where do they want all of the applicant data to be stored?

If we stored all of the applicant data with the web application, then we can get them started using the application right away.  If we stored it in their Salesforce instance, then it would take longer because they would need to modify their Salesforce objects to represent the fields in our online housing application.  After we reviewed the pros and cons of each approach, we decided that we'd store all of the data in Salesforce.  Salesforce would act as the single place that case workers could get data about a client, be it for housing, legal, medical or other types of reasons.  In a way, I was relieved because it meant that the app didn't need to be the system of record for such sensitive and important data.  The app will still be used, however, to process client data into forms and to even provide anonymized reporting on Section 8 housing demand in DC.

One question came up that I am mulling over still.  That's whether or not we should adapt the app to write data back to Salesforce.  They really love the forms we created (Jeff, that's a huge hat tip in your direction!), so they would like to do all of the client data entry in our app and then save everything back to Salesforce.  While technically possible, I am also trying to consider the longer term implications on maintenance.  Having data entry in the app means that a developer with knowledge of our code will be making the changes, for example, to add new fields.  Needing to depend on developers outside of Bread will mean that they will always need to wait for changes to be made.  That the developers are volunteers means that this wait could take awhile.  Whatever we decide, what I look forward to are the lessons that we can take from this project and apply to other civic-technology projects.

Sneak peak

Here's a sneak peak of what the affordable housing app looks like.  Today, I implemented the ability for case workers to search for clients by name.  Previously, the app would force you to scroll through names.  That works well with our test data, but Bread for the City says they have close to 100K clients.

Screenshot of the affordable housing app being built for Bread for the City.

I'll walk people through the full application after I put some more time into tuning it up.

So proud of our team

I love these guys!  Twice a month, I get to spend 2+ hours with these guys at Code for DC. We work on PDFs to make them fillable, we develop essential features for our app, we test and debug, and we onboard and welcome new members to the group.  

The affordable housing group gathered at Code for DC on January 14, 2015.

The affordable housing group gathered at Code for DC on January 14, 2015.

In the beginning, there was a small, core group of us, but usually a lot of people who showed up for Code for DC and then we never saw them again.  Overtime, we've grown the team one dedicated member at a time.  The group now has people who have been with us since the beginning, for a year, for 6 months, to only a couple of months.  Tonight (fingers crossed), I think we picked up another developer.

A lot of what I am learning as I work with this team has helped me during my day job at Socrata as well.  How do you match people's skills and interests to the project?  How do you enable people to contribute when you're not there?  As you scale the team, how do you find ways to empower other people to lead?  How do you communicate the value of your project to different people in the community?  Who are the right people to engage to make sure your project is serving their needs?  

Finally, I wanted to give a big shout out to Jeff Runningen, not pictured here (but was on Slack!).  Jeff moved to NYC a few months ago to work at Google, but despite living in a different city he has continued to devote many hours of his free time moving this project forward.  He has been absolutely essential.  We miss you, Jeff!

We still need the printed paper

This morning, I kicked-off my sabbatical by heading to Bread for the City's offices in NW.  Stacey, the innovative case worker who is shepherding me and Code for DC through the affordable housing world, met me in the lobby.  

Stacey was carrying a printed newspaper.   

"I just saw this on the way in," she said, pointing to a rental listing.  "A building just opened up a waiting list."

Listings in the printed version of the Washington Post are used to find newly opened waiting lists.   How can we better get this information to people?

Listings in the printed version of the Washington Post are used to find newly opened waiting lists.  How can we better get this information to people?

We are just scratching the surface.  When I think about what I am doing during my sabbatical and what Code for DC has been doing over the past 1.5 years, we are helping just one piece of a much bigger problem.