DECISION: New members join a project on the 2nd week

[plocket]

Why

The majority of participants expressed that bringing in new members is disruptive to their meeting process and most new members don't return for a second time. The disruption feels to them like a significant amount of wasted time and effort.

How

1. The orientation process should last the entire night.
2. Possibly change orientation process so that new member orientation begins an hour in (8pm) (some disagreed with this)
3. Project representatives come out around 9pm, discuss project and say, if you want to be part of this project, do this homework by next week.
4. Members then start the next week with their chosen project and do not participate at all first week.

Proposal History

01/23/20

1. Proposed and voted on, but through a thumb vote (not fist-to-five)
2. One project expressed its ability to handle onboarding each week. Possibly allow teams the flexibility of either assigning homework or onboarding that week.
3. Vote: 4 / 2 / 1 (for/neutral/against)

[plocket]

I'd be interested in hearing how that one group has handled new members. If they've found ways to make it an advantage instead of a disadvantage, maybe there's something other groups can learn from that.

[thadk]

I was the vote against this decision. I said that I felt we used all the flexibility that the existing model afforded and would not change it. Below is a collection of the techniques our team used to "plug in" new members in context. I'd be happy to distill these out of the context if anyone finds this narrative useful.

The rarest skills perfect-match may never be available the second week if you give people a bad quiz/homework that doesn't align with their meaning, their reasons for coming, and availability. If you let them, a single senior developer with your stack can completely restructure the app in a 2 hours period, making up for months of technical debt built up while you better developed the understanding of the problem.

See also How to Help Someone use a Computer (1996) "Knowledge lives in communities"

The Teardown:

I had the luxury on Windfall that our goal was well constrained and research was always oriented in a single direction: better user experience for retirees, and especially windfall-elimination affected retirees. The possibility space was still large but you could characterize the math on one whiteboard and the jobs-to-be-done by the app in retiree's lives on another one.

These were available to new people but eventually the app's introductory text copy and my pitch was so clarified that people stopped asking to be walked through them when onboarded. They were able to focus on either the coding of algorithms, the coding of frontend/UX or the interaction with the policy. Eventually the coding of the frontend/UX were the main thing we were requesting people on but we still welcomed people inspired by the policy.

1)When people expressed interest in the math: At first, this was the most important.

• [Added Saturday Jan/25/2020 Edit:] People took parts of the math whiteboard sketch to calculate retirement benefits to figure out and replicate.
• I'd kind of round robin around the room to each of the people working on this and make sure they were not blocked.
• If they were blocked on understanding, I'd answer or escalate to Anne, the project champion.

How it went (the math): I did a lot of prototyping myself in Observable after we had some essential algorithms figured out by the mathier people on the team. I also had to rewrite some code from a couple folks less familiar with javascript who had written in idioms of Java. In the end, we were able to make some core compos-able functional-programming style algorithms to describe all the math logic of the app and continue using them as a library in the front-end.

2) When people expressed interest in the frontend/UX:

• I would link them to Harlan's mockups in Figma (or my own ObservableJS mockups early on) and use that to convey what was not yet meeting those ideals.
• We'd have a dialog to understand their skills in React and either:
  • do mob programming on a main screen if they were not so confident overall or if there were UI changes that everyone needed to be synced about (some experienced volunteers did go heads down separately: they were well engaged in a challenge),
  • wholesale task out large parts of the design implementation if they were very experienced in task at hand ("rockstars"),
  • or subtask out new incremental parts of the design if they were just coming on.
• I would round robin to clear blockers constantly throughout every evening if we were not doing a single stream mob programming effort.

How it went (frontend/UX): Almost no one who worked on this stayed for more than 12 weeks over the course of the year because of life. Still, as so many people did contribute enough to string together, it worked. At first, all of our skills were imperfect on using Gatsby and CSS-in-JS, even though I know JS well. Slowly we picked up steam bit by bit with the TSX/CSS-in-JS/Gatsby/Netlify template that one senior volunteer had nicely dropped on us and left after 1 week. A few folks ("rockstars") came on and explained CSS-in-JS to us and demonstrated with PR's. This made the people who did happen to stay longer, better. Core team helped us add tests. Finally at the last few weeks we were able to clean up our code and use TSX to reduce bugs we'd struggled with all along between functions.

