The federal government has an interesting group called the Office of Evaluation Sciences that works on conducting randomized controlled experiments around interventions to improve the public welfare. I first became aware of this methodology when I worked in politics. Sasha Issenberg chronicles the use of this method in his book The Victory Lab and many of the techniques used by Democratic campaigns have been influenced by an organization called the Analyst Institute. I believe this sort of rigorous evaluation is important for deciding what is worth doing as an organization.
The exciting part about the studies posted by the Office of Evaluation Sciences is they include the flops and failures in addition to the successes. When I worked in politics I mostly learned about the successes or the idea that a direct mail piece would only move the needle a small amount. Doing a randomized controlled trial and concluding that there was no impact can free folks to stop spending resources on things that are not effective so they can try new things. I wish there was more of this.
An interesting piece of background in WIRED on the Boston school bus algorithm:
Optimizing the algorithm for greater “equity” also meant many of the planned changes were “biased” against families with privilege. My view is that the fact that an algorithm was making decisions also upset people. And the families who were happy with the new schedule probably didn’t pay as much attention. The families who were upset marched on City Hall in an effort to overturn the planned changes. The ACLU and I supported the activist parents at the time and called “foul” on the school system and the city. Eventually, the mayor and the city caved to the pressure and killed off years of work and what could have been the first real positive change in busing in Boston in decades.
The interesting part of the article is how the City of Boston actually was thoughtful in how it implemented the algorithm and involved the community, but it did not prevent the backlash. I was lucky in the program I implemented where backlash around the algorithm was almost non-existent. Most folks were happy because in addition to the algorithm we improved the job selection process for young people. I saw first hand how thoughtful the City of Boston tries to be when implementing these programs, and am glad the folks at MIT got the chance to tell their story.
Over the past few weeks I have been doing lots of traveling. I went to North Carolina for Code for America Brigade Congress a couple weeks ago. Then over the past two weeks I was in London and Spain for vacation. While these are fun and important trips, they also infringe on an important part of my routine. On Sundays I usually reboot by going through all my to do items and reconciling my finances. My inbox is cleared, groceries are ordered, and I ready myself for the week.
The weekly reboot comes from the weekly review idea from the Getting Things Done methodology. David Allen’s Getting Things Done book had a moment around ten years ago where it took off. I do not follow every aspect of the methodology but keeping a central to do list, working towards inbox zero, and making sure to write things down are central ideas to keeping my head around everything I do.
Vacation itself was also a reboot. By changing my routine and where I lived for a while I could approach current projects with a fresh perspective. I was mostly successful at getting my work and Code for Boston projects out of my mind so I could enjoy my trip. I missed some of the things in my routine like writing for this blog in the morning, but clearing my mind was worth the hiatus. Approaching things with a clear head helps with both judgement and creativity.
This morning I tried the Swift Playgrounds application that Apple offers for free to its iOS device users. A friend suggested I try it as a way to learn Swift. I initially ignored this tool because it seemed to be aimed at people who did not know how to code at all, but Apple did a really great job on this app. You can download a series of well designed tutorials that teach you not only the basics of programming but provide you with content for augmented reality and machine learning development. I even found a GitHub repo with interesting third party playgrounds. This is a much more fun and interactive way to learn coding material than the usual book method.
In organizations there are two types of communication that people can engage in: synchronous and asynchronous. I find synchronous communication to be best for trying to get agreement or dig into beefy topics. Asynchronous communication can often work for everything else. However the challenge with asynchronous communication is it is easily ignored. This leads to needing synchronous communication for things that would otherwise work asynchronously. Since synchronous communication is massively more expensive, this slows down progress.
Unfortunately the asynchronous communication style will rarely be effective with people who are only used to synchronous communication. This can lead to two issues. The first is that asynchronous communicators can fail to engage folks who desire synchronous communication. The asynchronous folks might be viewed as distant or aloof. Second, the asynchronous folks might be view synchronous folks in the same way. You can quickly see how translation is hard.
The solution to succeed is to help everyone learn to be effective in both modes. There are advantages and disadvantages to both styles, but you should not limit yourself to carrying the burden of adapting. If a a team is to grow and succeed it needs to proficient and effective in both styles. A person who is proficient at both of these methods can serve as a translator between the two types of people. They will also be more effective in working with a larger variety of people.