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.
One issue I have been thinking about is applying user centered design in situations where target users do not have the problem that is trying to be solved. For example if your goal is to build a software program to encourage people to reduce their energy usage, but the users do not need or want to do that, then does user-centered design make sense as the approach to solving this problem?
My guess is the answer to this is no, or rather it turns out that the project is focusing on the wrong user. If users do not need or want to reduce their energy usage, then we do not need to solve this problem for them. Instead the rationale thing to do is reframe it as “how do we help advocates persuade people to reduce their energy usage”. From there we can open up a world of possible solutions.
I encounter a similar issue with my vote.ctnewsjunkie.com platform. Candidates get tons of surveys so we sometimes have a challenging time getting them to answer our questions. However we can think about and try and fix other problems through our project. For example we provide an online presence and social media exposure that they do have, and then they are more likely to answer the survey if we solve these problems.