Brian's Opinions

The different ways to work on bikes and get things done at the Bike Kitchen are pretty much endless. Here is an incomplete collection of how I do things with some explanations.

If you don't know, ask!

'nuff said.

Cables and Housing are the last thing to go on the bike

Cables and housing must be cut to fit your bike. Their lengths depend on the components that you choose. Accordingly, you must choose your components before you trim and mount your cables and housing. Also, you don't want to be cinching down your cables in their anchor bolts any more than you have to. The reason is that every time you cinch down the cable you damage it a bit, and if you cinch it down enough it will fray and break. Finally, cables and housing often get in the way of working on your bike. So, before you string up your bike, dig up all of the parts. If you have any doubts that the parts are compatible, ask somebody.

The only exception to this rule is bar tape on your road bar. The reason for this exception is that the brake and shifter housing may be routed underneath the bar tape. Also, especially if you use light colored bar tape, the tape remains clean.

Embrace the junk box

Occasionally, an ambitious volunteer let's out a proud sigh of victory upon filing every nut, bolt, and spring from the junk box into a neatly labeled drawer. The junk box is declared a thing of the past. Then one day later the table around the drawers is doused in a spilled soup of nuts, bolts, and springs. A not-so-ambitious volunteer (perhaps me) finds the nearest box of a suitable size and sweeps the junk into it, re-introducing the loathed junk box. The junk box is an important and healthy part of the shop. Embrace it.

Now, if you want to assign a meaningful junk box remediation task to a volunteer, have them dig out specific parts from the junk box. For example, it's really nice to have a drawer with nothing but 5mmx0.8mm bolts. So have a volunteer create one (with a label!) and populate it. This way, the drawer has a chance of survival because it has a label and a critical mass of parts. It's also really useful for people who need 5mm hardware.

How successful systems are built and maintained at the Bike Kitchen

It's pretty frustrating to go about making a new handle bar rack or a new home for the files, only to come to your open hours shift to find everything all out of order. You don't have to spend much time reading the BK mailing list to hear this frustration expressed. Below I summarize a few of my own observations and techniques for making systems that really work.

Take your time (if necessary)

The bike kitchen is an organic place and it grows slowly. You've got to be realistic about how long it takes to do things. We have meetings every two months. If your proposed system requires lots of buy-in from the rest of the staff or a good chunk of money (i.e., $500+), expect to spend some time incorporating (or otherwise addressing) feedback.

That said, if you have a simple idea and the enthusiasm to make it happen, go for it. Re-arrange the yellow cabinet? Go for it. Purge puritan New England of incomplete parts? Go for it. Make a more durable sign for the open hours? Go for it.

Document and Promote

Documentation is a key element for developing a successful system. One reason is that by documenting how something works, you often realize and address a few things that you've overlooked. In this way, documentation is a design exercise. Another reason is that when a system is documented, you can more easily share the roles and responsibilities required to keep the system healthy. A current example is the gift card protocol that I've been working on with Tim and Angel. If/when I am no longer interested/able to handle the gift card stuff, I can recruit somebody to take over and point them at this document.

That said, documenting a system does not make it work. You need to regularly promote and update the document to keep it useful and to ensure that your fellow staff members accept it as the authoritative reference. The handbook is a great example of a document that meets this test. Many (most?) BK staffers know where it lives (on the wiki) and how to update it (propose, discuss, vote, update). Another good example is the Special Order Protocol. You know you've documented something properly when other people make reference to it.

Finally, (and I could really use a dose of my own medicine on this one), keep the documentation brief:)

Oh, and this wiki is usually the best place to put together documentation. Nothing else (including googledocs, files attached to emails, etc.) has really worked very well.

Make Durable Signs

We do have a laminator (that needs to be repaired) and a label maker. The more clear and simple procedural instructions there are the better. Making durable signage is more important than making pretty signage. Sharpies, cardboard, packing tape, and zip ties are a few of my favorite tools for this job. And making durable signs is a great job for EAB volunteers.

Keep a simple public log

I've used this technique in other organizations and it works well. I'm starting to use it as part of the [System]. The log is on the bathroom door. Have a look.

Promotion and Maintenance

The only reason that we collectively know how special orders are processed, that documentation lives on the wiki, and that reimbursement requests go in the Accounting Inbox is because we promote these systems to each other. This promotion often takes place verbally, with signs (have a look around the register), and on email. In this way, promotion of a system is a very important part of maintaining it.

Who should promote and maintain a system? Well, at first it should be the folks that designed it and implemented it. Later, (with sufficient documentation!) this can be punted to somebody else if necessary. We'd all like to depend on collective understanding to ensure that our systems work. But that collective understanding must be established first.

Recruit and Punt

There will come a time when you have to leave the BK for a while (or forever). Or, perhaps you just don't want to run your system anymore. No problem. Recruit somebody to take on the responsibility and punt it to them. Often, having worked on the system for a while you probably have some candidates in mind. If nobody steps up, the system either runs on its own until somebody adopts it up, or dies. If the system is really important to you, and you really don't want it to break down, consider approaching the board and/or recruiting from outside the organization.

Solicit Collaborators -> Design -> propose -> request comments -> revise -> vote -> implement

Bigger projects require a good amount of effort up front before they can be implemented. Once you realize your system is a "bigger project," I advise you to solicit collaborators, prepare a design, and propose the design to the group with a request for feedback. Expect to spend a good week or so tracking and addressing the feedback. Expect to revise your design based on the feedback and resubmit it for comments. In some cases, you may have to revise more than once. That's okay! Stick with it, take your time, and have faith that the design will converge. At the next meeting, bring the design up for a vote. Upon approval, make it happen.

I have two favorite examples of this process working well. One is the [Quiz]. The other is the work station design that we currently use. It would be rad to see this process exercised for the compressor design.

State your level of commitment clearly

If you're anything like me, you've got way of biting off way more than you can chew. In the "Solicit Collaborators" step described above, put clear limits on your commitment. For example: "I'll collect pricing info and write all of the documentation if somebody else steps up to draw the design and make signs."

If your level of commitment does not extend beyond providing your ideas, you should probably just keep quiet until there's a specific proposal to comment on. Frankly, ideas are generally only useful if they come with the will power and commitment to make them real.