Sometimes I gauged people a little bit too harshly in the moment and gave them tasks that were too easy and they finished them and didn't come back. Other times people got very frustrated when a task was too heavy and it took a real struggle for them with lots of gaps. My sense of these issues improved only somewhat.

The introduction of (20 years of design experience) Harlan's design unfortunately alienated our previous more junior designers because of his limited availability for active critique and buy-in when they were also around (we've spoken about this.) The hard part is that his time would not have been efficiently spent on a ambiguous design earlier in the project without a coherent end-to-end problem statement. So the junior designers work was absolutely needed. I don't think we conveyed this well enough.

3) When people expressed interest in policy:

• This was the biggest effort at first but dwindled like the math efforts.
• At first to establish common understanding for the math, we'd have these discussions together.
• Later, Anne would take them into a separate room and either talk about policy with them using a powerpoint and present challenges like finding a partner, and then rejoin main room once the context was clear enough.

If Anne wasn't there I would show people the 22 pins on the Slack channel, especially a brief slide presentation Anne had made, and offer whatever UX/Policy questions were pressing. As product manager, I still understood and kept track of 70% of the policy stuff from Anne but it was usually not a good use of time to convey this.

Eventually:

• She'd work through the ways the jobs-to-be-done by the app were serving users or could be improved by user experience changes.
• Sometimes this was easiest by reviewing Quicktime screencast videos or audio of users using the app from town halls.
• We also had a few "rockstars" in policy that used the jobs-to-be-done framework to help us think about risks and resolutions the app might enable in its broadest scope.

How it went (policy): At first this was a lot of Anne retrospecting on her own experiences as a caseworker for Social Security and conveying them to us. The first break was when our other member, who is nearly retired, contributed her earnings history. This gave us a point of reference along with the examples we found on the Social Security website and start thinking about what the inputs and outputs for the math and front-end were. We have not succeeded in identifying a partner besides MA-06 Congressman Seth Moulton's office (yet). We have talked to many retirement centers and advisor volunteer organization to make sure the app is useful.

Overall for the first 2 months I tried to operate on a completely consensus mode. I wanted people to begin tasks that matched with their reasons for coming to CfB, with just coaching on technical issues. It became clear that with a) the turnover of volunteers and b) somewhat junior experience level initially of the folks who persisted, and c) the rate we needed to move since Anne was leaving at end-of-year, that we needed a more active product manager. I started being more explicit about requests, and technical decisions, but still tried to listen carefully to match background and motivation and for where awesome rare capacities randomly appeared from new volunteers, resulting in above approach.

[thadk]

Besides those of us who were diligently learning stuff as we went and coding it, six milestone pieces that made this project work better were from volunteers with rare & aligned skills from outside: 1) The Community Connect volunteer who appeared in week 3 and dropped the Gatsby template for us and a quick wireframe. I recognized it as exciting technology and other people agreed to the wireframe. Before then, the group was trying to build it in SQL/Python which wasn't really ideal for privacy preserving. 2) My ObservableHQ javascript prototype (think of a spreadsheet) to make the math algorithm development with more individualization; cheap interactivity; and visual feedback. 3) ObservableHQ ended up being a distraction to the frontend/UX by month 5 because it was too unfamiliar to new developer volunteers and a bit fragile: a single-visit senior engineer convinced me to extract out the functions and just use vanilla Gatsby. 4) Harlan's design as a senior designer to recast what the team had learned elegantly. 5) a developer from Community Connect with experience on CSS-in-JS to implement Harlan's design quickly and teach us 6) a developer's explanation of TypeScript and demonstration of how to use it to clean up our state management. [Many additional pieces on the policy side were essential including the congressional partnerships, Anne's relationship with the Congressional Research Service, her experience on the topic, her standing in her office, etc etc etc]

The point of this is just that capturing and locking in progress on understanding & the problem statement is important: I think refactoring your pieces to improve your systemic presentation of the problem statement when a better formulation appears is a fantastic way to do this, even in the existing structure. This way, you're building institutional memory into the most faithful parts of your infrastructure.