On Fridays We Demo

One of the ideas I picked up from our colleagues at the NYC Planning Labs while we were at the Code for America conference was to build a ritual of spending one day a week where we show off our work. The idea behind this ritual is to give us something to strive toward. We want others to understand our work better so we are planning to open up our Friday demos to the rest of our department after we have done them a couple times. Instead of having big deadlines at the end of a project we can now triangulate our work towards these smaller goals.

The other upside of this ritual is it enforces some accountability. In order to demo we need to have software that is up and working on a staging server. So we no longer are putting off the deployment step until later in the software development cycle. It also gives us a gentle nudge to consider some user facing features and changes instead of focusing merely on technical improvements. No longer will we wonder what our co-workers have done all week.

The Monthly Core Team Meeting

As part of being on the core team at Code for Boston we have a monthly meeting. The core team meeting happens on a Thursday night. This regularity enforces structure and accountability in moving things forward. We share a Google document that allows any member of core team to propose an agenda item for the meeting. We enforce a meeting time limit of 90 minutes because any meeting that goes longer than that will suffer from lack of attention. We have a time keeper that enforces sticking to our agenda and a note taker that records next steps. This meeting is not brunch, we get together to focus on important things and we get them done.

The structure and rigidity of this meeting feels more helpful than hurtful. If a topic takes too long for this meeting it forces us to recognize the fact that it has earned its own meeting and give it the attention it deserves. We often reserve a balance of time (20 minutes) for discussions that go longer than we expect. We rotate the person who facilitates and the person who keeps time and notes. The absence of a single member does not hinder the ability of the team to get things done. Everyone knows the structure and keeps each other accountable.

Tonight is our monthly core team meeting and I am excited for all the new ideas and things we will get done. It is nice to have time to sit down with the rest of the core team and make decisions. It is also helpful to get from the others the download on what is happening in the areas of the organization they are focusing on and the feedback they are getting. The meeting may be real work, but it is rewarding.

The Benefits and Confusion of Slack

I do not remember when I became a user of Slack but it has been one of the more transformative applications I have used. The setup and design of Slack is sticky. Technical and non-technical folks generally do not struggle to onboard to Slack. It keeps things separated and has lots of tools for keeping track of conversations. Slack is not perfect but it seems to be the least worst solution to email and communication overload. However there are some Slack things I struggle to understand.

The first issue is private message overload. One of the promises of Slack is that conversations are more transparent. You can create channels (for free) that are titled with whatever they are about and invite people to these channels. However despite this handy organizational mechanism I find people often choose to simply direct message me (or each other) about things. This leads to conversations being lost in the DM ether. It also has the annoying side effect of firing off notifications for non-urgent matters. Surely the folks at Slack can let folks receive DMs but then only notify folks on the other end if someone @ mentions you in the DM. However this has not yet occurred.

The second issue is aggressive notifying. A huge value for slack is you can see what topic channels have been active or lit up and dip into them when you are ready to explore and work on that topic area. However Slack offers you the option to mention someone or send a notification to an entire channel if something is urgent or important. Unfortunately people are generally bad at figuring out if it is one of those things. The norms around notifications and mentions do not seem to be established yet and everyone has their own ideas about them.

The third challenge is channel overload. Once a slack team gets sufficiently large some users will protest if people have long (or slightly off-topic) conversations in a channel. The completionists feel honor bound to read the entire scroll back. I am not sure what most people think, but when I am working on Slack I usually try to read the entire channel only for my active projects. In general, unless a channel designates itself as important I treat them as mostly ephemeral.

The More Sleep Experiment

A year or two ago I experimented with quitting caffeine later in the afternoon to improve the quality of my sleep. This experiment was largely successful and now I rarely drink soda and I stop my coffee intake by early afternoon. Usually when I drink coffee I limit myself to two regular cups, if I have a third then it is decaf. This has greatly cut into my podcast consumption as I now typically fall asleep within 15 minutes of hitting the bed.

The next phase of this experiment is to inch my way from seven to eight hours of sleep. This was largely triggered by reading an article I found that suggested that seven hours might not be sufficient, but also it increases the margin of error for hitting my seven hour goal. The National Sleep Foundation recommends seven to nine hours for adults. If I aim for eight but hit seven or seven and a half then I am in a much better place than if I aim for seven and hit six. So far it is day two of this experiment and I feel better than usual.

Finding the Root Cause

Since September I have been battling with my cable Internet. About once a week the Internet dies. There is no warning, no error, no malfunction of the lights of the modem, it simply halts. Its death apparent by my modem’s inaccessible status page. A simple reboot brings it back alive.

Diagnosing a technical problem involves considering all possibilities from the possible to the probable. A good technician gathers facts, assesses the situation, and starts with the most probable thing and works from there. Unfortunately that is not how tech support worked with Motorola and Arris. They wanted me to exhaust all the possibilities. While the chances are not zero percent that my router was not working, it did not seem to be the likely possibility. Yet they insisted I direct connect my modem to my computer for a week or two to see if the issue presented itself. I had to stand my ground that this was not a reasonable solution given the need of my roommates to also use the Internet for a week. After months of technical support calls with them and Comcast I finally have a path forward. They agreed to ship me a replacement modem.

One thing I have learned from this is to keep better records. While Motorola Arris had a record of my previous calls, they had logged them into the model number of a different modem that I did not own. Secondly tech support can make or break the trust you have in a company. I will never purchase a product from them again. The process for them to intake my information for a replacement was arduous and their system went down during my call. If they are messing so many things up in technical support, should I be surprised that their product may be the thing that broke?

Follow Zagaja.com posts: RSS Feed
This work by Matt Zagaja is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.