Building a Process

As part of a new generation of leadership at Code for Boston my colleagues and I were charged with defining and building process for the organization. Some of this process was gifted to us via previous practice. Some of this process was thought out, and some of it was ad-hoc. Either way we thought we could be a better organization if we memorialize, communicate, and execute on our process.

Most recently we built a process for project intake. In our monthly leadership meeting we identified this need and decided to delegate the development of the process to a sub-committee of interested leadership members. People who felt strongly could be in the sub-committee while those who were not as interested in this particular process could sit out. As a rule we try and keep our meetings to 90 minutes in order to respect the natural attention span of attendants. In the meeting we brainstormed, discussed, and found agreement based on evidence and experience. We generated a document that was then shared and voted upon by the larger leadership team at our next monthly meeting.

What did we get for all this effort? First and foremost it made explicit the expectations by all the actors. We figured out that we needed a person willing to put in time to manage project intake. We made clear when and where leadership had to take a stance on a project proposal, eliminating the uncertainty around silence. Finally it gave clarity and certainty to potential external partners about when and where they could expect an answer to whether their project could be a part of our community.

The most surprising part of implementing this process is how much of a barrier filling out our Google Form is to proposers. Often people will on Slack or in person try and hook me or another leadership team member into a discussion about their project idea with an aim of making it an official Code for Boston venture. Despite informing them I am not empowered to make their project official and telling them they need to fill out our Google Form, many people still just want to talk about it and do not understand why their project cannot start next week. I am not sure why this is such a challenge, but my hope is that we are simply weeding out folks who would find other parts of running a Code for Boston project challenging and avoiding a bad fit.

Learning New Software Languages

I am in the process of reading A Swift Kickstart to learn the Swift programming language. Swift will be maybe the fourth or fifth language I am learning and so far I am enjoying it a bit more than many of the other ones I have tried to learn. Learning a language is about building the muscle memory around the words and syntax used to communicate in it. Many programming languages share similar concepts (like functions, variables, constants, etc.) and you need only map these concepts to the new syntax and conventions used by your new language.

The main thing I have learned from learning new languages is that good code can be good code in many languages and bad code can be bad code in many languages. More often than not the language itself does not impact whether the code is good. It is the skill of the author of the code that makes a difference. It is quite possible to write obfuscatory variable and attribute names in ruby as well as PHP or Python. At the same time I’ve rewritten beautiful VBScript code into Ruby with ease because the developer took the time to structure it in a way that was easily understandable.

I have yet to find a programming language I love as much as Ruby. Python’s significant white space frustrates me. I do not really enjoy looking at most PHP code. Javascript has improved lately but I find the fact that Javascript is always “improving” to be its own frustration. I did not even bother with Swift until it reached version four. Maybe I will learn to love Swift, maybe I will discover Go. It is fun to dip my toes in other languages, but more often than not they just cause me to better appreciate how great Ruby is.

The Baby Boomer Millennials Article

Someone shared this article with me today and I felt the need to respond in poem.

This analysis does nothing to undo our paralysis. The author tries hard to assign blame, but has no idea how to win this game. He can paint people with a large brush stroke, but has he even talked to regular folk? This was nothing novel; it was more of the same. If government debt is our frustration, Our solution must be innovation.

Live Streaming Events

Last night I helped present a webinar for folks in the Code for America network about live streaming their events. Most of what I learned about YouTube and live-streaming came from my friend Lon Seidman whom I helped film and edit with at CES a couple years ago. You can spend a lot of money on live streaming but ultimately the goal is to get a decent picture of your presenter and really good audio.

If you are using an iPhone you can get an inexpensive lav microphone and a long cord, along with a tripod and mount to record individual speakers. However you can also invest in some fancier equipment. The equipment I used included:

  1. Elgato Camlink - connects camera to laptop for livestreaming purposes.
  2. Alta Pro Tripod - to better position the camera
  3. Sony a6000 camera
  4. Zoom/gun microphone for focused audio
  5. MacBook Pro
  6. OBStudio
  7. Facebook Live

When recording I faced several challenges. The first was that the camera only transmits audio over HDMI when it is in video recording mode. Due to some EU regulations, video recording mode automatically stops on the a6000 after about 30 minutes. So I had to keep re-enabling recording mode. Another issue is that the a6000 does not recharge from its regular charging port while it is on. So having a backup battery or Sony’s official wire would have made it easier.

Ultimately it took a lot of tinkering to get to a setup that worked well and to understand the potential kinks. I strongly recommend testing your setup before trying to live stream for real.

Decoupling Myself

One of the biggest challenges I face on a daily basis, especially at Code for Boston, is trying to remove myself as a dependency from the organization. There is a difference between success because you are good at something and success because you have built an organization that is good at something. As Al Gore is fond of saying, “if you want to go quickly go alone, if you want to go far, go together.”

The hardest part of decoupling is effective delegation. As you try and remove yourself as a dependency you quickly realize that the vision in your head of what needs to be done does not exist in everyone else’s heads. Yesterday I put up some community asks to the folks at Code for Boston and after I put up those asks some members asked me about them. I then realized I had not given everyone all the information they needed to fulfill those asks. Delegation is not a free activity.

The individual hero is the opposite of organizational success. If you want to test whether you have succeeded in decoupling yourself you might try to step back when a big project is due. It can be challenging to step back and watch something you are a part of fail. However that failure is and should be a signal to the rest of the world that the team you are on is not resilient to your absence. In the words of a co-worker of mine, your team has a bus number of one.

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